On 2006-02-05, C Y wrote: > --- Larry Clapp wrote: >> I agree with the last part about learning the gory details of >> implementing Lisp. I also agree that when writing an application, >> one can usefully interweave the specification and documentation of >> the code with the code itself -- the code helps define and clarify >> the spec, in that case. >> >> But I wonder about the utility of writing a language specification >> with lots of code in it. In particular, I think you'd have to >> carefully differentiate between "the spec" and "this particular >> implementation of the spec". Otherwise you have people saying, >> "Well, in the spec they used a hashtable for such-and-such feature; >> my code breaks if you use something other than a hashtable, and >> moreover a hashtable implemented in this particular way." > > That might not be all bad though - it would point out two problems: > > a) the spec code has a problem (hidden requirement of a hash table) > b) the spec definition has a problem (the fact that code could be > written which is spec compliant and yet has an implementation > specific failure > > Theoretically, any spec feature should be implementable in ANY way > so long as it implements the spec. If this isn't so, then the spec > isn't complete.
Yes. The danger arises when programmers "break encapsulation" and take an accident of implementation and assume that the spec requires it. 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 suppose one might argue there are ALWAYS implementation specific > gotchas, but what if there had been only the text? One > implementation might have done the feature one way, a second another > way, and then both are spec compliant and only one could run a given > chunck of code. Granted that doesn't say good things about the > code, but the whole point of an executable spec is no one would NEED > to implement another version of the spec in code. 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. >> 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. > Why have five different lisps all doing the work to define the ANSI > features? Because they have five different target audiences. -- L _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
