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: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Fix #1133
Date: Tue, 1 Jul 2014 09:13:45 +0200
User-agent: Mutt/1.4.2.3i

On Tue, Jul 01, 2014 at 12:15:47AM +0200, Felix Winkelmann wrote:
> Hm. You mean invoking the entry-point of a library unit should
> register a feature of the same name?

Or something else, I'm not sure what exactly.  I think conflating
features with module names is asking for trouble down the line.
If nothing else, we could prefix it, like for example module:foo.
It's ugly but would avoid name conflicts.

> Perhaps that might work (yet
> wouldn't solve the problem of multiple compilation (and thus
> entry-points) units in a single library)

Can you elaborate on that?

> 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. 

Is this just a gut feeling, or can you give an example where it will
cause trouble?  So far, I've only seen several questions on IRC from
newbies who got confused that import didn't actually load the code.
And having to remember to (import chicken scheme) but that we should
(use everything-else) is just a hassle, and a barrier to entry for
newbies.  I admit it's a relatively minor annoyance, but if we can
remove it I don't see why we shouldn't (unless of course there's a
compelling example why loading and importing should be kept separate)

> 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.

Having multiple modules inside one file is kind of problematic anyway,
so I don't think many people are doing that.  (I don't think we should
actively make that impossible, however)

> That the documentation does probably increase the confusion due to the
> many options is a valid concern, though.

Perhaps we should strive to get rid of some forms.  I'm not sure which
though.  require-extension is there for SRFI compat, isn't it?
If "import" performed the task currently performed by "use", we could
eventually get rid of "require-library" AND "use".

I'm not sure if "require" has any uses, otherwise we could start by
deprecating that.  I've never seen anyone use it "in the wild".

> 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?

For convenience and to reduce confusion.  We wouldn't need "use" at all,
eventually we can get rid of it.

> (which is not necessary to implement in core. CHICKEN is an R5RS
> system, as you said in another mail.)

It is, but R5RS doesn't have a module system, so we're not bound to the
spec for how that works, and can change it to whatever is most
convenient for us.

> And why would it make using the r7rs egg less painful? I'm not sure I
> understand, but I'm probably missing something.

Hm, perhaps it's me who is missing something.  I seem to recall that the
r7rs egg just mapped import to CHICKEN's import, requiring the user to
load the implementation of a module somehow "from the outside", but that
doesn't seem to be the case (anymore?), so just ignore that.

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

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