|Designing a language in which a class can define (not just overload) email@example.com (Richard Cartwright) (2003-08-20)|
|Re: Designing a language in which a class can define (not just overloa firstname.lastname@example.org (2003-08-23)|
|Re: Designing a language in which a class can define (not just overloa email@example.com (2003-08-23)|
|Re: Designing a language in which a class can define (not just overloa firstname.lastname@example.org (2003-09-04)|
|Re: Designing a language in which a class can define (not just overloa email@example.com (2003-09-04)|
|Re: Designing a language in which a class can define (not just overloa firstname.lastname@example.org (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:||email@example.com (Michael Tiomkin)|
|Date:||23 Aug 2003 23:15:34 -0400|
|Posted-Date:||23 Aug 2003 23:15:34 EDT|
"Richard Cartwright" <firstname.lastname@example.org> 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
> 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
> 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.
> 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
Search the comp.compilers archives again.