Re: Lark - A surface syntax for Common Lisp

> 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]>:

> 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]> 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]> 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]>:
>
>> 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]> 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]> 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]
>> >> 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
>>
>>
>> _______________________________________________
>> Lisp Hug - the mailing list for LispWorks users
>> [email protected]
>> http://www.lispworks.com/support/lisp-hug.html
>>
>
>
> --
> --
> Jens Axel Søgaard
>
>
>
>

-- 
-- 
Jens Axel Søgaard