Re: Lark - A surface syntax for Common Lisp

Thanks for  the video link. I’m watching and thinking in the back of my mind - Rhombus isn’t initially simple. There is some amount of cognitive loading, almost equivalent to second level (inner nested) Lisp Backquoting in macro expressions.

And invariably, when imposing a “Language” outline on a body of syntax, like Racket allows, you must end up needing escape clauses at some point, like Rust Unsafe.

The alternative provided by Lisp is to just keep everything exposed, and depends on programmer discipline to not write certain forms of code that violates some abstract guidelines - e.g., writing Lisp to provide purely functional code, using functions like REMOVE instead of mutating functions like DELETE. 

The Lisp paradigm still has cognitive loading that grows. Not sure it is worse than Rhombus, because I haven’t written any Rhombus yet.

The ideal is to provide an absolute minimum of cognitive loading to the programmer. I clearly recall one incident in Rust, when I spent a full day writing a security protocol for shared messaging (like Telegram), where just to get the compiler to accept my coding was a chore. Once I finally got a clean compile I put the code aside for a week. On return to the code it became clear that all my work had produced an idempotent result. A mathematical identity, and not an encryption.

There had been so much cognitive loading in Rust, that I ended up forgetting the goal in an effort to please the damn compiler. That kind of cognitive loading is just stupid and destructive.



