7 ms·

Its not very smart to add static typing to Lisp, goes against the strengths of the language. At that point just program in another language, there’s a lot of be

Its not very smart to add static typing to Lisp, goes against the strengths of the language. At that point just program in another language, there’s a lot of benefit of static typing that IDEs can take advantage of but for anyone half decent at Lisp, they wouldn’t feel any need for static typing (outside of compiler optimisations, which is a different thing). Now in terms of interesting things, check out European Lisp Symposium https://european-lisp-symposium.org/ https://european-lisp-symposium.org/ The talks from this year were highly entertaining The other really cool thing in CL IMO is Allegro Cache - in memory datastore that is a joy to use

medo-bear 4y ago
> Its not very smart to add static typing to Lisp [...] (outside of compiler optimisations, which is a different thing) i think this is precisely the point of coalton. cl allows quite handy compiler optimizations and having the option to drop into a native statically typed environment just gives more bang to your lisp ;) coalton is not lispy, sure, but neither is the loop macro, yet it is probably the most powerful looping mechanism in any language :)
- math-dev 4y ago
  Those already exist and have been used by many. Coalton is a set of macros to make it easier for to write with the safety rails of static typing. Now if I write in Swift, for example, static typing is great, because the IDE can give a lot of hints during development. Non lisp languages have quite idiosyncratic syntaxes for various constructs, so static typing really does help a lot there. In large code bases in those languages it also helps a lot because they do not have the power of Lisp macros to reduce syntactical complexity via a Domain Specific Language. Now with Common Lisp, with a powerful generic functions and object system, with runtime dispatch and introspection that far exceeds other languages, plus with the abstraction power of macros, trying to add static typing guard rails simply doesn’t make any sense. I rather program in TypeScript if I am so far removed from the core essence of CL development. Each language has its strengths and the dynamic nature of CL is one of its biggest strengths (with the lack of a GUI and interop with other tools being its largest deficiencies today). Static typing in Lisp is like trying to fit a square plug in a round hole. If somebody wants so much guard rails, other languages are much more suitable because they have been designed (quite successfully if I may add) in that way. TLDR; As per On Lisp by PG, lisp code should be built in layers over each other and hence static typing is unnecessary. Furthermore generic dispatch provides similar features to some extent (although i recommend combining with closer mop and catching edge cases etc)
  - medo-bear 4y ago
    > Static typing in Lisp is like trying to fit a square plug in a round hole. If somebody wants so much guard rails, other languages are much more suitable because they have been designed (quite successfully if I may add) in that way. i belive the author of the coalton package is not very concerned with IDEs or putting up safety nets for developers. i think he uses coalton for making optimizing compilers. think of it as cl+ml not as cl+ts EDIT: typos
  - Kototama 4y ago
    > lisp code should be built in layers over each other and hence static typing is unnecessary It could help for refactoring though.
