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 15 May 2014 10:41 UTC
On 15/05/14 00:06, Per Bothner wrote:

> I don't know what the solution is.  It is possible that R7RS-large is too
> ambitious, at least for the Scheme community.  Perhaps we should aim for a
> more modest r7.1rs with a few optional additions.  Perhaps every other year
> we could have a new 7.x point release with some modules we can take more
> time to get consensus for.  Instead focusing on features perhaps it is
> more important to find a standards language and framework for optional
> features and modules.

As I see it, R7RS-large is causing people to think about what SRFIs we
need and to write them, which is great. What goes "into R7RS-large" is
then largely irrelevant, as R7RS implementations will be R7RS-small +
all relevant SRFIs (meaning: all SRFIs apart from ones skipped in
ideological grounds, ones not practical/relevant to the target platform,
or ones they've just not gotten around to yet).

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 :-)

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