[Truffle] Generated type system overrides isObject()/asObject() methods.

[Thomas Wuerthinger]

OK, so "self" sounds exactly like the kind of value you would put into the arguments. You can subclass the Argument class to have a specific field for "self" and pass it on / set it at the call sites.

Regarding nesting blocks: I guess leaving them as method calls is a good first choice. Inlining those calls is however critical for performance (and will then also help with avoiding the materialisation of the frame). How would you simulate the Smalltalk behavior of blocks and calls to blocks in a language like e.g. JavaScript?

- thomas

On Oct 3, 2013, at 10:02 AM, Stefan Marr <java at stefan-marr.de> wrote:

> Hi Thomas:
> 
> (cc Michael)
> 
> On 03 Oct 2013, at 09:04, Thomas Wuerthinger <thomas.wuerthinger at oracle.com> wrote:
> 
>> There is one question I have about the determineContext and getSelfFromMaterialized methods. Could the self value be transmitted via an argument? The lookup over the chain of frames seems slow (and forces materialisation), so is there some other way one could pass these values? Could you describe the requirements for this self value in the system?
> 
> I guess `self` could be passed as an argument somehow, but I wouldn't know immediately how to get that right.
> 
> What's called the context here is the lexical scope of a block/lambda, which is always defined within a particular method of an object.
> Thus, `self` is always the object on which the method was invoked, in which the block was defined.
> 
> Now `self` is not the only issue here, I think. (I guess you are mostly thinking of getting rid of all materialized blocks.)
> The main issue is that nesting blocks happens quite often, and you want to be able to access the lexical scope.
> 
> I am not entirely familiar with all the kind of possible techniques to avoid such 'materialization', but there are a couple of approaches in the Smalltalk world, for instance the one described by Eliot Miranda [1]. So, I could imagine that blocks get compiled into different variants depending on whether they actually access `self` or their outer contexts. This could avoid materialization for an interesting number of cases.
> 
> Michael, you got some more insight into what might be possible here?
> 
> Thanks
> Stefan
> 
> [1] http://www.esug.org/data/Articles/misc/oopsla99-contexts.pdf
> 
> -- 
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
> http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax:   +32 2 629 3525
>