- math-dev 4y ago
  You bring a good point about the loop macro (which I do like too). Maybe you are right. My personal feeling is trying to do static typing will lead to less elegant code (I say less elegant, because any code that works and is fast enough is good enough - style doesn’t matter that much, esp if readability is somewhat maintained) and has more far reaching implications on a code base than the loop macro which can be isolated to a specific section. But I get your point too, for those who crave static typing, then at least there’s something for them to try.
  - Jach 4y ago
    Java's type system is just powerful enough that sometimes you can approach a problem in a way that resembles a different paradigm than normal, i.e. you solve it with the type system itself much more so than what's expressed by particular procedural or object-oriented or declarative code along the way. Supposedly Haskell encourages this approach as its primary one (and the approach sometimes gets called the "functional programming paradigm" but that I think is a misnomer as FP is primarily about immutability and higher order functions, not static types), to the same extent Java otherwise encourages a Java-style-OOP approach to most things, but I'm too unfamiliar with Haskell to make this claim with high confidence. Still, different paradigms are useful, and one of the best things about Lisp is you aren't forced into one, and there's no threat of one being taken away from you. Coalton to me seems nice for people who like what it provides, it's nice that it exists, even though I don't see myself using it anytime soon since I don't personally enjoy working in that paradigm. There are two other non-type-proofs-paradigm benefits of static typing, but I don't really miss them in CL. The first is related to automatic refactoring tools, but Lisp has features to ease refactoring to compensate, and text-search methods for renaming aren't that bad (and even in Java necessary if you want to make sure you haven't missed reflection calls, though even then you can miss some) and anyway one can read the second edition of the Refactoring book that uses JavaScript if one needs convincing that refactoring can be done just fine even in a lower quality dynamic lang. The second is related to trivial conveniences like compile-time typo protection on symbol names, interface mismatches (like swapped function call argument order -- but failing to that indicates I have an unintuitive interface, and CL has many tools to help me make it better the simplest being keyword arguments), and faster assembly code. But SBCL's handling of the standard CL type system is good enough to get all of those things to a pleasing degree.
- nemoniac 4y ago
  > coalton is not lispy, sure, but neither is the loop macro, yet it is probably the most powerful looping mechanism in any language :) I would argue that iterate is more powerful as well as being more lispy in the sense that it's extensible and macro-programmable. https://iterate.common-lisp.dev/ https://iterate.common-lisp.dev/
  - Jtsummers 4y ago
    Iterate also breaks the count function. Or did the last time I tried to use it.
    - maydup-nem 4y ago
      What do you mean?
      - Jtsummers 4y ago
        Just checked and this is still a problem. Try this code with Iterate: (let ((list '(1 2 3 4 1 2 3 4))) ;; or whatever other sequence (iter (for i from 1 to 10) (sum (count i list)))) It will error out on you. The same works fine with loop: (let ((list '(1 2 3 4 1 2 3 4))) (loop for i from 1 to 10 sum (count i list))) ;; => 8 Now, that's a bit contrived as an example, but an iteration library should not break a standard library function call. https://gitlab.common-lisp.net/iterate/iterate/-/issues/12 https://gitlab.common-lisp.net/iterate/iterate/-/issues/12 - Apparently it's known and they intend to remove it in 2.0, which isn't out yet.
        maydup-nem 4y ago
        good to know, thanks
  - martinflack 4y ago
    I like the lispiness and features of ITERATE but it breaks source location for debugging errors in SBCL with SLIME. Instead the ITER form is indicated, which dampens my enthusiasm for it somewhat. (defpackage :test (:use :cl :iterate)) (in-package :test) (defun test-iter () (declare (optimize (debug 3) (safety 3) (speed 0))) (iter:iter ;;; <-- highlights whole ITER form (sleep 2) (error "test"))) (defun test-loop () (declare (optimize (debug 3) (safety 3) (speed 0))) (loop :do (sleep 2) :do (error "test"))) ;;; <-- highlights ERROR form
Tabular-Iceberg 4y ago
Did they record the talks this year?
- math-dev 4y ago
  I think so, try asking on reddit or IRC if you still can’t find them via some google fu
pjmlp 4y ago
Thanks for sharing, nice to see SisCog still at it.

medo-bear 4y ago

> Its not very smart to add static typing to Lisp [...] (outside of compiler optimisations, which is a different thing) i think this is precisely the point of coalton. cl allows quite handy compiler optimizations and having the option to drop into a native statically typed environment just gives more bang to your lisp ;) coalton is not lispy, sure, but neither is the loop macro, yet it is probably the most powerful looping mechanism in any language :)

math-dev 4y ago
Those already exist and have been used by many. Coalton is a set of macros to make it easier for to write with the safety rails of static typing. Now if I write in Swift, for example, static typing is great, because the IDE can give a lot of hints during development. Non lisp languages have quite idiosyncratic syntaxes for various constructs, so static typing really does help a lot there. In large code bases in those languages it also helps a lot because they do not have the power of Lisp macros to reduce syntactical complexity via a Domain Specific Language. Now with Common Lisp, with a powerful generic functions and object system, with runtime dispatch and introspection that far exceeds other languages, plus with the abstraction power of macros, trying to add static typing guard rails simply doesn’t make any sense. I rather program in TypeScript if I am so far removed from the core essence of CL development. Each language has its strengths and the dynamic nature of CL is one of its biggest strengths (with the lack of a GUI and interop with other tools being its largest deficiencies today). Static typing in Lisp is like trying to fit a square plug in a round hole. If somebody wants so much guard rails, other languages are much more suitable because they have been designed (quite successfully if I may add) in that way. TLDR; As per On Lisp by PG, lisp code should be built in layers over each other and hence static typing is unnecessary. Furthermore generic dispatch provides similar features to some extent (although i recommend combining with closer mop and catching edge cases etc)
- medo-bear 4y ago
  > Static typing in Lisp is like trying to fit a square plug in a round hole. If somebody wants so much guard rails, other languages are much more suitable because they have been designed (quite successfully if I may add) in that way. i belive the author of the coalton package is not very concerned with IDEs or putting up safety nets for developers. i think he uses coalton for making optimizing compilers. think of it as cl+ml not as cl+ts EDIT: typos
