[Prev][Next][Index][Thread]

Re: "Lisp" syntax differences

In article <B5C93AFC.7364%page@best.NOSPAM.com>, Chris Page 
<page@best.NOSPAM.com> wrote:

> There's been a raging discussion on comp.lang.lisp about Lisp syntax. 
> Dylan was mentioned a number of times, not surprisingly.

... including the odd Lisp person [1] saying that they thought Dylan was 
the logical sucessor to Lisp until it got the foolish infix syntax.


> It got me wondering: What, exactly, are the "hard" differences
> between Dylan and Lisp syntax? By that I mean, for example, if you
> wanted to convert between the two, what cannot be converted? Note
> that I'm just talking about syntax differences.

Expressions are no problem -- just rearrange.

All the built-in macros tend to need a translation rule of their own.  
It's not at all hard, it just needs to be done.


The problem is user-defined macros.  I assert, without proof, that the 
person who writes the macro would need to explicitly provide a rule to 
translate from infix syntax to prefix syntax and/or the reverse.  If you 
assume that the compiler actually works with one syntax or the other 
then you wouldn't need to actually implement the macro twice (though for 
simple macros this might be he easiest thing to do).

Here's the "if" macro from Gwydion Dylan's runtime library:

define macro if
    { if (?x:expression) ?:body ?elses end }
      => make-if({ ?x }, { ?body }, { ?elses })
  elses:
    { else ?:body } => { ?body }
    { elseif (?x:expression) ?:body ... }
      => make-if({ ?x }, { ?body }, { ... })
    { } => { #f };
end;


This is quite different to what was available in the prefix language 
described in the original book which had essentially the same "if" and 
"cond" as Scheme instead of if/the/elseif/else.  As well as the "if" 
form taking only a consequent and an alternate, each was also a single 
expression and you had to use (begin ... ... ) to group multiple 
expresions.

It's pretty clear that you could replace the RHS of the rules in the 
above macro with rewritings that were prefix Dylan instead of magic 
compiler built-ins.  Doing so *intelligently*, so as to produce 
idiomatic Lisp that chose between "if" and "cond" as appropriate would 
be more of a chore.  Not that hard for a person, but totally impossible 
to do automatically from only the above macro defintion.


> For example, here's a method from the original Dylan manual, page 81 
> [with slight modifications for comparison]:
> 
>   (define-method newtons-sqrt (x)
>      (bind-methods ((sqrt1 (guess)
>                        (if (close-enough? guess)
>                            guess
>                            (sqrt1 (improve guess))))
>                     (close-enough? (guess)
>                        (< (abs (- (* guess guess) x)) .0001))
>                     (improve (guess)
>                        (/ (+ guess (/ x guess)) 2)))
>             (sqrt1 1)))

This looks to be exactly the first example program developed in SICP. [2]


> What I'm thinking about, however, is not necessarily supporting both
> syntaxes in a compiler, but abstracting the syntax out so that code could 
> be presented and edited in either syntax, but perhaps fed to the compiler 
> using just one of them, or something else entirely.

Accepting both syntaxes is less work than automatic bi-directional 
translation between them, but even that requires explicit help from 
anyone who writes a macro.

-- Bruce


[1] no comment :-)

[2] SICP = _Structure and Interpretation of Computer Programs_, a^Hthe 
compsci text using Scheme.
References: