[Top][All Lists]

[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 17:08:15 +0200 (CEST)

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

Yes, I agree. But perhaps using a different form of "registry"
flor loadied stuff might be better.

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

You can have multiple entry-points (units) in a single library, just
as we have in libchicken in the moment. This might work with a
"feature-registry" based approach, but I'm afraid of changing anything
in that code (somewhere deep in eval.scm).

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

It's a gut feeling. I don't doubt this *can* be simplified, but
getting this right will be a major job, if it is going to cover all
possible use cases. And we already are planning too much, and haven't
even got the manpower to get patches to this list reviewed in a timely

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

You need it if you don't use modules, and if you don't want to
manually track what is loaded. But it is probably the least used of
those loading constructs.


reply via email to

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