Hacker News Reader

Hacker News

Comment by bonki | Hacker News Reader

Full thread

bonki

C-like and S-expressions? I guess my definition of a C-like language is a bit off.

View on HN

They aren't incompatible.

My own toy language which is intended to be a C replacement for myself is prototyped entirely in s-expressions.

What else would you use to represent a syntax tree?

Also with some tweaking you can push s-expr pretty far WRT readability. Here is an example of a cwerg program using "enhanced" s-exprs:

https://github.com/robertmuth/Cwerg/blob/master/FrontEnd/Tes...

And here is same the same program in the tentative concrete syntax:

https://github.com/robertmuth/Cwerg/blob/master/FrontEnd/Con...

Honestly I'm doing pretty much the same thing; been through several iterations of AST without yet deciding on a syntax, other than "Easy for C Programmers" and "Doesn't look like someone ate alphabet soup and vomited it all over the screen".

I had skimmed through the readme and then went straight to the example folder so missed the fact that this is not supposed to be the final concrete syntax, makes much more sense now!

> What else would you use to represent a syntax tree?

Different syntax for different concepts, easier for the eye, quicker the understanding, troubleshooting.

myself i'm partial to rose trees

rather than

    (set (aref a i) (+ i j))

you have

    set(aref(a i) +(i j))

and no difference between i and i(), and only one type of node, with a tag and zero or more kids, instead of separate node types for having kids and having tags

the rose tree model feels like a slightly closer fit to the needs of abstract syntax trees, and although it isn't simpler than sexps, it isn't more complicated either

another possibility is the ml approach where juxtaposition denotes function application but the functions are curried so they only ever take a single argument, which usually looks exactly the same as sexps but conceptually associates the other way

    set (aref a i) (+ i j)

the only difference is that this is equivalent, which i think is worse in this context:

    set ((aref a) i) ((+ i) j)

(note that ml only uses this approach for expressions to evaluate. for data, such as asts, it uses the rose tree approach)

regardless, the semantics are a lot more important than the syntax

> What else would you use to represent a syntax tree?

For unit tests I've used pretty-printed JSON. Text editors syntax highlight it plus you can leverage an off-the-shelf JSON library rather than writing your own s-expressions serializer (not that serializers are difficult to write or anything, but just as a convenience).

Apparently the actual surface syntax is not yet decided and the S-expression abstract syntax is currently used as a stand-in.

That is correct. The concrete syntax will be python-like. Somer examples are here:

https://github.com/robertmuth/Cwerg/tree/master/FrontEnd/Con...

Precedent for Python-like but C-level language in Nim; will be interested to see how yours develops too. Good luck!

IIRC, wasn't this originally also the case for Lisp?

I wonder how hard it would be to keep the S-expression syntax when the new one is implemented. As a C and Lisp programmer I'm intrigued by the possibilities - C-family syntax being IMO more readable, but Lisp providing unparalleled (in my experience) metaprogramming possibilities.

I'm also a Lisp and C programmer (want to get better at Forth too).

I think Lisp and C (not C++) share an important characteristic that few other languages share: being low-level.

C is low-level due to minimal abstractions from the hardware.

Lisp is low-level due to minimal abstractions from the AST.

People wanting to program very close to hardware feel comfortable with C. People wanting to program very close to the compiler feel comfortable with Lisp.

I am planning to make the s-expr form the on disk format.

Does that mean you are planning a specific editor for it?

I was thinking more of some light weight tools that convert between the two representations and which can be hooked into existing editors.

Ah, now I see. Thx.

I see. And this led me to a question: what can make a language expressed in S-expressions not a lisp?

Any language can be expressed in S-expressions. A translation of the syntax tree to sexprs is often used in parser debugging. And Lisp doesn’t have to be expressed in S-expressions (see Dylan, or M-expressions, a syntax for Lisp that predates S-expressions).

Lisp traditionally has these features, but they’re separate features:

* There is a rich syntax for literal data structures

* Code is directly exposed as data structures so it can be manipulated with code (macros)

* Code is written as literal data structures so it has no separate syntax

Thanks. Can you please elaborate some bits on what is meant under "rich syntax for literal data structures"? I'm not a lisp pro, just started studying it.

That's nothing special of Lisp. Literal data structures means that one can write down data objects like list, arrays, vectors, numbers (floats, integers, rational, complex, ...), symbols, strings, characters, records/structures, ...

Common Lisp for example:

    (berlin hamburg munich cologne)   ; a list of symbols
    #(berlin hamburg munich cologne)  ; a vector of symbols
    (1.3 1.3d6 13 #c(1 3) 1/3)        ; a list of numbers
    "Hello World!"                    ; a string
    #\H                               ; the character H
    #S(CITY :NAME BERLIN              ; a structure (aka record) of type CITY
            :COUNTRY GERMANY)
    #*1010101111                      ; a bitvector
    #2A((BERLIN GERMANY)              ; a 2d array
        (PARIS FRANCE))

Other programming languages have their own syntax for literal data (even data structures like unicode characters, hash tables, unicode strings, decimal numbers, ...) Common Lisp OTOH has an extensible reader, one can add new syntax extensions for data structures, using so-called reader macros. READ is the function to read s-expressions from text streams. It returns data objects.

> Lisp traditionally has these features

Lisp has traditionally a two stage syntax

1) S-expressions

2) Lisp

S-Expression level has a syntax to describe data: lists, conses, numbers, symbols, strings, arrays, ...

Lisp syntax is defined on top of that, as s-expressions: variables, function calls, macro calls, special forms (using quote, let, if, progn, setq, catch, throw, labels, flet, declare, ...), lambda expressions. Each macro also can implement syntax.

> Any language can be expressed in S-expressions.

I'm not sure this is true for the C preprocessor, though, where macros can represent partial structure.

People have come up with S-expression syntaxes for C, basically to be able to write C macros in lisp. Here's one: https://voodoo-slide.blogspot.com/2010/01/amplifying-c.html

Couple of others:

c-mera: https://github.com/kiselgra/c-mera

cmacro: https://github.com/eudoxia0/cmacro

(This one one is implemented in Common Lisp for its semantics, but doesn't use a S-exp surface syntax for the code.)

sxc: https://github.com/burtonsamograd/sxc

(incomplete)

MetaC: https://github.com/mcallester/MetaC

(References Lisp in readme; doesn't use it for implementation or notation, but references ideas. Source code seems to be a core of .c files, and the rest self-hosted in its own .mc language. Somehow provides a REPL.)

My thoughts too. I was expecting something between Go and Rust in syntax, maybe more terse.

That was also my first thought after looking at the examples.

Reply on news.ycombinator.com