Re: [Chicken-hackers] Folding lolevel bindings

[Peter Bex]

On Mon, Feb 22, 2016 at 10:30:50PM +1300, Evan Hanson wrote:
> On 2016-02-22 10:19, Peter Bex wrote:
> > What does this mean for eggs or other user code with #:foldable
> > annotations?  I'd imagine that this will just break there too?
> 
> That's not supported, is it? There's currently no way to do that without
> preparing a types file manually, and I don't think we make any
> guarantees at that point. (Not that it wouldn't be a very nice feature.)

Looks like #:foldable isn't documented, so I guess you're right in that
it isn't supported.  There are weird things going on here in any case:
because number-of-slots isn't namespaced at all, you could actually get a
program to compile which would run with an error in the interpreter or
unoptimised.  The program you quoted lacked a (use lolevel), but it
worked nonetheless in older CHICKENs due to rewrites, and that's also
what #:foldable would do if we fixed it.

I think a proper fix could be to detect #:foldable when loading a types
file, extract the module name and load it.  I'm not sure if that can be
done in general, though.

So maybe for now we should just require lolevel in the compiler, with a
clear comment that we're loading it just for the availability of it for
constant-folding.  Is there an easy way to pre-load all available core
modules?  That would make it easier on maintenance.

For the record, I don't think catching the error and ignoring it is a
good fix; it's equivalent to just removing the #:foldable annotation
from all the lolevel procedures in types.db, but strictly worse.
If ever we remove a dependency from the compiler, all procedures in
that module marked #:foldable would silently stop getting folded!

So the noisy error is probably a good thing and I think we should keep
it: it's also shown us that there's something strange going on in that
folding is being done on s-expression *and* on compiler nodes, which
is bogus.

Cheers,
Peter

signature.asc
Description: Digital signature