|[2 earlier articles]|
|Re: Do I need to invent a new type of parser? firstname.lastname@example.org (1992-04-22)|
|Re: Do I need to invent a new type of parser? email@example.com (1992-04-26)|
|Re: Do I need to invent a new type of parser? firstname.lastname@example.org (1992-04-28)|
|Re: Do I need to invent a new type of parser? email@example.com (1992-04-29)|
|Re: Do I need to invent a new type of parser? firstname.lastname@example.org (1992-05-04)|
|Re: Do I need to invent a new type of parser? email@example.com) (1992-05-06)|
|Re: Do I need to invent a new type of parser? firstname.lastname@example.org (1992-05-08)|
|From:||email@example.com (Keith Clarke;W208a)|
|Organization:||Computer Science Dept, QMW, University of London|
|Date:||Fri, 8 May 1992 09:43:50 GMT|
firstname.lastname@example.org (Anton Martin Ertl) writes:
>Some [extensible languages] are alive and kicking:
>Prolog allows defining any token as binary infix or unary pre- or postfix
>operator. (Some version of) ML has a similar feature. And finally there's
>Forth, where you can twist the compiler (and the syntax) as you like.
Standard ML provides infix directors for 2-ary functions, with specified
left/right associativity and precedence. Lazy ML goes further, providing
"concrete data types". These are tree-structures (like Prolog terms) with
user-defined syntax; you can add your own punctuation even when this
clashes with the keywords/punctuation of LML itself. It's handled by extra
delimiters to separate the user-defined construct from the rest of the
program, which must to a large extent avoid the problem of human
readability. Can any of the LML people comment on how useful this
construct has been? Has it been used much?
It *ought* to be useful in language-processing problems where the data
structures are abstract syntax trees. Not only compilers, but theorem
QMW, University of London.
Return to the
Search the comp.compilers archives again.