Speaking of such matters, what actually is the proper definition of S-expressions? I mean, I know ’em when I see ’em in a LISP, but I don’t think I know the proper definition of them.
e ::= <atomic>
\| (e . e)
Ah, it is that simple? (also, I love that you answered just by providing a grammar :smile:)
not shown: empty lists, non-dotted notation for lists (arguably a more central feature than dotted lists), various comment syntaxes, various string delimiters, various string escape sequences :-p
guess <atomic> can imply a lot :)
I also don’t know if stuff like #hash(...) should be counted as atomic.
The classical definition precedes a lot of nice things that were created after the idea of an s-expression but before most of us were born, but I think it might still be the best way to understand what they’re really about.
And then, yeah, you also need to know that (1 2 3) is just a less fussy notation for (1 . (2 . (3 . '())))
Btw - what does the S stand for?
You have ( and ). Combine them together, and you get S :wink:
I think I would consider #hash(...) atomic for the purposes of sexpr, and sort of hust attach that thought to an asterisk and a footnote to remind me that the idea predates all the cool stuff Backus and Naur did around formalizing the specification of the non-Lisp branch of the language family tree.
Iunno. Maybe not. That ones a little tricky to cram easily into the classical definition because it predates macros. Maybe it’s better to think of reader macros as a meta language for generating sexp but not really sexp themselves?
#hash(...) could he considered a reader shortcut for (hash ...) I guess. There are some semantics assumption though (like #lang racket/base), but that’s true for both cases. (Am I using ‘semantics’ properly here?)
Unfortunately that isn’t quite the semantics of #hash
Even though it’s not how it currently works, maybe we can imagine a world where the #xxx(...) reader syntax is a shortcut syntax for evaluating (xxx ...) within #lang racket/core (or kernel, or read-time?) at read time, and maybe one could also write (at-read-time (xxx ...)) to the same effect, where at-read-time of course has special read-time semantics.
I like that idea. Personally, I think it’d go well to usurp the common lisp #. read-eval macro for this purpose.
I’d vote for c-expression for any non-s-exp. The C could stand for “complicated”, “clunky”, or “C” :stuck_out_tongue:
Are “sweet expressions” a subset of s-expressions? If so maybe any non-s-exp is a sour expression?
I made a meme out of this:
This is the quality content we crave
Does that mean there has to be a new syntax for such literals?
Right now, these kind of literals — hashes, vectors and boxes — can ended up in the syntax object and the compiled bytecodes. I kind of wonder if removing them could change the performance.