Question about the new polyglot API and its `Value` class

[Christian Humer]

Hi Peter,

> Yes, staying independent of the Truffle/Polyglot API is one motivation.
Another is ease of use.

There are certain aspects in some of our languages that cannot be
represented with core JDK classes. This is where the Value API comes in.

> I think it functionally covers the use case I described. However, I’m
worried that funneling a language specific conversion through an
intermediate data structure (and TruffleObject protocol based conversion)
will be very inefficient for large data structures.

Truffle interop (you called it TruffleObject) is not a conversion protocol
it directly accesses the internal language objects. So whenever you read a
member from an object you would have the same costs as in the guest
language. For the object mapping that I have described we wrap the
TruffleObject into a Map view. This is done lazily when the value is
accessed. There is no Value instance involved here. Whenever you call into
the Map view we directly invoke a Truffle CallTarget that partially
evaluates the internal language object access (GraalVM is also able to
inline those calls into Java). Numbers, booleans and strings are not
wrapped but directly exposed.

The only additional overhead in this model is the wrapping into the Map
view for objects and arrays. Its impossible to get rid of this last
indirection without breaking the abstraction. The abstraction is important
because it separates host application Java code from Truffle partially
evaluated Java code. This is necessary because Truffle allows you to do
things that would not be backwards compatible with normal Java like
ignoring the Object identity semantics for instances annotated with the
CompilerDirectives.ValueType annotation.

> While there is the option to forgo the polyglot API, I increasingly feel
this is missing out on too much. For example, most languages will need
something like `TruffleContext`, which is tied to the polyglot API.

TruffleContext API is only necessary if you compose multiple languages. To
compose multiple languages (and in our case also tools) you need something
like the polyglot API that sets the rules. If you have a single language,
and no tools scenario and you don't want to implement TruffleLanguage then
you also don't need TruffleContext.

Truffle will remain usable without implementing TruffleLanguage, if you
only want to use the partial evaluation aspect of the system.


- Christian Humer






On Fri, Jan 12, 2018 at 10:32 PM Peter Niederwieser <pniederwieser at apple.com>
wrote:

> Hi Christian,
>
> thanks for your response!
>
> On Jan 12, 2018, at 9:50 AM, Christian Humer <christian.humer at gmail.com>
> wrote:
> Just to clarify: You want to expose Guest language objects to the user
> through the Evaluator, but you don't want them to use the polyglot API to
> access those objects so you stay independent of the runtime in use?
>
>
> Yes, staying independent of the Truffle/Polyglot API is one motivation.
> Another is ease of use.
>
> We are about to introduce API to support executing `value.as(Object.class)`
> to return a representation that only uses core JDK classes to represent the
> value.
>
> ...
>
> Does this cover your use-case as well?
>
>
> I think it functionally covers the use case I described. However, I’m
> worried that funneling a language specific conversion through an
> intermediate data structure (and TruffleObject protocol based conversion)
> will be very inefficient for large data structures. I’d much rather have
> *some* way to directly access/convert the language’s internal data
> structure. Initially I thought this could be done by implementing a
> “convert” message, but then I realized that message sends always return
> another `Value`.
>
> While there is the option to forgo the polyglot API, I increasingly feel
> this is missing out on too much. For example, most languages will need
> something like `TruffleContext`, which is tied to the polyglot API.
>
> -Peter
>