chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] Fix #1133


From: Felix Winkelmann
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Tue, 01 Jul 2014 00:15:47 +0200 (CEST)

> 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



reply via email to

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