On 2006-02-03, C Y wrote: > --- root wrote: >> Will we do the same thing with Lisp? Why? It should be the case >> that the whole X3J13 document is interwoven with the actual code >> that implements it. If I REALLY want to know how setf forms work >> then I can read both the standard description and the actual >> implementation code in the same chapter. > [snip] > I would actually like to see it taken one step further - I think > programming language standards should consist of both text and code > as a literate document, and that way the spec is not only defined > unambiguously but is also runnable - the spec not only will DEFINE > the functionality, it will also PROVIDE it, with as much of the > logic as makes sense defined in the language itself, and with the > minimal necessary assembler code or other bootstrapping code present > and defined in another, also standard language. [snip] > If and when a really Free version of dpANS3 is available, I think it > will be a highly worthwhile project to take CMUCL and SBCL, and > start weaving the best available code from both into the spec > document. I don't know if that would be a Gardner's project or not, > but either way very much worth doing. (And talk about a perfect way > to learn the in-depth gory details of Lisp...)
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." 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.) Test cases, on the other hand, you could put in the spec. Test cases verify behavior, but don't (necessarily) define implementation. Just my $0.02. -- Larry _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
