Follow

A troubling thing about alternatives to s-expression representation: to date, I don't know of anyone who, once they understand s-expressions enough to advocate for how the alternative syntax is "better" ends up dogfooding it themselves. Instead, they use s-expressions.

@cwebber The "s" in s-expression stands for "stockholm syndrome"

(ha ha only serious)

@cwebber Just to add some context to the toot for the readers that are not aware of what is happening. Racket is thinking of introducing a new language named Racket2, a language that is not based on parenthesis.

Check this toot by @tfb functional.cafe/@tfb/102456871

ref: github.com/racket/racket2-rfcs

ref: groups.google.com/forum/#!topi

@schemers @cwebber @tfb I agree, it is difficult to leave s-expr and in particular the easy syntax transformations it support.

At the same time Racket is THE language platform for making languages, maybe they will come up with a syntax that can be better that everything that already exists?

@cwebber A few things: I use a mixed-syntax Lisp, and yes I absolutely use some of its syntactic features. It's hardly the best designed alternative to s-expressions, but they got enough right in SKILL that the syntax is useful.

We're talking Racket and PLT here. They're going to insist on something that they want to use. Maybe they'll fail, but imagine if we get something with the syntactic elegance of OCaml or F#, and the ease of use and macros and such, of Racket.

@cwebber Also, John McCarthy used m-expressions. Anyone who waxes too poetic about deep understanding of Lisp and s-expressions needs to face that fact.

@tfb

"....The programs to be hand-compiled were written in an informal notation called M-expressions intended to resemble FORTRAN as much as possible. Besides FORTRAN-like assignment statements and go tos, the language allowed conditional expressions and the basic functions of LISP. Allowing recursive function definitions required no new notation from the function definitions allowed in FORTRAN I - only the removal of the restriction - as I recall, unstated in the FORTRAN manual - forbidding recursive defini- tions. The M-notation also used brackets instead of parentheses to enclose the arguments of functions in order to reserve parentheses for list-structure constants. It was intended to compile from some approximation to the M-notation, but the M-notation was never fully defined, because representing LISP functions by LISP lists became the dominant programming language when the interpreter later became available. A machine readable M-notation would have required redefinition, because the pencil-and-paper M-notation used characters unavailable on the IBM 026 key punch....
...Another reason for the initial acceptance of awkwardnesses in the internal form of LISP is that we still expected to switch to writing programs as M- expressions. The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned. It just receded into the indefinite future, and a new generation of programmers appeared who preferred internal notation to any FORTRAN-like or ALGOL-like notation that could be devised....."
John McCarthy, History of Lisp, 1979

@cwebber

@emacsomancer @cwebber That was in 1979. Twenty years later, McCarthy was himself using m-expressions, including when presenting at Lisp conferences. (I was pretty surprised when I saw that!)

@tfb @emacsomancer Was he using them for notation only, or was he actually programming in them?

As far as I know, nobody ever wrote an m-expression parser that was put into actual use, did they?

@cwebber @emacsomancer I don't know, honestly. I assumed at the time that he was using them for programming, but I don't know for sure.

I implemented an mexpr reader for PLT Scheme, and it worked ok.

@tfb @cwebber fact faced. Shook hands, talked shop, even drank some beer. The fact *is* peculiar, but friendly.

Moving on.

I don't think any of us smug lispers believe that McCarthy was a prophet inspired by the holy spirit, or something. He was just a smart guy who stumbled upon some very fundamental insights, that were later refined into manifestation of pure syntactic glory in the form of S-expressions.

S-exps may not have been the original intent, but they _are_ better.

@temporal @tfb @cwebber Anyone reading the old LISP manuals, and noting that they are using three different notations to describe the same thing, often literally writing the same algorithms three times, should realise that that is not the optimium state of things.

The solution was simply to eliminate the two superfluos syntaxes.

@loke @tfb @cwebber sure. I've read the 1.5 manual.

Obviously, they realized that having multiple syntaxes for the same thing - including a complex mathy one and a simple tree representation - is not an optimal state of things. So they got rid of the superfluous syntaxes and left the simplest one.

This still isn't an argument that s-expressions aren't a local optimum for programming syntax; it's only an observation that things don't get invented in one step, but need time and attention to be refined.

@temporal
Actually, I tried to make the point that it is a local optimum. There was clearly plans to implement another syntax, but it didn't happen because sexprs are actually as good or even better
@tfb @cwebber

@loke @temporal @tfb @cwebber

Everybody knows that FOO notation is superior to BAR, because I like FOO more and BAR has *these* flaws. Some argue that FOO has *such* flaws, but when you actually use it for a while you get used to it and it is not a big deal. Clearly people who doesn't like FOO are ignorants who are unwilling to invest some time to "feel it".

Now you may substitute FOO and BAR with any two of mexp, sexp, indentation-based sematnics etc (in any order!).

@cwebber s-expressions are a very strong local optimum, so they suck people in when they cross the event horizon.

S-exps are a close-to-minimal, unambiguous notation of trees; with syntactic transforms, also a concise way to express code. Trying to make them prettier in some aspect necessarily makes them worse in other aspects. Trying to make them not look like trees makes you lose the benefit that is ease of syntactic transformations.

Once people see past the parens & realize this, they stay with s-exps.

Sign in to participate in the conversation
Octodon

Octodon is a nice general purpose instance. more