Re: [Chicken-hackers] [PATCH][5] The other part of the FFI improvements

[lemonboy]

On 10 Jul, Peter Bex wrote:
> I'm a bit concerned about the patch itself though.  For one, in the interest
> of modularity and code layout, I think all type annotations on variables
> should _only_ be made by the scrutinizer.  It's the scrutinizer's job to
> assign types, not anything else's.
> 
We have to translate the ffi types into something the scrutinizer understands
and we have to do that somewhere. Building ##core#the expression during the
expansion proved to be a not-so-wise choice so I thought that producing the type
annotation when the stub itself is brought to life was a sensible choice.

If you don't like _where_ the conversion is done we can easily create an helper
function in scrutinizer.scm that generates the type informations for all the
stubs by walking foreign-lambda-stubs.
> There's of course the fact that the FFI knows the foreign types, and I think
> it's fine to decorate the node tree with foreign types, or perhaps add a
> node that contains the type (somehow use ##core#the in this situation?),
> but straight up annotating the stub symbol with the types is not done, IMHO.
> Having the foreign types in the node tree might even help us get rid of
> some attributes in the ffi stubs table (though that's not really a goal).
> 
> The other thing I think may cause some headache in the future is the fact
> that in the scrutinizer, ##core#invoke will cause a temporary ##core#call to
> be faked out in order to leverage the existing code.  This is (potentially)
> problematic, because everywhere else in the compiler, nodes are treated as
> "final", and may be mutated at will.  By creating a throwaway temporary
> node, this will cause any mutations on the node to be thrown away.
> 
I see, I overlooked the fact that the mutations are tracked.
This can be solved by making #invoke structurally similar to #call so that the
scrutinizer can reuse the same code path for both and without the additional
fake nodes, I've already prototyped this solution but decided to scrap it for
some reason I don't remember right now.
> [...] or a refactoring of ##core#inline/##core#primitive
> so that it becomes more "like" a ##core#call node and can contain
> type information.
> 
I don't think that's worth the effort, I don't see how this is going to be
useful outside the (niche) case at hand.
> Given that this is a non-user visible change (at least, API-wise),
> perhaps we should shelve this feature for 5.1?  It's not that important
> of a change, and we have enough other things to worry about.
> 
That's fine by me, I'll probably keep working on this on and off in the
meanwhile.