This page is part of the web mail archives of SRFI 63 from before July 7th, 2015. The new archives for SRFI 63 contain all messages, not just those from before July 7th, 2015.
Aubrey Jaffer wrote:
This works by the implementation knowing the difference between SRFI-25 arrays and SRFI-63 arrays. This difference can be hidden entirely from the user.
I claim that SRFI-25 and SRFI-63 can coexist -- not that they interoperate!
Having two different array implementations, with the same functionality, in the same Scheme implementation, using overlapping but inconsistent function names is out of the question. I really don't want to add a "this array was allocated using srfi-63 make-array" bit to my arrays. That's utterly gross. And of course it doesn't work to have vectors be both SRFI-25 and SRFI-63 arrays. The only sane way to support both SRFI-25 and SRFI-67 is to have them be in separate *optional* modules: (require 'srfi-67) ;; if you want SRFI-67 arrays. (require 'srfi-25) ;; if you want SRFI-25 arrays. Unfortunately, this causes probelems with any implementation that provides either set of functions in the default environment. (require 'srfi-67) must disable the srfi-25 names and vice versa. Existing code that uses srfi-25 array-set! will silently break if you (require 'srfi-67). If you have multiple modules, things are really messy, unless you have a real module system.
| This is a recipe for disaster.| | STFI-25:| (array-set! array k ... obj) | (array-set! array index obj) | SRFI-63: | (array-set! array obj k1 ...)| | It is claimed that "Type dispatch on the first argument to| array-set! could support both SRFIs simultaneously." I don't | believe that. | How would you handle: | (define array (vector 'a 'b)) | (set! array 1 0)
Note: this should have been: (array-set! array 1 0)
| Is the result #(a 0) or #(1 b)? SRFI-25 says: It is not required that vectors not be arrays. It is not required that they be, either. For your example to be ambiguous, you would be depending on unspecified behavior of SRFI-25.
Irrelevant to my point. I used a vector for convenience - the same issue arises with a rank-1 array. And for that matter higher-rank arrays, but I chose a simple example for illustration. In any case, in my implementation, vectors are arrays. The disclaimer is to allow implementating arrays without modifying the core language. If you have the option to tweak the langauge coret, clearly it is better if vectors *are* rank-1 arrays. It's a quality-of-implementation issue.
But vectors are mandated to be arrays in SRFI-63. So the result of your example would be #(1 b).
Not in my implementation. The result *is* #(a 0).
By vectors being SRFI-63 arrays, not SRFI-25 arrays;
But vectors *are* SRFI-25 arrays in some existing implementations.
and by the implementation knowing the difference between SRFI-25 arrays and SRFI-63 arrays,
Unacceptable. And doesn't work if vectors are also SRFI-25 arrays.
Bawden arrays predate SRFI-25 by a decade. SRFI-25 should have chosen other names.
Was that issue brought up during the discussion of SRFI-25? If not, it's irrelevant. You cannot expect everyone to know every possible array package. The fact that it was part of SLIB is more relevant: that should have been discussed, at least. (One problem I see with SLIB is that it contains multiple alternative APIs and implementations of the same basic concept - e.g. macros. That makes it harder to use it as a source for "best practices" or "standarization".) There is a pragmatic issue: How much currently-used code uses Bawden's/SLIB's arrays vs how much uses SRFI-25's. That's hard to tell, but perhaps there is some data or indicators. Without that, the default for a SRFI should be that compatibility with a past SRFI (and one supported by multiple active/popular Scheme implementations) should weigh more than conflicting non-SRFI APIs. From the SRFI document: To my knowledge, shared arrays were original to Alan Bawden in his "array.scm". I doubt it, unless you're restricting yourself to Scheme. Certainly the concept predates 1993 by far. There are precursurs in APL and Fortran going back to the 60-ies. I had it in my Q language from the 80-ies/early 90-ies. (The latest "modify" dates on Q are 1994, but most of the work came before that.) -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/