Re: [Scheme-reports] Reformulated numeric-tower ballot Andy Wingo (07 May 2014 19:38 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Andy Wingo (14 May 2014 20:45 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Arthur A. Gleckler (14 May 2014 20:56 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Per Bothner (14 May 2014 23:11 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot John Cowan (15 May 2014 03:22 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Per Bothner (15 May 2014 07:14 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot John Cowan (15 May 2014 13:30 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Per Bothner (15 May 2014 22:08 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Alaric Snell-Pym (15 May 2014 10:47 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot John Cowan (15 May 2014 12:20 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Sascha Ziemann (16 May 2014 08:37 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Alaric Snell-Pym (16 May 2014 08:46 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot Peter Bex (16 May 2014 08:57 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot John Cowan (16 May 2014 21:05 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot John Cowan (16 May 2014 20:26 UTC)
Re: [Scheme-reports] Reformulated numeric-tower ballot xacc.ide@gmail.com (16 May 2014 20:41 UTC)

Re: [Scheme-reports] Reformulated numeric-tower ballot Alaric Snell-Pym 16 May 2014 08:41 UTC
On 16/05/14 09:32, Sascha Ziemann wrote:
> 2014-05-15 12:41 GMT+02:00 Alaric Snell-Pym <alaric@snell-pym.org.uk>:
>>
>> I suspect that a "common consensus" on the set of SRFIs that makes a
>> "practical implementation" will emerge organically, and predicting that
>> set to mandate it now will be difficult :-)
>>
>
> This is the reason why the decision which SRFIs are important and which
> are not important is useless. Instead it would be much more important to
> specify some kind of Maven like package repository for Scheme. There
> have been several attempts, but Racket has its own, Chicken has its own,
> Gamit has its own. And if you try to switch from one Scheme to another,
> it is always a pain to find the packages necessary for the program. Not
> having access to package repositories is nowadays a major productivity
> drawback. If R7RS wants to be large/great, it should do something great.
> And joining all Scheme code would be the greatest thing R7RS could do.

I gather Snow is being resurrected in terms of R7RS modules, so
hopefully, that's in the bag. However, that only helps for the kinds of
SRFIs that can be written as portable Scheme code, which I do indeed
hope will be in such a repository for all to use on demand - the ones I
was talking about (and I should have been clearer) are things that can't
be portable, such as interfaces to sockets APIs, or things that peek
into implementation details.

So, chin up! The future's bright :-)

>
> Sascha
>

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports