Re: Lark - A surface syntax for Common Lisp

For a while, I took an interest in the Kernel language, which reinvents FEXPRs from long past. It took me a while to grok the essential difficulties in FEXPRs, but they are very real problems, akin to the variable capture to which Scheme is so prone. 

When you cannot count on the meaning of anything in your language, you really get stuck - not just in terms of writing understandable source code, but also in being unable to make meaningful compiled optimizations.

Common Lisp, with all its various namespaces, and even maddeningly at time, separating variables from function bindings, ends up being very capable of supporting highly expressive code, and allowing for massive macrology economy in the source code. Common Lisp, once you boil it all down is probably the most malleable, capable, efficient coding, language that I have ever seen.

I did spend about a decade on my NML language, which parroted OCaml syntax, but was late bound like Lisp, and numerically vectorized. This language specialized in data analysis right from the keyboard. 

But after providing an invited talk to a European Lisp conference, at which they expressly denied any interest in NML, I reverted back to using Lisp almost entirely. That was about 15-20 years ago. Lisp is more wordy, but far simpler to comprehend at a glance, and the macrology allows the full power of the language to be used in crafting new surface syntax. I have to agree with the conference organizers - there is no better alternative to Lisp.

I’d love to find a more powerful language. But I haven’t seen any serious successful candidates yet. Kernel was a possible contender for me, but it offered too much flexibility in return for never being quite sure what your program actually means.



> On Feb 15, 2026, at 11:35, Tim Bradshaw (as tfb at cley dot com) <[email protected]> wrote:
> 
> On 15 Feb 2026, at 17:46, David McClain <[email protected]> wrote:
>> 
>> Rust worries way to much about “memory safety”, and Racket worries way too much about "variable capture".
> 
> To be fair I think the hygiene thing is real.  But the interesting part of it that isn't solved in CL (I think of this as 'upward hygiene', where a macro relies on some name meaning what it thinks it means and it doesn't) is soluble by placing restrictions on non-CL packages which are similar to those on the CL package.  That would even be fairly easy to implement, so a compiler would complain about code which violated the restrictions.  Failing that you just document the restrictions.
> 
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html