Truffle CallNode API. Is it possible to keep the old inline API?

[Christian Humer]

Hi Wei,

I had a very brief look at ZipPy calls and they seem to be implemented
nicely.
Do I guess correctly that your problems migrating is due to
BuiltinIntrinsifier?
Can you quickly outline the rationale behind it?
Can you point out other areas which got you into troubles?

I will have an in depth look on them on Monday.

Thx.

- Christian Humer


On Sun, Feb 9, 2014 at 2:54 AM, Wei Zhang <ndrzmansn at gmail.com> wrote:

> Hi Christian Humer,
>
> I've been looking at the new CallNode API for a while now.
> I tried a couple of times to adopt it, but it hasn't been successful so
> far.
>
> The new inlining API does look cleaner and more compact.
> It makes more sense for the most part, but it requires a big change in
> ZipPy.
>
> One thing that ZipPy relies on in the old API is that one can
> customize the inlining logic.
> A Python level call Inlining could trigger some additional
> transformation in the caller's AST.
> In the new API, inlining is pretty much hidden from the caller.
>
> Admittedly there's always another way to achieve the same thing, but
> it would be nice to have the old API around at least before we can
> successfully migrate to the new one.
> Another option for me is to stop merging with Truffle until I figure
> everything out.
> But it is going to take a while before I can put my focus back on the
> new CallNode.
> And I know it is not healthy to fall behind for too long.
>
> I'm not sure how much it would affect you, but it is definitely making
> my life easier for the next month or so.
> Please let me know.
>
> Thanks,
>
> /Wei
>