This page is part of the web mail archives of SRFI 47 from before July 7th, 2015. The new archives for SRFI 47 contain all messages, not just those from before July 7th, 2015.
| * To: srfi-47@xxxxxxxxxxxxxxxxx | * Subject: compatibility | * From: Per Bothner <per@xxxxxxxxxxx> | * Date: Wed, 12 Nov 2003 12:04:15 -0800 | * Delivered-to: srfi-47@xxxxxxxxxxxxxxxxx | * User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030827 | | While the SRFI process allows alternative and incompatible | implementations, a meta-goal is to define APIs that can be portable | across Scheme implementations. This new specification touches on | existing SRFIs 4 and 25, both of which have been implemented by a | number of Scheme systems. While in theory it may be possible to | implement both SRFIs 25 and 47 at the same time (by descriminating | of the parameters to make-array), that would be a fragile hack. | | The new SRFI is deliberately incompatible with a prior SRFI, and | one that is implemented in multiple Scheme systems. You have it backwards! As the appended SRFI-25 message shows, it was their decision to be deliberately incompatible with SLIB and its installed base. | It does not provide a rationale for why we need an incompatible | SRFI. It says it provides a "richer set of features" than SRFI-25, The richer set of features is: integrating uniform and non-uniform arrays with vectors and strings, all supported by vanilla R4RS code, not requiring changes to implementations. | but it does not explain why it would be impossible or inferior to | instead extend SRFI-25. My hope is that arrays become part of R6RS or equivalent. ARRAY-REF and ARRAY-SET! taking indexes either by list or as multiple arguments makes the semantics in the one-dimensional case difficult for compilers to discover, and would not be accepted into R6RS in my opinion. Specifying shape by a list of an even number of integers has no good precedents that I know of. To compute the origin of an array requires throwing out every second element -- an un-schemely process. Mapping over pairs or lists would be more schemely. There has been no agitation that I am aware of to extend Scheme vectors or strings to have non-0-based indexes. If they are not useful there, then they are unlikely to pass muster according to: Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. ... So my view is that SRFI-25 would require major changes to make it integrable with R6RS. Its final status would seem to prevent such major revision. | It also says the new SRFI has "more compatibility with Common-Lisp" | but surely that is secondary Common-Lisp compatibility is secondary. However, array.scm was developed years before SRFIs; at that time Common-Lisp compatibility had some standing. | compared to compatibility with existing Scheme implementations. According to http://srfi.schemers.org/srfi-implementers.html, SLIB is supported by more implementations than SRFI-25 (five). | An alternative (implemented in Kawa) is to allow the base array of | SRFI-24's share-array to be a uniform vector: | | (share-array | (f64vector 1.0 2.0 3.0 4.0 5.0 6.0) | (shape 0 2 0 3) | (lambda (i j) (+ (* 2 i) j))) | | This is may admittedly be a bit tedious, but we can provide an | alternative make-array that takes a "prototype" of some kind. A | simple and general prototype mechanism that does not require us to | define "types" and "prototypes" SRFI-47 defines only one new type -- ARRAY. Prototypes are just arrays, vectors, or strings. SRFI-4 has different accessor procedures for each type. SRFI-47 uses the same accessors for all. The only procedure dedicated to each type is its prototype generator. For providing a superset of SRFI-4's features and types, SRFI-47's 22 procedures are far fewer than SRFI-4's 64. -=-=-=- | * To: srfi-25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | * Subject: Re: Yo, whassup? | * From: David Rush <kumo@xxxxxxxxxxxxx> | * Date: 16 May 2002 09:47:52 +0100 | * Delivered-To: srfi-25@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | * In-Reply-To: <3CE2E16E.4030009@xxxxxxxxxxx> | * References: <00da01c1fbf0$91e34cc0$0100a8c0@here><qot7km5o3o5.fsf@xxxxxxxxxxxxxxxxxxxxxx><3CE2E16E.4030009@xxxxxxxxxxx> | * User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) | | Per Bothner <per@xxxxxxxxxxx> writes: | > It's unfortunate that srfi-25 is incompatible with | > SLIB. Both include array-set! and make-array functions, | > but they are incompatible - i.e. there are argument lists | > that are valid for both apis, but give different results. | > | > This is bad. | | But only slightly. For myself, I primarily use SLIB for cut-and-paste | reuse, it is my library of last resort. I don't like the burden of its | module system and I frequently find that it implements | almost-but-not-quite the functionality I need. | | Anyway, I'm not going to go off slagging what is still a good body of | software (because I *do* use a fair few bits of it in various | projects), but I just can't see compatibility with SLIB as being an | issue. | | Go final. | | david rush | -- | Research is what I am doing when I don't know what I am doing." | -- Wernher von Braun