[plt-scheme] Are new Schemers supposed to be reading SRFIs?
On 5/10/07, Robert Nikander <nikander at nc.rr.com> wrote:
> Richard Cobbe wrote:
> > It looks like the primary advantage to descriptive names (for whatever
> > value of `descriptive') is to save the users the trouble of having to look
> > up the srfi number in order to require the module. I don't expect the
> > descriptive names to cut down on trips to the help desk.
> >
> > First, the user would still have to look up which descriptive names we
> > chose. ("Now, I want SRFI 48 -- is that format.ss? No, that's SRFI
> > 54....")
>
>
> I won't be looking them up. As someone who is new to PLT Scheme, I do
> the opposite. For example, while coding, I think, "I want the 'cut'
> srfi, what number is that again?", and I have to go look. In contrast,
> it took a day to remember all the libraries that have symbolic names.
> (lib "plt-match.ss"), (lib "class.ss"), etc.
>
>
> > Second, the (occasional) user would still have to look up the surrounding
> > stuff necessary for the require. I mean the (lib mumble "srfi") context,
> > which I can never remember (possibly due to confusion with the existing
> > "informative name" require form).
>
>
> (require (lib "cut.ss" "srfi")
> (lib "string.ss" "srfi"))
>
> I wouldn't have to look anything up to write that.
I think one complaint is that it is hard to decide who gets the "good"
names, like "format.ss".
> For people who are like integer library names, the
>
> (lib "13.ss" "srfi")
>
> style could continue to work.
>
> About the other objection: "what happens if the "list" srfi (#1) is
> revised to version 2, as srfi #300." The problem of libraries changing
> with new versions is a general problem that all languages/systems face.
> But the usual solution is to attach integers (version numbers) to the
> symbolic name, not make the entire library name an integer.
>
> Rob
>
>
>
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>