Just wanted to pipe in here, because I think I agree with Larry's comments but want to make an additional point.
On 2/5/06, C Y <[EMAIL PROTECTED]> wrote: > > 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. 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. Just load the spec and > that's that. If people don't like a particular consequence of how part > of the spec is written (text OR code) then it can be discussed, hashed > out to a conclusion/decision, and then the next version of the spec can > implement the correction. I had envisioned a schedule where once every > three or five years corrections and improvements which are available > and licensed under Modified BSD are sorted out, considered, and applied > as appropriate - then a "Community Lisp 2010" or a "Community Lisp > 2015" could be released. In a perfect world, each new version of the > spec would have its own package, and if a particular piece of code > couldn't be updated and required CL2010 (for example) then it could be > pointed to that particular package. There are specs which are intended to define a complete system, and I would claim this is usually as a response to a requirements document with the end-goal being a specific deliverable (for internal or external customers). Then there is the kind of spec that is akin to a standard, where certain areas may be intentionally left as guidelines (i.e., "may" instead of "must" in standards-speak). This happens for many reasons. This is the situation where you have multiple parties with similar but not completely aligned objectives (perhaps even competing objectives). In this case, an executable spec is *at best* a reference implementation -- in fact, that may be the most valuable aspect of the code, rather than it being canonical. To relate my comments back to Lisp, then, I would say that an executable spec for Common Lisp as the canonical implementation is unrealistic, because it falls into the latter category. -- Jack Unrue _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
