Operator implementation

2 views
Skip to first unread message

Felipe Pena

unread,
Jan 4, 2012, 5:04:10 AM1/4/12
to cleve...@googlegroups.com
Hi guys,

I'm working in the operator implementation for types using it like a
common method call. This will make the thing easier to come with an
operator overloading in user-level. And this is just like as did in
the TODO language.

I've created the branch in my repo:
https://github.com/felipensp/clever/tree/operator

In this ways, we won't need a opcode handler for each binary
expression. I.e. 'x + y' will yields a method call to 'x' type's
method '$+$'. Hence, we will use the argument types to check if a
determined type accepts operation with another type, as in actual
method call.

x + y => (type* of x)->$+$(x, y)


From an optimization view (constant propagation), it's not affected,
we can do it without problem yet.

@Murilo
I guess we don't need a separated Operator map, It's more cleaner if
we just use the method stuff. So I changed a bit the idea.


Thoughts?

--
Regards,
Felipe Pena

Murilo Adriano Vasconcelos

unread,
Jan 4, 2012, 9:33:25 AM1/4/12
to cleve...@googlegroups.com
Hi,

2012/1/4 Felipe Pena <feli...@gmail.com>

Hi guys,

I'm working in the operator implementation for types using it like a
common method call. This will make the thing easier to come with an
operator overloading in user-level. And this is just like as did in
the TODO language.

I've created the branch in my repo:
https://github.com/felipensp/clever/tree/operator

In this ways, we won't need a opcode handler for each binary
expression. I.e. 'x + y' will yields a method call to 'x' type's
method '$+$'. Hence, we will use the argument types to check if a
determined type accepts operation with another type, as in actual
method call.

x + y => (type* of x)->$+$(x, y)


From an optimization view (constant propagation), it's not affected,
we can do it without problem yet.

It is nice to see that you're working on that. I have to say that the point to do the operator implementation this way is that we can check the operands types with the TypeCheckerVisitor like a simple method call. That enable us to use operator overloading and check before the 'compilation' with the TypeCheckerVisitor.
 

@Murilo
I guess we don't need a separated Operator map, It's more cleaner if
we just use the method stuff. So I changed a bit the idea.


That's ok! The idea in separating was more about semantics and speed than everything else. I remember that you were worried about the performance of this strategy. 
 

Thoughts?

--
Regards,
Felipe Pena

It seems good to me, go ahead!

--
Murilo Adriano Vasconcelos
http://murilo.wordpress.com
Reply all
Reply to author
Forward
0 new messages