51–60 of 73 posts
Earlier quoted context omitted.
> Now that types and tools are advancing, static Lisps are feasible, and I love that. Haven't that been feasible for a pretty long time already? Judging by how well-received (or not) they've been, it seems there isn't much demand for it. Things like clojure.spec and alike (compile-time + run-time typing) seems much more popular, but isn't static.
There isn’t much demand for Lisps in general.
For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme. Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference…
Earlier quoted context omitted.
What are the main differences between OcamML and a statically typed Lisp?
Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).
Rust is categorically different from all of these other things. Lisps (and OCaml) all have interactivity as a core language feature - Rust is as non-interactive as it gets.
> whose macro system is quite good
Compared to C, perhaps.
Earlier quoted context omitted.
There isn’t much demand for Lisps in general.
I think given the sheer amount of them that is demonstrably false
This just made my day. I'm the author of Scheme for Max, an extension to the Max music programming environment that puts the s7 Scheme interpreter in it for scripting note-event level code (not dsp). It would be fantastic to also be able to use a subset of Scheme for generating DSP level code, where speed would be more important than dynamic typing or continuations/tco/etc. I will be watching this closely!
Earlier quoted context omitted.
Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).
There is a simpler solution than type inference to removing type annotations while retaining types: remove the distinction between variable and type names. The way that you handle multiple instances of a type is to define an alias for the type. In pseudocode it might look like: type Divisor Number def divide(Number, Divisor) = Number / Divisor As compared to: def divide(number: Number, divisor: Number) = number / Div…
This doesn't remove them, it just moves them.
For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme. Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference…
I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case…
For Common Lispers such as myself, who are vaguely aware of developments in the Scheme space: the most important difference between CRUNCH and Chicken appears to be that, while both compile down to C/object code, CRUNCH is additionally targeting a statically-typed subset of Scheme. Opinion: this is great. The aversion of Lispers to static types is historical rather than intrinsic and reflects the relative difference…
I don't believe it's not intrinsic. A lot of the reason why Lispers may be averse to static types is because of the perceived inflexibility it can induce into the system. Lisp programmers don't want to be told what to do, especially by the compiler. Some CLs like SBCL have allowed some form of inference through the standard type declarations in the language. This leads me to believe that the 'right thing' in the case…
I don't want static types in a high level language.
It's just counterproductive.
We only have to look at numbers to feel how it sucks. If we divide two integers in Common Lisp, if the division is exact, the object that comes out is an integer. Otherwise we get a ratio object. Or if we take a square root of a real, we get a complex number if the input is negative, otherwise real.
This cannot be modeled effectively in a static system. You can use a sum type, but that's just a greenspunned ad hoc dynamic type.
Earlier quoted context omitted.
What are the main differences between OcamML and a statically typed Lisp?
Type inference is probably the biggest thing. You would need explicit "phases" to expand macros, disallow macro expansion at runtime, and implement bi-directional type inference HM-style to get even close to what OCaml has. To be honest, I'd kill for a Lisp that had the same type system as OCaml, but I suspect the closes we'll get is basically Rust (whose macro system is quite good).
Shen homepage: https://shenlanguage.org/