(Alan Manuel Gloria posted only to me, but it's clear it was intended for the
whole list, so here it is reposted... with a few comments by me.)
Alan Manuel Gloria:
> > 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.
> >
On Nov 27, 2007 2:32 PM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> > *Bing*. That's it, exactly.
> >
> > Hmm, we have a mind reader on the list. Better keep all my thoughts
> > G-rated :-).
> LOL don't worry, I scanned your mind, all your non-G-rated thoughts
> aren't even up to my level of non-G-rated thoughts!
> > > 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.
>
> defmacro operation-on-two-exprs (a o b)
> `{,a ,o ,b}
>
> expand-macro-1 '(operation-on-two-exprs a + b)
> => ?
> expand-macro-1 '(operation-on-two-exprs a bar b)
> => ?
>
> From my understanding sweet-expressions it seems it does all
> translations before macros even work. So I suppose that in a macro's
> `(,) some features just can't be used, as shown above.
Correct. I don't see how to "fix" that. That drawback should be documented at
least, because that IS unfortunate. Basically, you CAN use infix operations in
macro definitions - no problem. You can use infix operations in parameters TO
macros - no problem. But if the function names THEMSELVES are parameters,
there's no way to detect that they are infix operators at (read) time.... so
the macro cannot use functions-as-parameters as infix operators. There's
really no easy way around this if you determine infixness at read time.
So, if you define a macro where the FUNCTION is a passed-in parameter, you MUST
use prefix notation and not infix notation to call the function. That's
unfortunate, but since this only affects _defining_ macros, this isn't too bad.
After all, _existing_ Lisp systems already have this limitation :-).
A solution is to use macros to do this translation, which is of course what nfx
and friends do. But they don't handle the other things I'm trying to do. I
don't see a problem with having several different approaches for making
Lisp-like languages easier to use... at least:
1. A simple macro that easily fits into Lisp-like systems
2. A replacement for (read) that does more, but thus requires more mechanisms.
...
> > 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.
> First '(' including function-prefixed f(...), or just naked '(' (f
> ...)? I'd assume the naked '(' only.
Yes, correct.
...
> > 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.
> Not to mention the potential headaches of multithreading... "so,
> which (read...) function state did you mean...?"
In the case of multiple threads doing I/O with the same source, the program
better ALREADY have a method for deconflicting the threads, or the program is
toast anyway :-). But clearly, if there are multiple threads, a "read" that
maintains per-port state has to protect that state from multiple threads. So
now we have a global data structure that's consulted on every read, which has
to be protected from multiple-thread access. Not impossible, but that's a lot
of complexity that can be eliminated entirely by NOT supporting a
per-stream-state interface.
--- David A. Wheeler
