chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] Merging of import, types and inline information


From: Peter Bex
Subject: Re: [Chicken-hackers] Merging of import, types and inline information
Date: Sat, 17 Jan 2015 13:23:41 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jan 17, 2015 at 02:28:27PM +0300, Oleg Kolosov wrote:
> Hello All!
> 
> I’ve been thinking about an idea to merge module type and inline information 
> into import libraries for a long time, and, before starting to hack, decided 
> to ask for opinions in hope to produce useful discussion.
> 
> As you might remember we are working on CHICKEN based karaoke box firmware. 
> The project keeps growing and the number of application modules almost 
> approached 100 already. Scrutinizer provides great assistance with that (a 
> major selling point in comparison with other implementations, you should 
> advertise it more IMO) but to fully utilise it across modules it needs to use 
> exported type information. Hooking this into build system is a major hassle, 
> especially during quick development when things are moved around/renamed.

Good point on the advertising part.

> So, what do you think about adding type/inline information unconditionally 
> into the generated import library when emit-import-library options are 
> supplied and using it from the import libraries found in the include paths 
> when modules are used? In other words: ditch emit-type-file/types and 
> emit-inline-file/consult-inline-file options completely and use the existing 
> import library mechanisms for that because they are mandatory anyway. Maybe 
> I’m not seeing the whole picture and there are some downsides.

I think the main reason the files are separate is because the types
database file format might change, which would make old libraries
unusable.  Especially in case of core itself it would be a big hassle
to correctly bootstrap a new CHICKEN if the format ever changes.
And it does change; recently we introduced a new "#:foldable" property
which is not recognized by older CHICKENs.  A CHICKEN bootstrap compiler
("chicken-boot") is built without using the type database.

Secondly, for example the "numbers" egg has an extensive types file
with many hand-written specializations.  The nice thing of separating
this file from the import file is that numbers can still be compiled
with, for example, CHICKEN 4.6.0 (which didn't have a scrutinizer).

However, your idea itself is sound and will produce less of a hassle
for new users.  Having auto-generated type annotations and maybe even
specializations will make the type system a lot easier to use.
Bootstrapping problems could be avoided if there's a way to get
CHICKEN to *completely* ignore type information in the import files.
I'm not sure how something like the numbers egg could work across
multiple CHICKEN versions; maybe a cond-expand could avoid adding
type information.  Do you know if the complete numbers.types file
could be expressed via inline type annotations and then emitted?
(I haven't used the type system much aside from this particular egg)

Maybe Evan or Felix care to comment further on this, they know more
about the nitty gritty internals of the scrutinizer.

Cheers,
Peter

Attachment: signature.asc
Description: Digital signature


reply via email to

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