> LISP works it by (IIRC) passing each token to the "read macros" and 
> seeing if any of them modify it, so it has to be distinguishable 
> somehow.

> FORTH works it by literally letting you read the input stream, 
> as well as calling a specific function when an unparsable word is 
> encountered. So in FORTH, a literal works mostly like your quasi-quoting 
> scheme, except there's no magic characters at the front or end to say 
> "hey, this is quoted."

> Even Erlang has a mechanism to pss the parse tree thru a number of 
> routines each of which takes a parse tree and returns a new parse tree. 
> It isn't quite as flexible as LISP or FORTH, but it lets you add 
> parse-time features pretty easily, like your splice more than anything

Well, there's no law against you writing a Haskell preprocessor in 
Haskell. (Though obviously that's not quite as convinient as the 
compiler automatically running it for you.)

>> You have to tell the compiler what function to use to parse this 
>> stuff, one way or another.
> 
> Yeah, but you shouldn't be putting it inline in the stream. You should 
> be able to say "anything with < on the front and > at the back should 
> parse as an XML tag."

The way Haskell does it has advantages.

1. You can tell that stuff is quoted, and what quoting rule it's using. 
(Pointless for something like a hex number, but damned useful for a 
complex program with a dozen kinds of AST which you might want to quote.)

2. You can't accidentally write a quoting rule which changes the meaning 
of a valid Haskell fragment.

3. The new stuff can have completely different parsing rules to Haskell. 
(Presumably the Lisp, Forth and Erlang methods can't do that.)

If you could write XML tags literally, then an expression like "if x<y 
then if y>z then..." would suddenly parse as an XML tag, which would be 
a Very Bad Thing. Really, having to explicitly say you're doing weird 
stuff isn't so bad.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message