Neil Toronto:
> > One thing I don't understand is the need for full
> > backward compatibility. Is it because readers are global, and you can't
> > switch them out per-file - or at least, you can't expect people to do that?
Alan Manuel Gloria:
> I think he wants to add this as part of the LISP language. If
> swt-expr readers are somehow inherently incapable of reading s-expr --
> well, LISP's without support for s-expr syntaxes seem to have failed
> to really capture the attention of LISP users e.g. Dylan. If he can
> somehow keep s-expr syntax while supporting m-expr syntax, he hopes to
> attract both oldtimers who are madly in love with s-exprs, and
> newcomers who can't figure out all those parens.
> As far as I can tell, swt-expr is an attempt to get m-expr syntax
> while retaining the possibility of reading s-expr syntax.
*Bing*. That's it, exactly.
Hmm, we have a mind reader on the list. Better keep all my thoughts G-rated
:-).
> Finally - conventional wisdom claims that LISP's most important power,
> macros, is possible only because of the sheer number of parens in the
> s-expr syntax (I would contend this, though). So, just in case macros
> really, really need s-expr - better keep it in, since we don't want to
> accidentally cut LISP's power.
Macros are actually no big deal to support. The problem is the vast amount of
existing software which use s-expressions, as they currently exist. New
languages are really, really painful to start, while tweaks on existing ones
are much easier to get going. So if there are _reasonable_ compromises for
backwards-combatibility (grin), I certainly want to entertain them.
Actually, one nifty result of making unprefixed (...) mean 's-expression' is
that it's very easy to describe the mappings. I.e., "f(x {2 + 2})" maps to "(f
x (+ 2 2))"... notice that this is completely unambiguous.
> Basically, macros are so important that we'll even program in s-expr
> if necessary, but if you can, say, do something like this, so much the
> better:
> defmacro foo (x)
> if check-if-valid(x)
> `(let
> ( (some-foo ,x))
> (do-something some-foo))
> error "x is not valid"
Can-do. Note that ' and ` and , all work already. However, that first "("
disables indentation as being meaningful until the closing ")". You can use '
and other markers without "(" at all, that works too.
> > If that's the case, maybe the right thing to do would be some sort of
> > file-level block delimiter rather than expression-level enclosures. I'd
> > be perfectly happy with something like this:
> >
> > *readable* (or some other non-syntactic marker)
> *readable* is a valid symbol in LISP. Possibly #readable#, since # is
> an "escape character" to the reader.
... (e.g.)
> > *unreadable* (or some less snarky non-syntactic marker :D)
:-) :-).
Hmm, the snarkiness alone makes it worth considering :-).
However...
File-level settings turn out to be MUCH trickier to implement than you'd think.
The problem is, once again, backward-compatibility.
All traditional Lisp systems build on a primitive function named "read", which
takes an optional parameter of where to read from. This function returns an
s-expression, and NOTHING ELSE. Callers do NOT expect to get back some sort of
status information, which they then pass back for the next call. This means
that the "clean" solution, where the status of the reader is not stored inside
the reader, is impractical unless you're writing a new set of languages from
scratch. (Yeah, I know about Hakell monads, and Prolog's syntax-reading
gimmicks to add new parameters. See "new set of languages from scratch".)
So if we aren't going to rewrite everything, there are file-level settings, and
they have be stored INSIDE the "read". Except that stuff gets hairy here. What
exactly a "port" is (where you can get data from) isn't exactly spelled out in
great detail, and it's DEFINITELY not common across Lisp implementations (even
ones that implement the "same" spec). E.G., what if you're reading from a
string? A file which has been opened multiple times? You can do it, sortof,
but it's exceedingly nasty... and thus somewhat unreliable.
What gets REALLY nasty is when you have multiple different layers of meaning in
the SAME string. E.g., you have a language, and a DIFFERENT meta-language, both
using s-expressions (or its equivalent), embedded in the same data stream. You
can have a "readable" version at one layer, but the "unreadable" enabled
simultaneously in the other. There'd be no way for the "read" routine to know
that you've switched how the upper layer is being interpreted, because it's the
same stream. This isn't unusual; Lisp systems typically get used for symbol
manipulation, and they have to manipulate both their own programs, as well as
some higher-level set of symbols (PVS, ACL2, Macsyma, and other systems are
cases in point). You can sortof solve this by having new parameters, ones that
no one will use correctly, so it won't REALLY solve the problem.
I think the "New Jersey" school has a point; if it's hard to implement, that
may be a very good indicator that you're solving the wrong problem. Which is
why I'm a big believer in BOTH group discussions AND implementation; you learn
from both.
I don't think there's a fundamental problem with having a file-level setting;
many languages have such notions. But given how all Lisp systems expect solely
a list as its return (this dates from the 1950s), something so basic is hard to
change in this context.
--- David A. Wheeler
