[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why reference SRFI's at all
This page is part of the web mail archives of SRFI 97 from before July 7th, 2015. The new archives for SRFI 97 contain all messages, not just those from before July 7th, 2015.
- To: srfi-97@xxxxxxxxxxxxxxxxx
- Subject: Re: Why reference SRFI's at all
- From: "Phil Bewig" <pbewig@xxxxxxxxx>
- Date: Wed, 23 Apr 2008 08:08:41 -0500
- Delivered-to: srfi-97@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=gXYN1rrB2UABN6a1kQRppJxZQj30xSWmRFfnzPT/Da0=; b=xivDxYRPQ1A0BwmMlGwsGtSKbjejNffmVo4wxpEmHUgFmL1C6raa0ACJm+tX0yCMqwb4cqxSunwnLfXVUVY8R0CLkedw9lzA2dQCP2XErAzXh4+BMyHCda/K8OaRFtm+/NSdP3Nb8Ohcfv4NXO1D1i99i0h9uXyBX4BzZEnbca8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=L733DVU/0etVzZKxEqGSkYgjkMvplIFK8NkHR9n/6E+YemVM8GwEz4uMhNITD14KqKZuQGY/9PGj40TvaUeutSND+2wWqd+cjTH99OVK8VqZRXvz60W5doBqYIi9VmSi1zhNBceiMCEqWatZsNPQclXDl5qPWE11b+yxCPlMqjU=
- In-reply-to: <15367e850804230521m4b68f7e8id0ec60b635bab9f4@xxxxxxxxxxxxxx>
- References: <15367e850804230521m4b68f7e8id0ec60b635bab9f4@xxxxxxxxxxxxxx>
I've discussed this point previously in another forum.
Users don't care that some particular library was born of a SRFI. Olin Shivers' list library is a SRFI (1 is one of the few SRFI numbers I can remember, along with 40 and 41); Andrew Wright's pattern matching macro isn't. Why should one library hide in a SRFI-ghetto while the other doesn't?
Nor do users want to look up a number any time they need to invoke a library. Likewise, those who read unfamiliar code don't want to be distracted the SRFI numbers. Symbolic names are easier to remember and understand. Authors of academic papers are urged not to give references as  but instead to write [BW88] or [WTM98], which some readers will instantly recognize as Bird and Wadler's 1988 textbook on functional programming or the 1998 paper on even/odd streams by Wadler, Taha and MacQueen. Shouldn't we do the same for SRFI?
I object to any naming convention that uses the word "srfi" or the srfi-numbers.
On Wed, Apr 23, 2008 at 7:21 AM, Geoffrey Teale <tealeg@xxxxxxxxxxxxxx
I was asked to post this comment here after it came up on the Ikarus users list.
I am not a common contributor to the SRFI process, I am just some guy who uses Scheme, loves scheme and tries to encourage others to use it too. That may seem like an irrelevant point, but I think it's essentail to understand the context of what I'm about to say.
Scheme is a powerful, elegant language. However, I sometimes think that people go out of there way to make it hard for people to learn.
I have one simple question. If you step back from this process, and you think about someone coming to scheme for the first time, what value is there in naming a library after the order that someone thought of the idea? Please take the following in the good humour it is intended - I don't want to start a flame war, just make a point.
Imagine for a second I create a new language, the awesome, all powerful Perlpy Scruby, in this language I choose to name the libraries after the combination of the process used to reach the design decision and the order in which the particular design decision was made. Therefore, in my Perlpy Scruby code you might see the following at a top of a file:
<import <gjti <47 64 12>>>
OK, as you are all newcomers to my fictional language, I hope you're all perfectly comfortable and understand exactly what I just did. If you don't you'll be reassured to know that there is a site, somewhere ont he internet that you can trawl through to find out what those things all mean.
I am all for standardised naming, in fact in a world with so many Scheme implementations I think it's essential, but why do we have name things after the beurocracy involved in standarising them? It only makes sense to the people involved in this kind of discussion, not to the end users of the language.