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

I have joined this thread a little late, so I'll quote a recent post verbatim
below, and it includes a trace back to the start.


The Software Composition Group Archive is a relevant site,


http://www.iam.unibe.ch/~scg/Archive/


as it includes "Oscar Nierstrasz' publications (also pre 1994)"


http://www.iam.unibe.ch/~oscar/pubs.html




I'll mention here a few of the many entries on that page alone of a site that
is generous to say the least. Relevant to posted comments, perhaps might be
the following. We need to determine if the poster recalls Hybrid as the
language that had the various prefix/postfix/infix he is trying to lead the
original poster to. Even if not, the leads here will take any interested party
to material that can set those notions up and also help deal with precedence in
their solution (not a bad thing to consider first before you start combining
such facilities).


quoting the named SCG page :


87.Dimitri Konstantas, Oscar Nierstrasz and Michael Papathomas,
An Implementation of Hybrid, a Concurrent Object-Oriented Language,
Technical Report, Centre Universitaire d'Informatique, University of
Geneva, June 1988, Active Object Environments. abstract PDF postscript


http://www.iam.unibe.ch/~scg/Archive/OSG/Kons88aHybridImplementation.pdf






90.Oscar Nierstrasz, Hybrid A Language for Programming with Active
Objects, Technical Report, Centre Universitaire d'Informatique,
University of Geneva, March 1987, Objects and Things. abstract PDF


http://www.iam.unibe.ch/~scg/Archive/OSG/Nier85bHybridUnified.pdf




Note that this may be the item the recent poster has in mind, I do not know for
sure:


A pdf on Hybird, A Unified Object-Oriented System


http://www.iam.unibe.ch/~scg/Archive/OSG/Nier85bHybridUnified.pdf


I find the text in this as follows...


"... The scheme used in Hybrid is to declare operators explicity as
prefix, postfix or infix. ... "




If you are at all interested in Active Object or temporal scripting you will
find this site very disctracting! I could not help but gain an
increased sense of the
leadership that has come from Geneva in this
area.


Interested parties should definitely pursue the many fine ACM articles on the
several pages available here. But I am left a little uncertain that I am
finding the actual article the the more recent poster had in mind as the
thought was that the it was CACM circa 84-87.


Also the original poster may want more of the yacc and lex material itself and
I am not sure these leads get there. But that because, having found this stuff
I have a bit more reading to do myself. ut clearly the history of the Hybrid
implementation can be fairly well seen in the material that is so graciously
available on this site. Hybrid looks relevant to the original posters
challenge.


Best Wishes,
Bob Rayhawk
RKRayhawk@aol.


I will quote the entirety of the more recent post below, which post quotes the
original post as well




joshualevy@yahoo.com (Joshua Levy)
Date: 8/23/03 10:14 PM EST
in response to


joshualevy@yahoo.com (Joshua Levy)
Date: 8/23/03 10:14 PM EST


said
<<
"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?


I have a dim memory of a paper published in CACM in the 1984-1987 time
frame, which solved this problem by forcing new infix operators to
start and end with dots, while new prefix operators would end with a
dot and postfix operators would start with a dot.


In your example "cross" and "dot" would actually be .cross. and .dot.,
like this:
        c = a .cross. b;
        f = a .dot. b;


If you wanted to define a prefix operator which doubled its argument, it
would be called double., and would be used like this:
        x = double. 17 ;
If you wanted a posfix, round down operator, it could be this:
        i = 1.345 .roundedDown ;


They were able to build their parser using yacc and lex, as I remember.
The key is that the lexer can identify any new operator, including the
not-yet-defined ones.




>>

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