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)
|
Peter Bex scripsit: > This single identifier can be renamed which causes both these types > of begins to be renamed. In that sense it's really just one begin. True. > I'm unsure such things are very generally useful. [...] Perhaps > it's more useful to add a sort of "pragma" declaration in which such > annotations can be safely kept, being ignored by implementations that > don't understand it. 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 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. The only declarations for which support is by my proposal are "reexport" and "notinline", and even the latter can be ignored if your implementation does not inline code by its own decision. If interfaces are included, the "interface" declaration will also be required. My list was compiled by looking at the declarations (and command-line switches) of Common Lisp, Chicken, Gambit, and Bigloo (which has about a hundred such declarations). I looked briefly at other Schemes but found nothing I wanted to add. > 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. > I think pattern-matching shouldn't be added. [...] I'm already a > little uneager to implement R7RS modules in Chicken. Adding a pattern- > matching thing to it will push the complexity well over the edge of > being acceptable to implement IMHO. To hear is to obey. I have put everything in that part of the proposal in the subjunctive, and made it clear that I am not proposing it though someone else may do so. That's just in order to keep the idea around for completeness. > 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. For example, there are now two implementations of SRFI 1: the Shivers implementation, optimized for speed, and the Shinn implementation, optimized for code space. An implementation could check the optimizing declarations to figure out which is wanted, or leave it up to the user. In any case, the SRFI 1 procedures could be listed in an interface, and both libraries could specify `(interface (srfi 1))`. Adding new identifiers to the interface that aren't supported in either library would cause it to break. -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the cowan@ccil.org Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports