Re: Lark - A surface syntax for Common Lisp

I think I did run into issues similar to that a bit with the 
assembler.    The assembler language doesn't have anything like pending 
effects.. the win was keeping the primitives sufficently "lispy" that 
they could be built up without effective side-effects.. lol, I guess it 
could be viewed as a form of a functional-only implementation of the 
language, so primitives can be aggregated without accumulation of 
unknown stuff.

Part of the test program I feed into it involves building up some basic 
macros using the usual Lisp syntax, so as to bring the reader and macro 
functions to bear.   With the language primitives oriented around that 
approach I think complexity can scale without a lot of risk.   But I 
haven't written something complex in it, so I wouldn't be suprised if 
there were lurking issues.



On 2/15/2026 11:37 AM, David McClain wrote:
> … but at the same time, I think the total lack of syntax rules in 
> Forth is what makes it so dangerous and cumbersome to use. Semantics 
> are whatever verbs you list and in their order of listing.
>
> Lisp s-exprs do have syntax rules which makes their effects visually 
> delimited by the enclosing parens. Not so in Forth.
>
> With Forth you come to depend on “pending effects” that stack up, much 
> like the operand stack, and what you end up with is non-determinate. 
> You cannot predict (in general) where the pending effects will end in 
> a Forth sentence, unless you fully understand the operation of each 
> individual Forth word and their position in the sentence.
>
> That is convenient for writing quick Assemblers in Forth, but really 
> inconvenient for conveying meaningful source code for an application 
> to another human for maintenance. (Or even to yourself, some six 
> months later.) Hence giving the notion of “Write Only Language” to Forth.
>
>
>
>> On Feb 15, 2026, at 08:56, David McClain (as dbm at 
>> refined-audiometrics dot com) <[email protected]> wrote:
>>
>> I am a longtime ago Forth expert (from Telescope Observatory use). 
>> Writing Assemblers for various CPU’s in Forth is an afternoon’s 
>> exercise. That used to amaze other people who worked arduously for a 
>> year to obtain their Assemblers.
>>
>> A big part of the reason for this simplicity is the near total lack 
>> of syntax rules, and the use of “defining words” to impart more 
>> semantics than previously existed. This pushes in the exact opposite 
>> direction from noisy syntax languages.
>>
>> code Next
>> ip )+ wp mov
>> wp )+ jmp
>>
>> Lisp s-exprs have just barely more syntax than Forth, and that alone 
>> makes Lisp less suitable for writing Assemblers like we did in Forth. 
>> In the above example, that “)+” is a Forth word that invokes a “;:” 
>> defining word to modify the top of stack item with an address mode. I 
>> cannot write something as simple using Lisp s-exprs.
>>
>>
>>
>>
>>> 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
>>
>