Alpheus Madsen: > 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.
Since this project's purpose *is* to work out syntax (notations), that could be a little challenging :-). We're simply trying to come up with improved syntax/notations, compared to traditional s-expressions, for the structures that are *traditionally* represented using s-expressions. > 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. The s-expression readers for different systems do have some differences, but at their fundamentals, they're all identical. I would expect: (+ 1 2) and '(fun (f a b)) to mean EXACTLY the same thing everywhere. Sure, there are variations on how to represent things (e.g., true and false), but I've been considering those out-of-scope. > 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 agree in one sense, but fundamentally disagree in the sense I think you mean. I do agree that the portions of the various Lisps that differ, such as the spelling of true and false (Scheme #t and #f), would still differ. So in that sense, whatever we do will be "encoded in a variety of syntaxes". But for the rest of it, no, I think it's vital that there be a *single* syntax (at each tier) that can be widely adopted by many Lisp-based systems: 1. If the syntax is mostly the same between many Lisp-based systems, it's more likely to be adopted (and adopted further). Once someone is used to it in one system, they're more likely to want it elsewhere. Being able to keep the syntax in the other system makes it more likely to move. 2. It is critically important that the notation *NOT* be dependent on a particular semantic. That was the downfall of M-expressions and many other notations, too. Once way to prevent that is to create programs in lots of different Lisp-based systems. Look at [Examples], where I code up Common Lisp, Scheme, Clojure, Arc, ACL2, and a host of others. > 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. If something turns out to be impossible, then obviously we need to back down until it's possible. But I think we need to first try for the best, and only when there's a blocker, look for alternatives. Creating examples & coding implementations is a key part of the process, to ensure that our ideas work in the field. While it was tricky to find, the "!" as the non-whitespace indent character and "\\" as the group/split symbol seem to resolve these. The problem with "..." is that Scheme actually uses that for something meaningful. No problem, we just need to choose something different. > 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...) ... > I wouldn't say "configurable" in the sense of "set a flag so that this > function becomes that", so much as "configurable" in the sense of "trying to > get the right syntax for the target Lisp". > For example, while Arc, Scheme and Common Lisp are all Lisps, they each have > different syntax. In some ways, it seems a shame to try to create a > "sweet-expression" system that doesn't allow for the possibility of > recognising these different coding traditions. > For that matter, if I were to dust off a Symbolics Lisp Machine, and I > decided I wanted to use "sweet-expressions" for programming the beast, it > wouldn't be reasonable for me to start e-mailing this list, and saying, "But > I can't use either of '!', '.' or '~' for my Lisp Machine. These are all > reserved symbols! Why don't we use '_' or ':' instead?" > (Let's not rule out the possibility of finding an ancient Lisp Machine being > found in a Babylonian archaeological dig--in which case, a Cuniform > non-whitespace character would be a given! :-) > I suppose what I'm trying to say is that the rules ought to be separated from > the implementation, so that if some weird system comes along, the > "sweet-expression" syntax can use the same principles, when syntax is the > issue. It'd be easy to ensure that in the sample code a few symbols and characters are defined "at the top". E.G., horizontal-whitespace-chars, GROUP=SPLIT symbol, and so on. They're already there, actually, since we've changed our minds :-). We could also ensure that in the formal spec, those terms were specially defined so that if you just COULDN'T use the "standard" syntax on specific system, you could modify it for your specific Lisp system, creating a mostly-compatible syntax that works within the constraints of local conventions. So yes, we could define the syntax using generic terms like "SPLIT symbol". But I think it's important to have a *common* syntax if we can, down to the individual symbols. We've managed to have a basically-common syntax between Common Lisp, Scheme, Clojure, and many others. At *that* level I have hopes we can do the same. Based on the recent discussions, I think we *are* going to achieve that, so we won't need to work out "back off" plan. But to address your concern, let's name the important symbols or characters (SPLIT, GROUP, NON-WHITESPACE-INDENT), so that someone could say, "Sweet expressions, except that @@ is the SPLIT symbol" or whatever. ---- David A. Wheeler ------------------------------------------------------------------------------ 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