> On Feb 16, 2026, at 04:29, Jens Axel Søgaard (as jensaxel at soegaard dot net) <[email protected]> wrote:
> 
> > So, when whitespace is significant, how do you tell whether or not a space has been added or dropped? Probably more difficult when they get dropped. 
> > Do you have to re-analyze the entire function to discern the proper level of nesting?
> 
> It is more or less the same effort compared to forgetting a right parenthesis  in Lisp.
> The automatic indenter will in both languages indent the following lines incorrectly.
> This alerts you that something is wrong - then you look for the problem.
> 
> I can recommend this talk by Matthew Flatt.
> 
> https://www.youtube.com/watch?v=hkiy1rmKA48
> 
> He brings the syntax into perspective and explains why the choice makes it possible
> to write macros using the lessons learned from Lisp/Scheme/Racket.
> 
> 
> Den man. 16. feb. 2026 kl. 00.27 skrev David McClain <[email protected] <mailto:[email protected]>>:
>> So, when whitespace is significant, how do you tell whether or not a space has been added or dropped? Probably more difficult when they get dropped. Do you have to re-analyze the entire function to discern the proper level of nesting?
>> 
>> 
>>> On Feb 15, 2026, at 15:49, David McClain (as dbm at refined-audiometrics dot com) <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> as an aside,
>>> 
>>> I’m probably too old to appreciate languages that use whitespace as a signifier for syntax. 
>>> 
>>> Reminds me too much of the days when I would drop an entire tray full of punched cards and had to reassemble the program by hand without having had the foresight to punch sequence numbers in the final columns.
>>> 
>>> But I do note that Python and Haskell both seem to use whitespace as something of significance. And now Rhombus. 
>>> 
>>> Have you never lost your indentation due to text editors compressing runs of spaces into tab characters? Or was that just the early days of Emacs?
>>> 
>>>> On Feb 15, 2026, at 15:39, Jens Axel Søgaard (as jensaxel at soegaard dot net) <[email protected] <mailto:[email protected]>> wrote:
>>>> 
>>>> > On a more serious note, the existing S-expr surface syntax is a huge reason for the enormous utility of Lisp macros. Noisy syntaxae (sp?) just make that so much more difficult.
>>>> 
>>>> FWIW Rhombus is an attempt to apply the lessons learned with S-expression macros for languages with a more familiar syntax.
>>>> 
>>>> https://docs.racket-lang.org/rhombus-guide/Notation.html
>>>> 
>>>> /Jens Axel
>>>> 
>>>> 
>>>> Den søn. 15. feb. 2026 kl. 16.49 skrev David McClain (as dbm at refined-audiometrics dot com) <[email protected] <mailto:[email protected]>>:
>>>>> On a more serious note, the existing S-expr surface syntax is a huge reason for the enormous utility of Lisp macros. Noisy syntaxae (sp?) just make that so much more difficult. 
>>>>> 
>>>>> You have issues of syntax operator precedence, left/right binding, etc. Just an absolute mess, and guaranteed to be different in some respects from other popular “noisy” languages. I fully suspect that this is the reason for abandoning early M-syntax for Lisp. 
>>>>> 
>>>>> After all the effort, S-exprs are simply easier to use and syntax-extend.
>>>>> 
>>>>> A simple example of the “noise” level is to just compare JSON with S-expr. You can do absolutely everything with S-exprs that JSON syntax requires, and with half the number of keyboard keystrokes.
>>>>> 
>>>>> 
>>>>> 
>>>>> > On Feb 15, 2026, at 08:14, Greg Menke (as gregm32768 at comcast dot net) <[email protected] <mailto:[email protected]>> wrote:
>>>>> > 
>>>>> > 
>>>>> > I used a similar method writing a 8052 embedded cpu assember- a small language built on top of lisp so all the macros etc can be applied, and the effect of "running" it is to emit a located binary ready to run on the cpu.   Not used for realsies alas but disassembly of the object code shows it working.. the 8052 being sufficiently simple that its easy to work that out.   The theory was complex functions more advanced than simple macro assembly could be built up conveniently using lisp, perhaps not unlike Forth.
>>>>> > 
>>>>> > It was fairly simple to write, but did need a bit of nuance to get things to work right eg macros etc.
>>>>> > 
>>>>> > Greg
>>>>> > 
>>>>> > 
>>>>> > On 2/15/2026 8:16 AM, Yuri Davidovsky (as work at disclosure dot ie) wrote:
>>>>> >>> On 15 Feb 2026, at 11:03, Gerry Weaver <[email protected] <mailto:[email protected]>> wrote:
>>>>> >>> 
>>>>> >>> It was actually inspired by several languages. Lark isn't a standalone
>>>>> >>> language that happens to compile to Lisp — it's a skin over Common Lisp.
>>>>> >>> Every Lark construct maps directly to a CL form. fn is defun, struct is
>>>>> >>> defstruct, |x| x * 2 is (lambda (x) (* x 2)), @(...) drops straight into
>>>>> >>> s-expressions. You can call any CL function, use CFFI, define CLOS
>>>>> >>> methods with typed dispatch, write macros with backquote templates. The
>>>>> >>> FFI, the package system, the condition system, the type declarations —
>>>>> >>> it's all CL exposed through a friendly syntax.
>>>>> >> It appears that you picked up where John McCarthy left off.
>>>>> >> 
>>>>> >> An interesting approach of making lisp a language that is more suitable for one personally, that is something that I would totally approve as I myself constantly invent ways of doing things differently and more conveniently. I have also been thinking recently about streamlined ways of parsing DSL languages in Lisp (essentially what you are doing here), and I think I haven’t come to a good conclusion how it should work.
>>>>> >> 
>>>>> >> Tokenising appears to be easy enough to do using the standard Lisp reader, however I haven’t decided on a good way to do parsing/syntax checking of the resulting list of tokens. How do you go about parsing the tokens in order to extract the syntax patterns (say for an fn definition) and compile them into lisp? Have you used the parsergen package in Lispworks for that, or did you come up with your own parsing tool?
>>>>> >> 
>>>>> >> I am not deeply familiar with the topic of computer languages’ parsing and would be interested to hear the perspective of someone who did some work in the area, as you evidently have.
>>>>> >> 
>>>>> >> 
>>>>> >> 
>>>>> >> 
>>>>> >> _______________________________________________
>>>>> >> Lisp Hug - the mailing list for LispWorks users
>>>>> >> [email protected] <mailto:[email protected]>
>>>>> >> http://www.lispworks.com/support/lisp-hug.html
>>>>> > 
>>>>> > _______________________________________________
>>>>> > Lisp Hug - the mailing list for LispWorks users
>>>>> > [email protected] <mailto:[email protected]>
>>>>> > http://www.lispworks.com/support/lisp-hug.html
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Lisp Hug - the mailing list for LispWorks users
>>>>> [email protected] <mailto:[email protected]>
>>>>> http://www.lispworks.com/support/lisp-hug.html
>>>> 
>>>> 
>>>> 
>>>> --
>>>> -- 
>>>> Jens Axel Søgaard
>>>> 
>>> 
>> 
> 
> 
> 
> --
> -- 
> Jens Axel Søgaard
>