[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: whoa
- To: srfi-103@xxxxxxxxxxxxxxxxx
- Subject: Re: whoa
- From: Derick Eddington <derick.eddington@xxxxxxxxx>
- Date: Thu, 24 Sep 2009 10:36:10 -0700
- Cc: campbell@xxxxxxxxxx
- Delivered-to: srfi-103@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=R74mXj6oXASMfyggYZcjg1b64+thw281kURZ2WShxUU=; b=Ttm+GmhszAIy2ccLo/NbJb1DrkwtIKLDqukQ/GCojYlDMM50J9sLKBPxBYacFXiQ6K 7UynUlATOLqptNgr9bSESka/Jn/+epT/PTDJUk+F5EP05A0jfemlHRZ9eycNoFk76JdI oPdc87t6m5FSMHaN+0cl5dK4JZ49kWJHrq1WM=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; b=OqGYIKuFuv+zOlh2xYt/YUlRemPx0FmvIpXT8VHVxB/SxYNNN6eJ/Z2VrAHxxKM7FQ kEkj+PGO/q3KkJ7ZF0dZjN/WTC/p6eBkfHvYPiLtWiK3dwuh4aXvKsPVsi472RGtOS/D zeRc2U1Hto8XFXktUH1ykLkHL5AA1uC5Vechk=
Taylor Campbell wrote:
> I'm not keen on what has become the conventional mapping from library
> to nested directory structures in implementations of the R6RS, or for
> that matter with the R6RS's library system at all, but I have to say
> I'm pretty astonished by the immensity of this SRFI.
I don't think it's immense. I don't think it's small either. It's size
is proportional to the features and description I wanted it to have.
Most of the features in it are already available from R6RS systems. It
standardizes them and addresses known issues with them, and it adds
qualities I think will be useful for building upon to programmatically
manage collections of library files.
I have a couple sizable collections of libraries, and I review others'
sizable collections. I don't think I could have as effectively
organized and managed my collections, or as easily reviewed others',
without the compound library names and convention for hierarchical
organization of files. I want to make and review more, possibly large,
collections, and I want automation tools for managing collections, and
this SRFI has a design I think I'd like to have. I think this SRFI can
help promote creation and sharing of larger numbers of larger
collections.
> I expected, perhaps, a sentence such as the following to explain the
> entire specification, modulo details of term definitions:
>
> `A Scheme system keeps a list of directory pathnames called its search
> path, relative to which it looks in order for libraries' source code
> by mapping their component names to file names, mapping alphanumerics
> and hyphens to themselves, and mapping all other code points by
> percent-encoding.'
>
> Maybe there need to be a couple more sentences about an environment
> variable storing the search path, putting version numbers before the
> `.sls' suffix
If it were that small, it would lack features and qualities I want it to
have.
> (which is silly enough as it is -- what was wrong with
> `.scm', again?),
I, and I think others, like `.sls' because it distinguishes files
containing R6RS-like libraries from all other file types. A distinct
extension allows identifying library files versus non-library files by
just the file name, without having to look in the file. I use `.sps'
for R6RS programs. I still use `.scm' for non-R6RS files (i.e. files
which are not R6RS-specific, such as R[45]RS code I run as R6RS code).
> and bumping the directory used to find a particular
> library up to the front of the search path when finding its imports so
> that it gets its neighbours if possible.
I don't think I'd like that.
> Anything more than that, I can't keep in my head when trying just to
> write Scheme code!
I don't think using it is as head-consuming as you're thinking. You
probably have to become familiar with it, like any system.
--
: Derick
----------------------------------------------------------------