Re: [Scheme-reports] R7RS-large library declarations

[Peter Bex <Peter.Bex@x>]

On Tue, Jan 01, 2013 at 03:02:04PM -0500, John Cowan wrote:
> They are already in effect pragmas, because they are all defined using
> RFC 2119 "should", which means they can be ignored if they make no sense,
> and that is spelled out in the proposal.

I think I missed that bit.

> I also spell out that it is not an error (though it is in Chibi) to
> provide a library declaration that the implementation does not understand.

If these are accepted, there should be at least a warning, to prevent
confusion in the case of typos and misunderstandings by the user.
There's nothing as annoying as hammering on something for an hour just
to figure out you made a silly typo.

> > OTOH, maybe SRFI-0 feature specifications are enough already to
> > conditionalize extensions to the library forms for controlling
> > optimizations and other compiler hints?
> 
> I don't see how that would work, because it is not suggested that you
> can specify your own SRFI-0 features.  Also they are very unselective.

These optimization hints aren't user-defined either, so I'm not sure I
follow your line of reasoning.  If an implementation provides a SRFI-0
feature that's the name of the implementation this will be easy of
course.

> > Interfaces might be useful but probably need some more experimentation
> > by implementers to figure out how useful they really are in practice.
> > Without something that "needs" an interface in the abstract, it doesn't
> > seem to add much benefit to be able to group identifiers in this way.
> 
> They are provided by Chicken and by Scheme48.  They are used at least
> in the latter system when there is more than one good set of algorithms
> for providing particular functions, to save typing out long lists of
> identifiers which must be kept consistent.

IIRC in Scheme48 a module can specify it requires an interface, which
can then be put together by the user with another module that provides
said interface.  In Chicken they are primarily designed for use in
combination with functors, which are higher-order modules.  A functor
can specify it requires a particular interface to be available.  Then
it can be instantiated when provided with an implementation of this
interface.  These are the kinds of abstraction features I was talking
about.

> For example, there are now two implementations of SRFI 1: the Shivers
> implementation, optimized for speed, and the Shinn implementation,
> optimized for code space.

It must be said that even the reference implementation of SRFI-1 isn't
particularly fast, but that's mostly due to the requirements of the API.
But yes, it seems marginally useful to have interfaces.

Cheers,
Peter
-- 
http://sjamaan.ath.cx

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