Related articles |
---|
Designing a language in which a class can define (not just overload) news@chunk.com.au (Richard Cartwright) (2003-08-20) |
Re: Designing a language in which a class can define (not just overloa joshualevy@yahoo.com (2003-08-23) |
Re: Designing a language in which a class can define (not just overloa tmk@netvision.net.il (2003-08-23) |
Re: Designing a language in which a class can define (not just overloa rkrayhawk@aol.com (2003-09-04) |
Re: Designing a language in which a class can define (not just overloa vidar@hokstad.name (2003-09-04) |
Re: Designing a language in which a class can define (not just overloa nmm1@cus.cam.ac.uk (2003-09-09) |
Re: Designing a language in which a class can define (not just overloa derkgwen@HotPOP.com (Derk Gwen) (2003-09-09) |
From: | tmk@netvision.net.il (Michael Tiomkin) |
Newsgroups: | comp.compilers |
Date: | 23 Aug 2003 23:15:34 -0400 |
Organization: | http://groups.google.com/ |
References: | 03-08-062 |
Keywords: | syntax, design |
Posted-Date: | 23 Aug 2003 23:15:34 EDT |
"Richard Cartwright" <news@chunk.com.au> wrote
> I have OO language design in my head in which it is possible for a
> class to define new operators. I'm thinking of something like this
> (adapted to C++-like syntax for purposes of illustration):
>
> class vector3
> {
> public:
> float operator "dot" (const vector3& v) const precedence 5;
> vector3 operator "cross" (const vector3& v) const precedence 5;
> };
>
> Which could then be used like this:
> vector3 a, b, c;
> float f;
> c = a cross b;
> f = a dot b;
>
> Since the grammar for this language is very much context sensitive,
> rather than context free, I can't use the traditional finite state
> machine approach of YACC or Bison to implement a compiler for this
> language.
>
> Could anyone point me toward any resources for implementing such a > language?
Look at a parser of Prolog (early 1980s). In Prolog you can
define/remove operators and set their priorities at run time, and the
parser looks at the operator table whenever it sees an identifier.
If your parser will keep a partial parse tree for an expression,
you will be able to do a simple update with moving up the tree
and doing rotations until you meet an operator of a lower degree.
The only problem is to let the parser know that the parse tree
changed!-) A parser of a Prolog expression does not need to know
any semantic information about the expression, and for Prolog
parser that gets a list of tokens and returns a parse tree
changing the parse tree on the fly is very simple. For a more
complicated grammar this might be less doable.
Try to find a parser generator based on parse tree transformations.
If you have to use yacc, build the 'wrong' parse trees of expressions -
you can transfer from lex the operators with some default priority,
and then, after the parsing, do the postprocessing of rotating the tree
and deriving the expression types.
Michael
> Thanks,
> Richard Cartwright
> [Write your parser with generic expression rules like this:
>
> expr: expr OP5 expr /* precedence 5 operator */
>
> Then when you define a new operator at level 5, have the lexer return
> an OP5 for it with semantic info so the parser can figure out which
> operator it was. I'm pretty sure this trick was used in extensible
> languages before 1980. -John]
Unfortunately, this will need 100 rules for 100 priorities.
[It's true. But since a language with 100 priorities would be unusuable,
so what? -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.