Change other languages behaviour from own Truffle language
christian.humer at gmail.com
Fri Apr 20 09:37:20 UTC 2018
I think Jaroslav already gave a good answer.
I'd like the add that the problem with the proposed approach is that
interop is not a full abstraction of the target language. It only abstracts
part of the target language functionality. While we have the aim to close
this gap as much as possible, you will experience a difference when you
So while I think this it is a good approach for a research prototype, the
challenge will be to support it fully to preserve full language semantics.
Also it requires to wrap all the objects which might come at a cost.
If we are willing the change the languages for this feature, more solutions
to this problem become available. For example, we could also use internal
keys in interop. I am roughly thinking about something like magic methods.
There could be some convention for an object that if it has an internal key
called "__call_handler__" that it invokes that handler if its defined on
the object. The language would need to implement support for this magic
method for all of its dispatches.
A third option that comes to my mind, would be to standardize invokes
(receiver, target, arguments) in Truffle and allow instrumentation of those
as cross cutting concern.
- Christian Humer
On Fri, Apr 20, 2018 at 9:40 AM Jaroslav Tulach <jaroslav.tulach at oracle.com>
> Hello Lars,
> this is interesting topic.
> On pátek 20. dubna 2018 6:22:29 CEST Lars Schuetze wrote:
> > We currently do research on role-oriented programming languages.
> > Role-orientation is an enhancement of object-orientation such that
> > can play roles.
> I assume [DCI](http://wiki.apidesign.org/wiki/DCI) is an example of such
> > By doing so, their type and behaviour (ie., method
> > dispatch) is changed. For example, first a.m() dispatches to method m
> > implemented in class A. But after playing the role r, a.m() will be
> > dispatched to method f in R.
> "after playing" or "while playing"? As far as I know in DCI the objects
> can be
> added to an "interaction" and while they are in the interaction they play
> roles. Outside of (and "after") the interaction the objects behave
> > Also, there exist operators like in
> > aspect-orientation that can change instances of classes in a crosscutting
> > manner. Roles themselves define methods etc. just like normal classes.
> > However, they cannot exist on their own. They always have to be played by
> > objects.
> > Currently, there exist some implementations for these languages. For
> > example, SCROLL (Scala Roles Language)  is implemented in Scala using
> > the Dynamic trait and a handwritten dispatch implementation in userland
> > cope with the different memory model of roles.
> Eclipse ObjectTeams on the
> > other hand is implemented in Java as an extension of JDT and also
> employs a
> > load time compiler built with the ASM library. It is able to adapt
> > and compiled applications with roles. It also has a handwritten runtime
> > userland.
> Java and Scala are statically compiled languages and the JVM doesn't make
> kind of meta-programming completely easy. (Truffle) Dynamic languages may
> more suited for this kind of manipulations by their natural virtue.
> > My question would be if by using Truffle we would be able to implement
> > a behaviour that when calling a method a.m() in language A it will be
> > dispatched to a method r.f() in our language?
> I believe it could be done with the decorator. All Truffle languages are
> supposed to work with [foreign objects](
> - if you can wrap/decorate the
> object "a" from language A by your instance and pass it back, you will
> everything including dispatch.
> > I see that we could use
> > Truffle to implement a language that can have that behaviour in its own
> > I don’t see if it is possible to change the behaviour of other languages
> > from ours.
> By passing your own instance of `TruffleObject` into a foreign language
> basically take over all the [classical operations/messages](http://
> languages perform. Invocation, property access, etc. all gets routed
> you and you can perform any magic you need.
> I'd suggest you start with [MessageResolution](
> sample. That
> should give you overview of the possibilities. Good luck.
More information about the graal-dev