chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: lemonboy
Subject: [Chicken-hackers] [PATCH][5] The other part of the FFI improvements
Date: Mon, 3 Jul 2017 17:22:26 +0200
User-agent: NeoMutt/20170113 (1.7.2)

Hello hackers,

some months ago I sent in a patch that was supposed to put an end to the
scrutinizer blindness during the analysis of the ffi functions: the define forms
for the ffi would "inject" synthetic type declarations that ended up not taking
into account that some foreign types may specify a conversion procedure causing
the final return/argument type to be completely different from the declared one.

In a follow-up mail sjamaan suggested:

> Allowing an optional type annotation would allow the scrutinizer to
> analyse the converter's type.  Currently, returning '* just blocks the
> scrunitizer from performing its analysis.  In fact, it would be even
> better if we can use the foreign type's scrutiny type as information
> for the conversion procedures' input or output.  But that's just wishful
> thinking.

This patch offloads all the heavy lifting to the scrutinizer, most of it is just
boilerplate (that I hope I've got right) to introduce a new node to the core
language named ##core#invoke (the name is up for discussion of course).
The node serves as a simple way to represent the call of a ffi stub and it is a
nice mixture of ##core#call, ##core#primitive and ##core#inline that's easy to
analyze during the scrutiny phase and is desugared into simpler code later in
the pipeline.

I've also added a simple test that checks we don't do silly specializations.

One minor design question: the node stores the stub id as a symbol in the
node-parameters section but one could argue that a structure that's more similar
to ##core#call (where the stub id is stored as a ##core#variable in the first
slot of the node expressions) would be a better suite and would also enable us
to avoid a handful of LoCs in the scrutinizer as it'd be structurally similar to
it. But there's a downside to that because at the moment we don't register the
stub variables as module exports and (##core#variable stub-id) is blocked during
the module finalization phase because of that.
I took the shortest route but you may have some better way to handle this so
feel free to shoot a mail if you do.

The code/mail ratio is approaching the zero so I'm gonna shut up for a while :)

Cheers,
LemonBoy

Attachment: 0001-Generate-type-information-for-the-ffi-stubs.patch
Description: Text Data

Attachment: 0002-Remove-unused-parameter.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]