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

[Peter Niederwieser]

Hi Christian,

> On Jan 13, 2018, at 6:43 AM, Christian Humer <christian.humer at gmail.com <mailto:christian.humer at gmail.com>> wrote:
> 
> 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 totally see the usefulness of the `Value` abstraction. My only gripe is that there is no way to do without it for language-specific use cases.

> > 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.
> 
> The only additional overhead in this model is the wrapping into the Map view for objects and arrays.

I don’t think this is universally true. For example, if interpreter performance is important (e.g. because Graal is not available in all execution environments), converting directly from language-internal to language-specific external datatypes (as in my `Evaluator` example) will surely be much more efficient than going through `Value.as(Object.class)`. A direct conversion is also much easier to implement than implementing Truffle interop messages for all non-primitive datatypes (of which there could be many) and turning the resulting Map views back into language-specific external datatypes.

> 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. 

For the language-specific use cases I have in mind, having *some* way to get at a language’s internal object representation would be very valuable. This could take the form of `Value.getRawObject()`, or `Value.as(MyApiObject)` together with registering a converter from `MyLangObject` to `MyApiObject`, or sending a custom interop message that is allowed to return `MyLangObject` unwrapped. Such a language-specific conversion could certainly take care of handling things like value type semantics as appropriate.

> 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.

Languages that want to be embeddable into Java (e.g. by way of their own `Evaluator` API) will greatly benefit from features such as `TruffleContext` and time/memory boxing, which I believe do/will require using the polyglot API.

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

That’s good to know.

-Peter