[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Scheme-reports] Proposed R7RS-large library declarations

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@x
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