--- Larry Clapp <[EMAIL PROTECTED]> wrote: > > Yes. The danger arises when programmers "break encapsulation" and > take an accident of implementation and assume that the spec requires > it.
I would say that (in my scenario, which I see is not at all appealing) the response would then be to take a look at the "accident of implementation" and see if it is desirable or undesirable. > So one would have to draw a careful line that says "the text > defines behavior; the code defines one possible implementation of the > behavior". Implementation A that runs on a multi-GHz, multi-GByte, > multi-cpu cluster might use a highly optimized generational > multi-threaded garbage collector; implementation B that runs on a > Palm m505 might use a stop-and-copy garbage collector. And the > specification should allow this, even though the code, of necessity, > must choose one implementation over another. I'm not sure I agree - it depends on how much you want specified by the spec. I prefer a spec that provides ABSOLUTE reproducibility in behavior, even at the expense of performance - at least as a first cut. Performance tuning implementations could be added on as vendor specific implementations of the text part of the spec, but with the actual spec implementation available (however slow) to fall back on if behavior is of absolute importance over performance. I agree that the ANSI spec as written was probably intended to allow performance tuning on different platforms, but I'm not sure I would favor the idea of a spec being written broadly enough to cover such widely varying platforms. Alternatively, perhaps there could be "levels" of compliance - e.g. being compliant with the "text" part of the spec but not necessarily the implementation part, vs. ensuring absolute reproducibility in behavior (with no guarantees of performance). However, seeing how uninformed my opinion is I will concede the argument - I suppose it is probable that the current problems with incompatible lisp implementations might be less severe than an attempt to unify everything up to the ANSI level. > No, I disagree. In any application, one makes design tradeoffs. > Your implementation may need to optimize for small code size at the > expense of execution speed whereas mine may need to do the reverse. > And the specification should allow that, even though the reference > code must make a choice. I guess it depends on what one is looking for in a spec. > >> In other words I don't think you could reasonably define the code > >> as part of the spec, but only as an example implementation. (I > >> apologize if you mentioned this elsewhere and I just missed it.) > > > > No problem - you didn't miss it - I'm just an unreasonable sort > ;-). > > I see what you're getting at but I think it's a feature not a bug, > > since a Modified BSD licensed spec could be loaded anywhere, and > > provide EXACTLY the support required, intended or not. Whether > > something unintended should be intended (or forbidden) can be > sorted > > out later. The "example" implementation would be the ONLY > > implementation, removing the need to implement it again. > > I disagree. Fair enough. It depends on the goals - I can see where mine would be different from the really broad case. > > Why have five different lisps all doing the work to define the ANSI > > features? > > Because they have five different target audiences. Do they? Clisp, CMUCL, SBCL, GCL, and ECL all seem to be attempting to be desktop PC level lisp implementations which provide ANSI feature-sets. The way they do it is different of course, but I always thought the target audience was pretty similar - desktop PC developers using lisp. I confess the idea of embedded lisp never occurred to me as a major application for the lisp language as per ANSI - I would have though the more compact spec of scheme would lend itself to that. Again, though, I confess to ignorance here. Cheers, CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
