🚀 go-pugleaf

In article <1991Jun26.223026.13792@watserv1.waterloo.edu>, mhcoffin@tolstoy.waterloo.edu (Michael Coffin) writes:
> There's at least one advantage to the lisp syntax, and that advantage
> is important to lispers, although others may not find it important.
> Lisp programs have a simple, logical representation as data within
> lisp: a program is a list of lists, i.e., a tree.  

Lisp has two features: an internal form for programs, and a (over:-) simple
syntax.  I think with an "infix Scheme," having a well-defined internal 
form would give you most of the power.  You'd need a "code-constant" or
"internal-form-of-this-quoted-code-fragment" construct, e.g.,

x = quote {
    function ( a, b ) {
        return a+b;
        }
    };

(That's not a lambda expression, it's a quoted lambda expression.)

> In most programming
> languages, source-to-source transformations are a pain because to do
> anything general you have to parse the language into some idiosyncratic
> form, manipulate it, and then translate back into the source language.

If the compiler (or a library routine) can do the parsing,
and there's a standard (not idiosyncratic) internal form,
and a library routine can print programs,
(or else, you don't go to ASCII, but stay in internal form),
then the situation would be pretty much the same as with Lisp.
Lisp has to be parsed and printed, too, if you're working with ASCII.  

> It's also why lisp has general-purpose syntax extension
> that integrates neatly with the rest of the language (e.g.,
> extend-syntax) while C has a crude, tacked-on macro processor
> pre-pass.

I've always wanted "semantic macros" instead of text macros, for C.

--Steve