Re: MzScheme and SML

[Michael Vanier <mvanier@bbb.caltech.edu>]

> X-Authentication-Warning: fast.cs.utah.edu: majordom set sender to owner-plt-scheme@flux.cs.utah.edu using -f
> X-Sender: clements@cs.rice.edu (Unverified)
> Date: Sat, 17 Feb 2001 14:01:16 -0600
> From: John Clements <clements@cs.rice.edu>
> Cc: plt-scheme@fast.cs.utah.edu
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> Sender: owner-plt-scheme@fast.cs.utah.edu
> Precedence: bulk
> 
> >
> >This interests me.  Here is a quote from Andrew Appel of Princeton, one of
> >SML's designers, commenting on SML's lack of macros:
> >
> >     This is clearly an advantage, not a disadvantage.  For the programmer
> >     to have to calculate a string-to-string rewrite of the program before
> >     any semantic analysis invites problems of the worst kind.  Where macros
> >     are used to attain the effect of in-line expansion of functions, they
> >     are doing something that should be done by an optimizing compiler.
> >     Where macros are used to attain call-by-name, the effect can be
> >     acheived by passing a suspension as an argument; in ML this is written
> >     with the syntax fn()=> which though admittedly ugly is fairly concise,
> >     and is better than tolerating the semantic havoc wrought by macros.
> >
> >     [From "A critique of Standard ML", 1992]
> 
> One other point, perhaps already noted: the paragraph reads well, but 
> dodges the question: his specific criticism of macros is confined to 
> the phrase "semantic havoc"; the rest of the paragraph is devoted to 
> explaining how to work around them.  I've written many paragraphs 
> like this myself, and they've generally arisen when I am unable to 
> come up with a more detailed criticism.
> 
> Of course, I'm reading this paragraph out of context; the surrounding 
> text may address these issues more precisely.
> 
> john clements
> 

Actually, the paper has nothing more to say about macros.  Here is the URL
for the paper, which is well worth reading anyway (and quite short):

http://ncstrl.cs.princeton.edu/expand.php?id=TR-364-92

Matthias' comments re the difficulty of reconciling type-inferencing and
macros are very interesting.  I've always had the sneaking suspicion that
there must be a technical, not a religious, reason why ML dialects shun
macros while lisp dialects embrace them.  But if this is the case, how does
MrSpidey handle type information across macro boundaries?

And on a completely unrelated note, is the MrSpidey source code available
online?  All I can find is the .plt file.

Mike