Orchid XP v8 wrote:
> The way Haskell does it has advantages.

No question.

> 1. You can tell that stuff is quoted, and what quoting rule it's using. 

Trivially true of LISP and FORTH, too. LISP syntax is so simple it's hard 
not to know what you're quoting, and in FORTH *everything* works that way, 
including all the "normal" stuff.

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

Yeah. That's the only thing you *can* do in Erlang, which is kind of odd.

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

Erlang, no, because it's already parsed when you get it. FORTH and LISP, 
yes, it's exactly the point of it.  If you can read arbitrary amount of 
input off the input file as you're compiling, you can pretty much completely 
change the parsing rules.

Of course, the parsing rule for FORTH is "read up to the next whitespace, 
then run that function. Repeat."  So the whole point of FORTH is that there 
isn't any syntax beyond that defined by the libraries. (For example, the 
function to define functions, and the "if" statement, are both library 
routines.)  It can make things rough, tho.

> 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.

Yeah, that was just an example I saw. Obviously you'd have to take care. I 
haven't used Erlang enough to understand the subtleties of its mechanisms.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message