Re: [Scheme-reports] Location of definitions inside libraries
John Cowan
(30 Dec 2012 22:37 UTC)
|
Re: [Scheme-reports] Location of definitions inside libraries
Peter Bex
(01 Jan 2013 13:31 UTC)
|
Re: [Scheme-reports] Location of definitions inside libraries
John Cowan
(01 Jan 2013 18:53 UTC)
|
Re: [Scheme-reports] Location of definitions inside libraries
Peter Bex
(01 Jan 2013 19:20 UTC)
|
[Scheme-reports] R7RS-large library declarations
John Cowan
(01 Jan 2013 20:02 UTC)
|
Re: [Scheme-reports] R7RS-large library declarations Peter Bex (01 Jan 2013 20:34 UTC)
|
Re: [Scheme-reports] R7RS-large library declarations
John Cowan
(01 Jan 2013 21:43 UTC)
|
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@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports