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
signature.asc
Description: Digital signature
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers