More meaningful names for Red Libraries?

[arthurmaciel]

Hi, @johnwcowan! I know I am coming late to the subject, but still is there any discussion on the Red Libraries names?

Scheme is such an expressive language and it seems (at least to me) far way more intelligible, instead of (scheme ilist) and (scheme ideque), to use (scheme immutable list) and (scheme immutable deque), and (scheme immutable ...) for the many other immutable data structures yet to come. The same applies to (scheme lseq): R7RS-small already have (scheme lazy), so (scheme lazy sequence) or, if typing is really a constraint, (scheme lazy seq), seems much more Scheme-ish IMHO.

I really assume there have been a long discussion about naming libraries and I definitely do not want to seem disrespectful. But I am a hobbyist and being so makes me feel responsible to make the entrance (and stay) of the many newcomers of the future as comfortable as possible. Scheme, due to its flexibility, including the many characters allowed for its identifiers, has a huge advantage over those fancy other languages we see out there. We do not fear long names, as far as they bring clarity, preciseness and call-with-current-continuation :)

What do you think?

[johnwcowan]

In fact we have had very little discussion of library names, or function/macro/variable names either, for these reasons:

• The two groups of names are closely related: we should either use immutable-list-ref and (scheme immutable list), or ilist-ref and (scheme ilist).
• While long names aren't necessarily a problem as such, it's easy to get them wrong.
• There's an ordering question: should it be (scheme immutable list) on the assumption that immutability is more important, or (scheme list immutable), on the assumption that being a list is more important.
• It's easy to rename identifiers and not too much harder to create alias modules.

So rather than bikeshedding names, we concentrate on providing the current features in a library and the correct libraries.

[arthurmaciel]

Thanks for the answer, @johnwcowan.

The intention is definitely not to start a bikeshed discussion. If the arguments pointed out do not make sense, just ignore them with no problems.

The two groups of names are closely related: we should either use immutable-list-ref and (scheme immutable list), or ilist-ref and (scheme ilist).

In my opinion, the part of renaming identifiers of your fourth point makes indifferent which path to take.

While long names aren't necessarily a problem as such, it's easy to get them wrong.

I see that that does not apply to make-bytevector instead of make-bvector, but I completely agree with you. However, as Scheme is a language with traditionally long names (one of its strengths), I think typing errors will/should be addressed by the editor program anyway.

There's an ordering question: should it be (scheme immutable list) on the assumption that immutability is more important, or (scheme list immutable), on the assumption that being a list is more important.

It seems there is already a decision about it: it is defined as ilist and not listi or list-i.

It's easy to rename identifiers and not too much harder to create alias modules.

As far as I know, the standard provides means to rename identifiers, but not to aliases modules, right? Anyway, I was thinking more about the pedagogical/cognitive value of the specification. At least for me, to read it is always instructive and provides a mean to organize how the language is made up.

So rather than bikeshedding names, we concentrate on providing the current features in a library and the correct libraries.

I appreciate the great effort you all put into it!

[johnwcowan]

In my opinion, the part of renaming identifiers of your fourth point makes indifferent which path to take.

In principle, yes. (Insert Radio Yerevan joke here.)

I see that that does not apply to make-bytevector instead of make-bvector

That name was inherited from R6RS. I would have preferred byte-vector, but the Working Group voted otherwise.

It seems there is already a decision about it: it is defined as ilist and not listi or list-i.

This is the same problem. In the (scheme rlist) library, we redefined everything in the underlying SRFI to begin with r (with a few exceptions).

As far as I know, the standard provides means to rename identifiers, but not to aliases modules, right?

There is no standard way, but it's easy:

(define-library (b)
  (import (a))
  ;; copy the exports of module (a) here
)

Anyway, I was thinking more about the pedagogical/cognitive value of the specification. At least for me, to read it is always instructive and provides a mean to organize how the language is made up.

Better consistency is useful, but it is only one value that has to be judged against others. I think the effort would be better spent on a catalogue raisonnée of standard libraries, preferably as hypertext. (If you feel like volunteering, not only would the end product be very much worth having, but you probably find inconsistencies we don't already know about.)

[arthurmaciel]

@johnwcowan, thanks for the response. I think the idea of a catalogue raisonnée of standard libraries is great, but unfortunately I can't undertake it due to other priorities.