4 ms·

The biggest advantage of using SBCL over other Common Lisp implemnetations is that it has very good support for Common Lisp types: https://www.sbcl.org/manual/

by brabel 3y ago

The biggest advantage of using SBCL over other Common Lisp implemnetations is that it has very good support for Common Lisp types: https://www.sbcl.org/manual/index.html#Handling-of-Types https://www.sbcl.org/manual/index.html#Handling-of-Types I "(declaim)" the types of my exported functions (at least) which makes life much easier when consuming the library's API, and when you make a mistake (either in the caller or the implementation) you'll get either an error or a warning when you compile the function. The types also show up in the documentation in SLIME and can (but is not guaranteed to, you can check with (time) and (disassemble) and (sb-profile)) make code much faster... specially if you need a lot of numeric computation, declaring the types of the numbers as `fixnum` or `single-float` (you may need to explicitly restrict the range of the numbers too to get the best Assembly) your code can run much faster as that will let it compile to basically what C would do, as it avoids the Lisp numerical tower slowing things down.

ducktective 3y ago
Quick comparison between CL with types and Typed Python as both are dynamic languages with types added later in?
- p_l 3y ago
  Nope, Common Lisp is strongly typed, however the implementations are a bit flexible in how they handle it - the minimum required is that they serve as asserts (essentially, types for safety). CMUCL Python compiler (not to be confused with the much younger language of the same name), which is also used by CMUCL's descendants like SBCL, is famous for the amount of type-guided optimisation it performs. If it can subtype, or you can inform you of appropriately narrow type, it will happily replace more generic arithmetic and with (safety 0) elide all safety checks.
  - pfdietz 3y ago
    Also, the soft typing it does to allow the type-guided optimization also allows it to detect many type errors at compile time. These become warnings; it's considered proper to eliminate all such warnings from your code before considering it to "compile".
- nabla9 3y ago
  Opposite of strongly typed is weakly typed or loosely typed. Opposite of static typing is dynamic typing. Both CL and Python are strongly and dynamically typed by default. Their values have well defined types, variables don't. C/C++ are statically and weakly typed. Haskell and Java is statically and strongly typed. Many shell and scripting languages are weakly or loosely and dynamically typed.
  - d3ckard 3y ago
    It’s a nice summary, I might steal that.
  - lispm 3y ago
    Common Lisp includes a type system for static typing. Variables thus can have types in Common Lisp. (defun foo (bar) (declare (type (integer 100 200) bar)) ...) Above declares the variable BAR to have the type of a subtype of integers between 100 and 200. The language standard does not enforce any static type checking. What implementations typically might do: * ignore it: interpreters, Lisp Machines, etc. * use it for optimizations: most compilers incl. SBCL * do type inference: many compilers incl. SBCL * use it at runtime for type assertions: SBCL * use it at compile time for type checks: SBCL
  - jemfinch 3y ago
    Calling C/C++ "weakly typed" is just functional/academic language snobbery. They have some automatic type conversions (more than some languages, less than others) and they have casts that allow programmers to circumvent the type system (but so does Ocaml with its Obj.magic, and Haskell with its unsafeCoerce). The strong/weak distinction isn't particularly valuable in the first place, but it becomes especially useless if you try to shoehorn C/C++ into the "weak" category.
    - nabla9 3y ago
      I disagree. Firstly, Ability to circumvent type system means it's a weak type system. In in C and C++ you can take pointer to anything and cast it into anything. The memory model in both languages is just one or more contiguous sequences of bytes. https://en.cppreference.com/w/cpp/language/memory_model https://en.cppreference.com/w/cpp/language/memory_model Secondly, What you call "functional/academic language snobbery" is accurate language that every software engineer benefits from using and understanding. Being professional is not snobbery or elitism.
