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)
[Scheme-reports] Proposed R7RS-large library declarations John Cowan (16 May 2014 01:28 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)

[Scheme-reports] Proposed R7RS-large library declarations John Cowan 16 May 2014 01:23 UTC

Per Bothner scripsit:

> I'm uncertain about export-all.  Kawa by default does this if there is
> no module-export or export form.  (Binding defined by define-private
> are excepted.)  It might be useful to have an 'except' option if this
> is added.

I've changed it to take a list of identifiers not to be exported.

> The optimization options have a 80's feel to them.

Not surprising, as they come from Common Lisp.

> I'm not sure how useful they'd be to Kawa.  Maybe debuggability to
> control whether to force better exceptions, as an example.

I think speed and safety are important in general, though on the JVM
you pretty much always get safety and speed is out of your control.  :-)

> The Numeric tower specifications seem rather ad hoc, and I suspect will
> see limited use.

`Exactness-preserving` means you have bignums.  But I agree they
are probably obsolete given the R7RS numeric tower vote.  They are
meant to cause complaints if the corresponding features don't exist.
I have removed `numeric-tower` in favor of `error`, which signals an error
(possibly uncatchable) when the library is first examined.  It's meant
to be used within `cond-expand`.

> The Types features might be useful.  However, it's a big can of worms.

It is.  I'm removing it as a proposal and making it an issue.

> I would prefer the provide syntax to be:
>   (provide 'feature-identifier)
> for historic compatibility.

I understand the motivation.  However, the inside of an R7RS library
(other than within a `begin` declaration) is not Scheme, so quoting an
identifier would suggest that a variable is also possible, which it isn't;
there can be no variables there.

--
John Cowan          http://www.ccil.org/~cowan        cowan@ccil.org
Winter:  MIT, / Keio, INRIA, / Issue lots of Drafts.
So much more to understand! / Might simplicity return?
                (A "tanka", or extended haiku)

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