> Ah, now I understand. That's due to register-feature, right? This may be the case, I think (I'm too lazy to check right now, but features are used for this, at least for the core library units)
> > Would it be enough to simply always register the library as being > loaded in case of static linking? That way, we could make (import) > perform the task of (use), and remove all the other forms that so > often confuse beginners. This will also make using the r7rs egg less > painful. Hm. You mean invoking the entry-point of a library unit should register a feature of the same name? Perhaps that might work (yet wouldn't solve the problem of multiple compilation (and thus entry-points) units in a single library), but I'm not sure if it is a good idea. The separation of loading/linking and importing is IMHO actually an advantage and provides more flexibility. Hiding everything in "import" will result in trying to work around that very feature, sooner or later. I also don't think that the confusion is _that_ great, "require-extension"/"use" normally works fine, in the usual mode most users will eventually have - one module per compilation unit. That the documentation does probably increase the confusion due to the many options is a valid concern, though. And as "use" currently performs the task of "import", why do you want "import" to perform the task of "use", if not for R7RS compatibility? (which is not necessary to implement in core. CHICKEN is an R5RS system, as you said in another mail.) And why would it make using the r7rs egg less painful? I'm not sure I understand, but I'm probably missing something. felix _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
