As we've been discussing syntax, it has occurred to me that perhaps we're
getting a little too bogged-down in the details. This is most obviously
seen with the "non-whitespace for whitespace" discussion, but I think it
has affected the discussion of syntax, for better or for worse, since the
first time David Wheeler started to think about sweet-expressions.
And here's my random thought: while it's good to try to fit
sweet-expressions into as many Lisp dialects as possible, it would be a
very good idea to separate the ideas from the actual syntax. For example,
most various Lisp dialects implement s-exprs, but they do so in a dizzying
number of sometimes-incompatible ways. (Those that don't, like Dylan, are
almost literally an expression of m-exprs, and have certain problems as a
result.) Yet, s-exprs have a simple syntax, typically using parentheses
and "." to define lists (McCarthy's "LISP 1.5" formally defines a s-expr as
the form "(A . B)" where A and B are either a symbol or another s-expr),
and having quote and quasi-quote syntax to manipulate s-exprs.
If I recall correctly, (I've only read the first couple of pages of "LISP
1.5") McCarthy even uses square brackets instead of parentheses to define
s-exprs; and I think Clojure uses different types of brackets
interchangeably. (That's one thing I don't like about Clojure--I'd rather
that a single bracket type mean one, and only one, thing, for
consistency...and for maximum flexibility.)
It would be useful if we could do the same with t-exprs: establish basic
rules, that could then be encoded in a variety of syntaxes. Once the basic
rules have been clearly defined, the syntax to implement them won't matter
so much--and the implications of the rules can be explored in greater
depth. Furthermore, once these basic rules are defined, syntax will only
be an implementation detail, that could potentially change from one syntax
to the next.
I'm not sure what prompts me to feel that this should be an "urgent"
concern...but I think it has something to do with seeing concerns about
whether it would be easier to use ".", "!", or "~" for a non-whitespace
indent character, based in part whether or not it would conflict with Arc;
or using ".", "\", "\\" vs "..." for a GROUP concept, except that "..." may
be incompatible with Scheme (I don't know for sure, since I've never
studies Scheme, but it seems to be, based on code examples I've seen); for
that matter, I even have a desire to create a new Lispy language, and where
it would make no sense to use "." for whitespace in Common Lisp or Scheme,
it might make a lot of sense in a language whose parser is being put
together from the ground up.
Also, having said all this, I think we're sort-of headed towards this
direction when talking about "GROUP", "SPLICE", etc., concepts; and since
we have a goal of having a new spec by July 31, I *certainly* don't think
that "Separating Rules from Syntax" should be a goal for this particular
spec--indeed, it could probably be written independently of the spec. :-)
For that matter, such a spec would probably do well starting out discussing
just what goes into a "classical" s-expr. (No matter how popular t-exprs
become, I'm going to hazard a guess that it will always be useful to have a
simpler "s-expr" concept to build on and to fall back on...)
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