- brabel 3y ago
  > both are dynamic languages with types added later in? Common Lisp has always had types and type declarations (e.g. `the` in the hyperspec[1]) as it's part of the specification. It was not added later as far as I know. However, `declaim` and `declare` were left very underspecified so they tend to be very implementation-specific, though there are libraries that make types more portable[2][3]. [1] http://www.lispworks.com/documentation/HyperSpec/Body/s_the.htm#the http://www.lispworks.com/documentation/HyperSpec/Body/s_the.... [2] https://github.com/lisp-maintainers/defstar https://github.com/lisp-maintainers/defstar [3] https://github.com/ruricolist/serapeum/blob/master/REFERENCE.md#types https://github.com/ruricolist/serapeum/blob/master/REFERENCE...

by brabel 3y ago

ducktective 3y ago

Quick comparison between CL with types and Typed Python as both are dynamic languages with types added later in?

p_l 3y ago
Nope, Common Lisp is strongly typed, however the implementations are a bit flexible in how they handle it - the minimum required is that they serve as asserts (essentially, types for safety). CMUCL Python compiler (not to be confused with the much younger language of the same name), which is also used by CMUCL's descendants like SBCL, is famous for the amount of type-guided optimisation it performs. If it can subtype, or you can inform you of appropriately narrow type, it will happily replace more generic arithmetic and with (safety 0) elide all safety checks.
- pfdietz 3y ago
  Also, the soft typing it does to allow the type-guided optimization also allows it to detect many type errors at compile time. These become warnings; it's considered proper to eliminate all such warnings from your code before considering it to "compile".
nabla9 3y ago
Opposite of strongly typed is weakly typed or loosely typed. Opposite of static typing is dynamic typing. Both CL and Python are strongly and dynamically typed by default. Their values have well defined types, variables don't. C/C++ are statically and weakly typed. Haskell and Java is statically and strongly typed. Many shell and scripting languages are weakly or loosely and dynamically typed.
- d3ckard 3y ago
  It’s a nice summary, I might steal that.
- lispm 3y ago
  Common Lisp includes a type system for static typing. Variables thus can have types in Common Lisp. (defun foo (bar) (declare (type (integer 100 200) bar)) ...) Above declares the variable BAR to have the type of a subtype of integers between 100 and 200. The language standard does not enforce any static type checking. What implementations typically might do: * ignore it: interpreters, Lisp Machines, etc. * use it for optimizations: most compilers incl. SBCL * do type inference: many compilers incl. SBCL * use it at runtime for type assertions: SBCL * use it at compile time for type checks: SBCL
- jemfinch 3y ago
  Calling C/C++ "weakly typed" is just functional/academic language snobbery. They have some automatic type conversions (more than some languages, less than others) and they have casts that allow programmers to circumvent the type system (but so does Ocaml with its Obj.magic, and Haskell with its unsafeCoerce). The strong/weak distinction isn't particularly valuable in the first place, but it becomes especially useless if you try to shoehorn C/C++ into the "weak" category.
  - nabla9 3y ago
    I disagree. Firstly, Ability to circumvent type system means it's a weak type system. In in C and C++ you can take pointer to anything and cast it into anything. The memory model in both languages is just one or more contiguous sequences of bytes. https://en.cppreference.com/w/cpp/language/memory_model https://en.cppreference.com/w/cpp/language/memory_model Secondly, What you call "functional/academic language snobbery" is accurate language that every software engineer benefits from using and understanding. Being professional is not snobbery or elitism.
brabel 3y ago
> both are dynamic languages with types added later in? Common Lisp has always had types and type declarations (e.g. `the` in the hyperspec[1]) as it's part of the specification. It was not added later as far as I know. However, `declaim` and `declare` were left very underspecified so they tend to be very implementation-specific, though there are libraries that make types more portable[2][3]. [1] http://www.lispworks.com/documentation/HyperSpec/Body/s_the.htm#the http://www.lispworks.com/documentation/HyperSpec/Body/s_the.... [2] https://github.com/lisp-maintainers/defstar https://github.com/lisp-maintainers/defstar [3] https://github.com/ruricolist/serapeum/blob/master/REFERENCE.md#types https://github.com/ruricolist/serapeum/blob/master/REFERENCE...