--- Larry Clapp <[EMAIL PROTECTED]> 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. 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. > 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. Why have five different lisps all doing the work to define the ANSI features? Why not have all five load "community_lisp-2010.lisp" instead and then focus on new and interesting stuff? (or improving the spec, as the case may be)? > Test cases, on the other hand, you could put in the spec. Test cases > verify behavior, but don't (necessarily) define implementation. I would also like to see test cases. I think Paul Dietz's ANSI tests (the obvious starting point) are either GPL or LGPL, so they might not be workable as inclusions in a spec, but that's down the road a ways. First we need dpANS3 or something similar. > Just my $0.02. A good $0.02! I don't actually know what I'm talking about really (I can't claim ANY kind of real world experience in Lisp, which is why I still think it might be better to have someone other than me be the name on the request for clarification of dpANS3's status.) I agree that there would be unintended consequences of having code in the spec, but whatever else it might cause it would produce a spec that is COMPLETELY unambiguous in fact, if not necessarily in intent. And for consistency I suspect the former is more important than the latter. In the case of a pressing problem there could be "interum" patches to the spec released, kind of like Windows XP SP2 - CL2010rev001(although hopefully with less disruption than that example.) 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
