Re: Designing a language in which a class can define (not just overload) operators

tmk@netvision.net.il (Michael Tiomkin)
23 Aug 2003 23:15:34 -0400

          From comp.compilers

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)
| List of all articles for this month |
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]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.