Re: [Chicken-hackers] library unit restructuring

[Felix Winkelmann]

From: Evan Hanson <address@hidden>
Subject: Re: [Chicken-hackers] library unit restructuring
Date: Sun, 13 Jul 2014 14:37:57 -0700

> On 2014-07-09 13:05, Felix Winkelmann wrote:
>> It would be nice to have some hierarchical naming for core
>> modules, what do you think about "chicken.string", "chicken.list"
>> etc. (even though I prefer the plural form, that is, "strings")? In
>> R7RS that would map to "(chicken string)" and so on. I can't remember
>> whether we have considered "list"-syntax for module names yet. Should
>> that be added? There is some ambiguity with that, when
>> import-modifiers come into play...
> 
> I don't think there's been any real discussion of it yet. I'm for it, at
> least, and there shouldn't be any ambiguity disallowing "only" et al (as
> described in the other fork of this thread).
> 

I actually found one case: module alias definitions with listish module name
can not be distinguished from functor instantiation:

  (module foo-alias = (chicken string))

Which is obscure enough. Should be drop module-aliases? They are used
internally for functors, but are probably useless otherwise.

> I like "chicken.string", "chicken.list", "chicken.ports", etc. It seems
> like "chicken.string" might be a good one to start with as a proof of
> concept, since it's fairly obvious what should be moved there from
> data-structures (anything with "string" in its name, and possibly
> "conc") and it'll probably only go one level under "chicken" (as in,
> it'll consist of two parts, "chicken.string", and not more like, say,
> "chicken.data.queue" (which is a bad example as it'll be eggified, but
> still)).

Right, sounds good to me.

Regarding the eggification of binary-search, memory-mapped-files and
queues - are we all agreeing about this? Does this require a
change-request?


felix