--- Jack Unrue <[EMAIL PROTECTED]> wrote:
> Just wanted to pipe in here, because I think I agree with > Larry's comments but want to make an additional point. > > 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. Well, perhaps - but remember, following the spec is voluntary. It would be quite possible for a particular lisp to define alternatives to virtually any part of the spec, and include those as the "default" mode of operation. The "standard" definition can be shadowed or some such. A truly "standard" behavior is available if that is what's needed, and people can build from there doing other things of interest. That way, there is always a "core" common language that can be spoken at need. In a sense ANSI is a "partial" definition - it doesn't standardize the FFI for example, an area which is arguably crying out for standardization. I think Clisp also does something like this - they implement the full "standard" ANSI, but deviate from it deliberately in a few places - at user option they can use either the ANSI standard of Clisp's choice. That makes a lot of sense to me - a standard is at its most useful when it enables universal uniformity. Not "forces", but "enables". If enough people use a deviation from the standard, that's a strong argument for the deviation becoming the new standard. But hopefully by the time something becomes part of the standard, the issues remaining to be debated are minimal, or the benefits of having SOME standard, however suboptimal, outweigh the disadvantages of a suboptimal implementation. 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
