A natural extension (to me, anyway) would be to modify the parser to
allow actual operators as method names - removing the need for the map.
As in:
method ||(a)
return this.stringValue () || string(a)
end
This should not be very difficult to do. I did think about this as you had suggested it earlier and it thought about implementing it by adding new production rules to the "method" part of unicon's grammer. Here is how I think it could have been implemented.
from unigram.y
methhead: METHOD IDENT LPAREN arglist RPAREN {
$$ := Method( , , , , , $2.s, $4, $1.s, $3, $5)
} ;
modify this rule to handle the case where we have operator tokens instead of ident tokens. Then translate the operator token to the predefined name.
It is not hard to add the procedure|| also
However operator overloading is impelented by actually changing the main opcode processing loop in interp.r. In case of objects (I am messing the terminology here and I am worried my advisor might ask me to return my M.S. ) without operator overloading we are going to get a runtime error. With operator overloading before executing the opcode corresponding to each operator we check if we are dealing with an object. In this case we perform the method lookup and if the method lookup fails we have the original runitme error. In the non object scenario the overhead is just the comparison to check if the operand was an object. My initial benchmarks showed that the modified runtime did not cause any noticable slowdown of normal unicon code.
However if we generalize this to perform a proc lookup for all types then this will slow the interpretation of the usual code path down.
regards
Sudarshan
On 9/21/06, Steve Wampler <[EMAIL PROTECTED]
> wrote:
Sudarshan Gaikaiwari wrote:
> Hi
>
> I worked on operator overloading for Unicon while I was at NMSU.
>
> I believe my changes are checked into the Unicon cvs repository on
> sourceforge.
> Operator overloading is not turned on be default (yet) rightly as you will
> see from the explanation below.
>
> To turn on operator overloading get the sources from cvs and
>
> 1. go to src/h/define.h and uncomment OVLD
> 2. build both icont and iconx.
>
> See the attached file uniconovld.icn for an example of how to use the
> operator overloading feature. I have also attached a file that has the map
> of operators to method names.
This is *really* interesting. I've had a number of occasions where
overloading would be nice! It's going to be fun playing with this
when I get some time.
A natural extension (to me, anyway) would be to modify the parser to
allow actual operators as method names - removing the need for the map.
As in:
method ||(a)
return this.stringValue() || string(a)
end
Did you by any chance look at this? Do you have a feel how hard this
would be to implement? Is anyone interested in doing so?
And of course, given that syntax, how hard could it be to add
procedures also?:
procedure ||(a,b)
returm string(a)||string(b)
end
--
Steve Wampler {[EMAIL PROTECTED]}
The gods that smiled upon your birth are laughing now. -- fortune cookie
--
Sudarshan Gaikaiwari
www.sudarshan.org
[EMAIL PROTECTED]
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
