Need alternative (friendlier) names for SRFI's, per R7RS large

[justinethier]

EG: (scheme hash-table) for SRFI 69.

[arthurmaciel]

This is definitely useful for Scheme newcomers. Definitely.

[justinethier]

Agreed, the current numeric approach is very unfriendly to anyone outside the Scheme community.

I think R7RS large calls out alternative, non-numeric names for most of the libraries that have been designated as part of that standard (EG: red libraries). So that is a good start for names. We will need to update our code and documentation accordingly.

It would be best if Cyclone could have a way to "alias' one library to another so that the compiler can use both, EG: (srfi 69) and (scheme hash-table), without incurring significant overhead. For example, I do not want the library to have to be compiled twice when building cyclone from source.

[justinethier]

Updated title, need to address both in the API documentation as well a code.

[arthurmaciel]

@justinethier, it is great you are planning to work on this issue in the current roadmap!

I am not sure if this is an useful thought, but I think it would be great if we could define as many aliases to SRFIs as possible, so for SRFIs not listed by R7RS-large, like SRFI 197, we could provide a temporary alias now (e.g. (scheme pipeline)) and, when/if it becomes a part of a future standard, we could add another alias (e.g. (scheme chain-operator) without dismissing the former one. That way we would avoid backward-compatibility breaks. It work like providing a list of synonyms.

What do you think?

[arthurmaciel]

BTW, if you need any help, please let me know.

[justinethier]

Thanks @arthurmaciel !

I like the idea of aliases, let me see if there is a convenient place in the library code to perform an alias lookup / conversion.

Would you be interested in pulling together an initial list of the aliases we need? Many of them may already be provided by R7RS large red edition.

[pclouds]

The list of all r7rs large names for red and tangerine editions can be found here http://practical-scheme.net/wiliki/wiliki.cgi?Gauche%3AR7RS-large. I think at least those names are settled.

[arthurmaciel]

Bellow the list of SRFIs:

Red Edition

Voted name	SRFI number	Core/package
(scheme list)	SRFI-1	core
(scheme vector)	SRFI-133	core
(scheme sort)	SRFI-132	core
(scheme set)	SRFI-113	core
(scheme charset)	SRFI-14
(scheme hash-table)	SRFI-125
(scheme ilist)	SRFI-116
(scheme rlist)	SRFI-101
(scheme ideque)	SRFI-134
(scheme text)	SRFI-135
(scheme generator)	SRFI-121	core
(scheme lseq)	SRFI-127
(scheme stream)	SRFI-41	package
(scheme box)	SRFI-111	core
(scheme list-queue)	SRFI-117	core
(scheme ephemeron)	SRFI-124
(scheme comparator)	SRFI-128	core

Other SRFIs in core:

Suggested name	SRFI number	SRFI title	Notes
(cyclone and-let*)	SRFI-2	AND-LET: an AND with local bindings, a guarded LET special form
(cyclone receive)	SRFI-8	receive: Binding to multiple values
(cyclone threads)	SRFI-18	Multithreading support
(cyclone random)	SRFI-27	Sources of Random Bits
(cyclone format)	SRFI-28	Basic Format Strings
(cyclone integer-bits)	SRFI-60	Integers as Bits
none	SRFI-69	Basic hash tables	Stimulate usage of (scheme hash-table) instead?
(cyclone socket)	SRFI-106	Basic socket interface
(cyclone fixnum)	SRFI-143	Fixnums

Other SRFIs already ported as Winds Packages:

Suggested package name	Suggested library name	SRFI number	SRFI title	Notes
hooks	(cyclone hooks)	SRFI-173	Hooks
chain	(cyclone chain)	SRFI-197	Pipeline Operators
assumptions	(cyclone assumptions)	SRFI-145	Assumptions
srfi-152	(srfi 152)	SRFI-152	String Library (reduced)	Stimulate usage of (scheme text) instead?
cut	(cyclone cut)	SRFI-26	Notation for Specializing Parameters without Currying

[justinethier]

Thanks @arthurmaciel and @pclouds !

Let me clean up the prototype code and documentation to incorporate these aliases.

Unfortunately with the change being in CORE, there is no good way to incorporate aliases for SRFI packages unless those names are in CORE as well. I think this is acceptable for now as it is restricted to a small number of SRFI's, which are well-known libraries anyway. Perhaps longer-term we can have a more generic solution.

[arthurmaciel]

@justinethier, I am not sure I have understood the point. I thought about aliasing in the core, so the user could import (scheme box) and (srfi 111) interchangeably. The aliasing would not be in the hands of users. Is that not possible?

[justinethier]

Apologies for the confusion.

@arthurmaciel What you stated is correct, our core code will provide the (scheme box) alias, for example. I think we agree this is how we want it to work.

If we need something more generic (such as a SRFI package author providing an alias) then we can discuss at a later time. In general there should not be many of these aliases since they only apply to SRFI packages; everything else will have a meaningful name by default.

[arthurmaciel]

@justinethier, thanks for the explanation!

I have updated the tables above.

About the srfi package authors, I think they could provide a package with a meaningful name and with meaningful libraries and in the description and tags of the package specify it refers to a srfi. I could adapt winds wiki to show all packages that implement srfis by looking at their tags.

[arthurmaciel]

As a side note, @justinethier, I would like to know what you think about the following:

For the sake of simplicity, I think we should externalize as much libraries as possible, letting in the core only what is related to the Scheme standard. Even for Cyclone libraries, wouldn't it be possible to provide packages from them, wrapping internal procedures?

I have a lot of concerns regarding the entrance of new users - in order to make easy to reason about the system, every library that is not of the standard (i.e. those that are prefixed with (cyclone ...) would require installation. Interpreter and compiler could suggest the installation of missing libraries through a search using a new (yet to come) functionality of winds.

[arthurmaciel]

@justinethier, thanks for the explanation!

I have updated the tables above.

About the srfi package authors, I think they could provide a package with a meaningful name and with meaningful libraries and in the description and tags of the package specify it refers to a srfi. I could adapt winds wiki to show all packages that implement srfis by looking at their tags.

Oh, and maybe winds could have a field alias in package.scm, so winds search could use this field to perform searches.

[justinethier]

Thanks @arthurmaciel I have incorporated these aliases into the compiler!

For maintenance/maintainability purposes I would prefer to keep everything in core that we need to build the compiler. That way a single compilation of the bootstrap repo is enough to get cyclone up and running. And it simplifies things if all of the source code for that is contained within cyclone core, rather than distributing it around cyclone, winds, and an assortment of packages.

[justinethier]

Closing ticket, we now have all of these aliases in place.