Re: Lark - A surface syntax for Common Lisp

Dylan had/has macros for D-Exprs to provide similar functionality to its
S-Expr syntax, it’s part of why D-Exprs were formalized the way they were
iirc. That’s to say nothing about all the work that has been done in other
languages that provide syntactic macros to non-SExpr-based languages.
Racket, Template Haskell, ppx and co for OCaml, nim, lots of systems have
decent macros at various levels now.

====
Q. How many Prolog programmers does it take to change a lightbulb?
A. No.


On Sun, Feb 15, 2026 at 10:49 David McClain (as dbm at refined-audiometrics
dot com) <[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.
>
> 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
>