- Kototama 4y ago
  > lisp code should be built in layers over each other and hence static typing is unnecessary It could help for refactoring though.
math-dev 4y ago
You bring a good point about the loop macro (which I do like too). Maybe you are right. My personal feeling is trying to do static typing will lead to less elegant code (I say less elegant, because any code that works and is fast enough is good enough - style doesn’t matter that much, esp if readability is somewhat maintained) and has more far reaching implications on a code base than the loop macro which can be isolated to a specific section. But I get your point too, for those who crave static typing, then at least there’s something for them to try.
- Jach 4y ago
  Java's type system is just powerful enough that sometimes you can approach a problem in a way that resembles a different paradigm than normal, i.e. you solve it with the type system itself much more so than what's expressed by particular procedural or object-oriented or declarative code along the way. Supposedly Haskell encourages this approach as its primary one (and the approach sometimes gets called the "functional programming paradigm" but that I think is a misnomer as FP is primarily about immutability and higher order functions, not static types), to the same extent Java otherwise encourages a Java-style-OOP approach to most things, but I'm too unfamiliar with Haskell to make this claim with high confidence. Still, different paradigms are useful, and one of the best things about Lisp is you aren't forced into one, and there's no threat of one being taken away from you. Coalton to me seems nice for people who like what it provides, it's nice that it exists, even though I don't see myself using it anytime soon since I don't personally enjoy working in that paradigm. There are two other non-type-proofs-paradigm benefits of static typing, but I don't really miss them in CL. The first is related to automatic refactoring tools, but Lisp has features to ease refactoring to compensate, and text-search methods for renaming aren't that bad (and even in Java necessary if you want to make sure you haven't missed reflection calls, though even then you can miss some) and anyway one can read the second edition of the Refactoring book that uses JavaScript if one needs convincing that refactoring can be done just fine even in a lower quality dynamic lang. The second is related to trivial conveniences like compile-time typo protection on symbol names, interface mismatches (like swapped function call argument order -- but failing to that indicates I have an unintuitive interface, and CL has many tools to help me make it better the simplest being keyword arguments), and faster assembly code. But SBCL's handling of the standard CL type system is good enough to get all of those things to a pleasing degree.
nemoniac 4y ago
> coalton is not lispy, sure, but neither is the loop macro, yet it is probably the most powerful looping mechanism in any language :) I would argue that iterate is more powerful as well as being more lispy in the sense that it's extensible and macro-programmable. https://iterate.common-lisp.dev/ https://iterate.common-lisp.dev/
- Jtsummers 4y ago
  Iterate also breaks the count function. Or did the last time I tried to use it.
  - maydup-nem 4y ago
    What do you mean?
    - Jtsummers 4y ago
      Just checked and this is still a problem. Try this code with Iterate: (let ((list '(1 2 3 4 1 2 3 4))) ;; or whatever other sequence (iter (for i from 1 to 10) (sum (count i list)))) It will error out on you. The same works fine with loop: (let ((list '(1 2 3 4 1 2 3 4))) (loop for i from 1 to 10 sum (count i list))) ;; => 8 Now, that's a bit contrived as an example, but an iteration library should not break a standard library function call. https://gitlab.common-lisp.net/iterate/iterate/-/issues/12 https://gitlab.common-lisp.net/iterate/iterate/-/issues/12 - Apparently it's known and they intend to remove it in 2.0, which isn't out yet.
      - maydup-nem 4y ago
        good to know, thanks
- martinflack 4y ago
  I like the lispiness and features of ITERATE but it breaks source location for debugging errors in SBCL with SLIME. Instead the ITER form is indicated, which dampens my enthusiasm for it somewhat. (defpackage :test (:use :cl :iterate)) (in-package :test) (defun test-iter () (declare (optimize (debug 3) (safety 3) (speed 0))) (iter:iter ;;; <-- highlights whole ITER form (sleep 2) (error "test"))) (defun test-loop () (declare (optimize (debug 3) (safety 3) (speed 0))) (loop :do (sleep 2) :do (error "test"))) ;;; <-- highlights ERROR form

Tabular-Iceberg 4y ago

Did they record the talks this year?

math-dev 4y ago
I think so, try asking on reddit or IRC if you still can’t find them via some google fu

pjmlp 4y ago

Thanks for sharing, nice to see SisCog still at it.