[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [scheme-reports-wg2] Closing SRFI-112 and voting on it for R7RS-large
- To: scheme-reports-wg2@xxxxxxxxxxxxxxxx
- Subject: Re: [scheme-reports-wg2] Closing SRFI-112 and voting on it for R7RS-large
- From: Faré <fahree@xxxxxxxxx>
- Date: Sun, 15 Sep 2013 17:44:26 -0400
- Cc: srfi-112@xxxxxxxxxxxxxxxxx, scheme-reports <scheme-reports@xxxxxxxxxxxxxxxxxx>, srfi-editors@xxxxxxxxxxxxxxxxx
- Delivered-to: srfi-112@xxxxxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5r2c0zxm810s2nLKYfvvRfx/cf0EuMcLOuZUwET4rHk=; b=tpo5WZYDskat09rU5/+X0KeiTsfaHgdNvtj/M9qn7WLAydtJrMJh5J7doIYDPIeKgM QrIyspnhrOhm1Zqio/CaoPTeWamNRy8/z4SotyJh/erV4Q0RC0NPhse0TJ/SUUGEX+dl u1TWGmjeAQUm+KVj/QhrE0UKNVNqsNZ3ICxadSmPeXbMReJ+DXfydOGHskGnhSFy4uDF ChAJReOt+3OLr4FPdsMvofMhArF7JI8CeELAQ5MQr+F56vmu8at463UYnSEmBxedJ6zx V6StExJRWXSJffvJMLA0VIhvuiVfA0PG6Nk0jXr2EZ+1m+xegpe1B/hmvU3zDbZZitVR ojPg==
- In-reply-to: <CAC_pKx9bdv4M=GwxaO9Wk4HGDXBqk79Z0kQnHown67oo1fEQjQ@mail.gmail.com>
- References: <20130912232429.GF27261@mercury.ccil.org> <CAC_pKx9bdv4M=GwxaO9Wk4HGDXBqk79Z0kQnHown67oo1fEQjQ@mail.gmail.com>
On the one hand, I think we need something, and that's better than nothing.
On the other hand, I think SRFI-112 is insufficiently adequate, though
a good start.
For instance, implementing ASDF (for Common Lisp), what I really
needed is some kind
of ABI-identifier so I may segregate compiled files. The provided
information does not allow to infer that: ABI may change because
you're linking to a different libc, using a different C++ compiler,
using a different compiler implementation strategy, etc. These are not
captured by any of the above elements.
Also, some standardization is often useful in the specific values to
be returned, e.g. "Linux" vs "linux", or "i386" vs "x86" vs "i686" vs
"pentium", or "arm" vs "ARM" vs "armv5te" vs whatever. I'm not saying
things should necessarily be specified in detail in the standard
(especially since they change), but the standard may explicitly
recommend that values be returned in accordance to some other
documents, websites, standard bodies, etc.
Finally, I was expecting the equivalent of getenv to be provided,
maybe setenv too, on operating systems that have it (i.e. everyone
that matters today), returning trivial #f on other systems.
I don't know that it makes sense to make a counter-proposal, which
would be meaningless unless actually widely implemented anyway. If
it's only half as hard getting Scheme implementations to agree as it
is to get Common Lisp implementations to agree, it's already too much
work for me.
I admit I've grown distant and disillusioned with the entire process,
and I only apologize for not doing more, but I don't see things going
anywhere good at any good pace.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Evolution competitively selects stable cooperative patterns.
On Sat, Sep 14, 2013 at 4:22 AM, Emmanuel Medernach
> On Fri, Sep 13, 2013 at 1:24 AM, John Cowan <cowan@xxxxxxxxxxxxxxxx> wrote:
>> Well, for personal reasons I haven't done anything on Scheme for about a
>> month, but I'm starting up again.
>> 1) SRFI editors: please finalize SRFI 112.
>> 2) WG2 members and would-be members: please vote on accepting SRFI 112
>> <http://srfi.schemers.org/srfi-112/srfi-112.html> as part of R7RS-large
>> in the (scheme inquiry) library.
>> Votes will be accepted until Monday, September 23 at noon UTC. Vote
>> by responding to this email on the scheme-reports-wg2@xxxxxxxxxxxxxxxx
>> mailing list. A valid vote consists of either "yes" or "no", plus
>> any comments you want to add. If you have trouble posting, send your
>> vote to me and I will forward it. (Kevin Wortman, your existing vote
>> will stand unless you tell me otherwise.)