Opened 13 years ago
Closed 7 years ago
#703 closed defect (fixed)
Restructure core libraries
Reported by: | felix winkelmann | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | 5.0 |
Component: | core libraries | Version: | 4.7.x |
Keywords: | Cc: | ||
Estimated difficulty: |
Description
The current structure of the libraries is completely arbitrary and both annoyingly impractical and inconsistent. identity
doesn't belong into data-structures
and why is write-line
in extras
and not in ports
. The list goes on like this.
The libraries should be restructured fundamentally. To make this backwards-compatible, we could provide wrapper modules (or extensions) that provide the old structure but internally map to the new one. This would also be the opportunity to give more meaningful names to the SRFI libraries (with the srfi-XXX
identifiers being just aliases).
Change History (6)
comment:1 Changed 12 years ago by
comment:2 Changed 10 years ago by
Does anyone want to propose a new structure for the core libraries?
Replying to felix:
The current structure of the libraries is completely arbitrary and both annoyingly impractical and inconsistent.
identity
doesn't belong intodata-structures
and why iswrite-line
inextras
and not inports
. The list goes on like this.
comment:3 follow-up: 4 Changed 10 years ago by
comment:4 Changed 10 years ago by
I like the idea of hierarchical R7RS style libraries quite a bit.
Replying to evhan:
https://wiki.call-cc.org/core-libraries-reorganization created.
comment:6 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
We finally managed to restructure all the core libs!
Names like 'extras' and 'utils' are certainly meaningless. It would be nice and clean if we could just filter them out into suitably-meaningfully-named libraries and just keep the generic names as re-exporting compatibility modules.
Slightly trickier is if we want to move anything out of existing well-named modules such as 'ports', as then we can't have backwards compatability without choosing a new name for the new module that doesn't export the names in question.
Personally, I'd like more finer-grained modules, avoiding generic terms such as "extras" as they just end up as grab-bags full of things, and looking for a function involves searching the list of modules for a specific module and then searching "extras" if you can't find it. In other words, I propose that the rule used to decide what granularity to use should be to put oneself in the shoes of somebody looking for any of the functions in a module, and seeing if all of those functions would seem to be implied by its name, without it misleadingly suggesting any functions that are elsewhere.