71–73 of 73 posts
Earlier quoted context omitted.
I think given the sheer amount of them that is demonstrably false
Have you used one at work? I would surely love to but haven’t had the chance yet.
Earlier quoted context omitted.
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 want static types in a higher level assembly language for systems programming. That's because I want to work with machine-level representations, in which there are no spare bits for indicating type at run-time (moreover, using such a language, we can design a type system with such bits, in any way we please). I don't want static types in a high level language. It's just counterproductive. We only have to look at nu…
This can easily be modeled in a static type system. All you really need is subtyping.
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!
Fun fact: the DOS version of the Cakewalk music software in the late 80's had a scripting language (CAL) that was very loosely based on Lisp. The author (Greg Hendershott) later went on to write a lot about Lisp.
With the Ableton Live Notes API, enabling something similar is one of the things I plan on adding to Scheme for Max this year.
Thanks for the tip about who wrote it, I will look him up!