graal-dev Digest, Vol 74, Issue 16

Tue Jun 5 11:05:52 UTC 2018

Hello Jaroslav, hello Christian,

Thanks for your responses and sorry for my long delayed answer.
Comments are in between your answers.

Cheers,
Lars Schütze

------------------------------

Message: 3
Date: Fri, 20 Apr 2018 09:40:09 +0200
From: Jaroslav Tulach <jaroslav.tulach at oracle.com<mailto:jaroslav.tulach at oracle.com>>
To: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
Subject: Re: Change other languages behaviour from own Truffle
language
Message-ID: <3465599.iYtrGxq7Rf at pracovni>
Content-Type: text/plain; charset="UTF-8"

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 objects
can play roles.

I assume [DCI](http://wiki.apidesign.org/wiki/DCI) is an example of such role
orientation.

Yes, DCI is one of the early examples, ie., the program can be composed out of parts that are modelled in isolation (ie. grouped wrt. their context). Well known implementations in programming languages are Object Teams / Java [OTJ](https://www.eclipse.org/objectteams/) or another implementation of one of my colleagues named [SCROLL](https://github.com/max-leuthaeuser/SCROLL). They both implement roles and context (the latter is named Teams in OTJ, Compartment in SCROLL). However, OTJ resembles crosscutting (ie. aspect-oriented) roles, where SCROLL resembles fine-grained (ie. like dynamic programming languages) roles that are bound to individual objects. They both implement roles from the different ends of a scale.

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 the
roles. Outside of (and "after") the interaction the objects behave normally.

Actually, I meant something “after beginning to play” because roles can also be stopped playing. This is similar to DCI interactions. However, for OTJ role types define a priori which class is playing that role (e.g., class RoleType playedBy SomeSpecificClass) while SCROLL allows to play roles by different objects of different types. This resembles dynamic programming languages.

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) [1] is implemented in Scala using
the Dynamic trait and a handwritten dispatch implementation in userland to
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 existing
and compiled applications with roles. It also has a handwritten runtime in
userland.

Java and Scala are statically compiled languages and the JVM doesn't make this
kind of meta-programming completely easy. (Truffle) Dynamic languages may be
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 such
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](http://www.graalvm.org/truffle/javadoc/
com/oracle/truffle/api/interop/TruffleObject.html] - if you can wrap/decorate the
object "a" from language A by your instance and pass it back, you will control
everything including dispatch.

The decorator pattern is also a possible implementation for roles in object-oriented programming. This also is similar to composition filters (ie. the filters decide how messages are passed) which also allow to implement some notion of roles.

I see that we could use
Truffle to implement a language that can have that behaviour in its own but
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 you
basically take over all the [classical operations/messages](http://
www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/Message.html<http://www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/Message.html>)
languages perform. Invocation, property access, etc. all gets routed through
you and you can perform any magic you need.

I'd suggest you start with [MessageResolution](http://www.graalvm.org/truffle/
javadoc/com/oracle/truffle/api/interop/MessageResolution.html) sample. That
should give you overview of the possibilities. Good luck.

-jt

------------------------------

Message: 4
Date: Fri, 20 Apr 2018 09:37:20 +0000
From: Christian Humer <christian.humer at gmail.com<mailto:christian.humer at gmail.com>>
To: Lars Sch?tze <lars.schuetze at tu-dresden.de<mailto:lars.schuetze at tu-dresden.de>>
Cc: graal-dev at openjdk.java.net<mailto:graal-dev at openjdk.java.net>
Subject: Re: Change other languages behaviour from own Truffle
language
Message-ID:
<CAK_HDSciDpfx3fB8TnCoo3=Pc3KbsrkWfhdw=SN4xKzAUxps-A at mail.gmail.com<mailto:CAK_HDSciDpfx3fB8TnCoo3=Pc3KbsrkWfhdw=SN4xKzAUxps-A at mail.gmail.com>>
Content-Type: text/plain; charset="UTF-8"

Hi Lars,

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
take, e.g. a JavaScript object wrap it using your own TruffleObject to
intercept the behavior and then pass it again to JavaScript. The reason is
that JavaScript handles JavaScript objects different to interop objects.

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.

Current implementations already pay a high cost for these features (and possible memory leaks) because context’s need to store instances of classes that are already playing instances of roles (ie. state is preserved and stored in instances). For example, because of features provided by SCROLL it stores a view of the object graph again in the runtime.

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.

Sounds interesting, if the object does not play multiple roles at once. Otherwise, I think we need such a “__call_handler__” for each active context the object is part of. Normally, the partial order of functions is defined by the order of context activation (ie. least activated context has highest priority), but SCROLL allows user defined dispatch queries which allow a reordering PER roleplaying object by user-defined dispatch queries.

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.

That would be awesome.

Cheers,

- Christian Humer

On Fri, Apr 20, 2018 at 9:40 AM Jaroslav Tulach <jaroslav.tulach at oracle.com<mailto:jaroslav.tulach at oracle.com>>
wrote:

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
objects
can play roles.

I assume [DCI](http://wiki.apidesign.org/wiki/DCI) is an example of such
role
orientation.

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
the
roles. Outside of (and "after") the interaction the objects behave
normally.

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) [1] is implemented in Scala using
the Dynamic trait and a handwritten dispatch implementation in userland
to
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
existing
and compiled applications with roles. It also has a handwritten runtime
in
userland.

Java and Scala are statically compiled languages and the JVM doesn't make
this
kind of meta-programming completely easy. (Truffle) Dynamic languages may
be
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
such
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](
http://www.graalvm.org/truffle/javadoc/
com/oracle/truffle/api/interop/TruffleObject.html
<http://www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/TruffleObject.html>]
- if you can wrap/decorate the
object "a" from language A by your instance and pass it back, you will
control
everything including dispatch.

I see that we could use
Truffle to implement a language that can have that behaviour in its own
but
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
you
basically take over all the [classical operations/messages](http://
www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/Message.html)

languages perform. Invocation, property access, etc. all gets routed
through
you and you can perform any magic you need.

I'd suggest you start with [MessageResolution](
http://www.graalvm.org/truffle/
javadoc/com/oracle/truffle/api/interop/MessageResolution.html
<http://www.graalvm.org/truffle/javadoc/com/oracle/truffle/api/interop/MessageResolution.html>)
sample. That
should give you overview of the possibilities. Good luck.

-jt

End of graal-dev Digest, Vol 74, Issue 16
*****************************************