Sorry, keep pressing the wrong button...
---------- Forwarded message ----------
From: Alan Manuel Gloria <[EMAIL PROTECTED]>
Date: Nov 30, 2007 7:39 AM
Subject: Re: [Readable-discuss] Making ndx macros and
sweet-expressions work together
To: [EMAIL PROTECTED]
On Nov 30, 2007 6:05 AM, David A. Wheeler <[EMAIL PROTECTED]> wrote:
> There seem to be two major approaches to making Lisp "easier to read":
> * Macros, primarily for infix support.
> * Modified reader (e.g., sweet-expressions).
>
> I think that through careful definition these approaches can work together.
> Each has their advantages. An infix macro is better for sophisticated
> precedence and ordering support. A modified reader can simplify presentation
> and eliminate many parentheses that a macro-only approach cannot, it enables
> a single interpretation that "works everywhere", and it doesn't require
> constant reference/use of the macro.
>
> My thought is that the sweet-expression reader should have strict rules on
> "what it will treat as infix", and anything else will be "passed through
> as-is". That means that if an expression uses infix operators beyond what
> the sweet-expression reader can handle, just surround it with the macro call,
> and the macro call will see the original list (so IT can process it).
>
> My proposed narrow rules for sweet-expression infix detection:
> 1. Must have an odd number of parameters >= 3 (otherwise you don't have
> enough parameters to HAVE an infix operation)
> 2. The second parameter matches the infix pattern ("and", "or", or only
> certain punctuation)
Not unless the infix pattern can be changed by the programmer.
Because in the future, I (or someone) might make a "convoke" (or
something) infix operator. And the act of declaring a new infix
operator should contact both the reader and the macro.
Declaring a "pattern" to match a string from an input stream just
feels so Perlish, to me.
> 3. The odd parameters do NOT match the infix pattern. So {a * - b} will NOT
> be processed by the sweet-expression built-in infix handler
> 4. All even parameters are equal, e.g., {1 + 2 + 3 + 4} becomes (+ 1 2 3 4).
> So {2 + 3 * 4} will just become (2 + 3 * 4) which will hopefully be later
> processed by an infix macro.
> A list that doesn't meet these criteria are passed on as-is, without an error
> message (for possible later manipulation by a macro).
Instead of doing *any* infix fixing in the reader at all, why not just
delegate the whole mess of infix-fixing to the macro?
i.e. sweet-read() sees {foo bar batz}, it outputs (infix-macro foo bar batz)
>
> A disadvantage to this is that "bad" expressions won't be detected by the
> sweet-expression reader - instead, they'll be passed through to an infix
> macro processor (which might not be used!). However, "bad" expressions are
> ALREADY undetected by Lisp processors (Lisp doesn't do that kind of checking
> normally), so this is nothing new :-).
>
> --- David A. Wheeler
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Readable-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/readable-discuss
>
