On 2006-02-05, C Y wrote: > --- Jack Unrue wrote: >> 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.
Well, sort of. In the sense that you can do it, but not in the sense that your users won't yell at you, file bugs, dis you on their blogs, or just not use your non-compliant implementation. This presents a large incentive to comply to the standard if you produce a commercial Lisp environment. > 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. Yes, certainly, we can do that now. I <3 Packages. :) > 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. And an area where standardization could do harm. I don't know for sure, but I would imagine great difficulties would face anyone that tries to define an FFI that would work on a Forth machine *and* a Linux box *and* a Windows box *and* a Palm m505 <cross product with> gcc *and* Intel's cc *and* MS VC *and* AIX's xlc *and* the Forth machine's compiler. (I've pulled some of this out of my ass, I'll admit, but I think you get the idea.) If you put FFI *in the standard*, then you either specify an FFI that can work everywhere (difficult), or you, in effect, deliberately say "Community Lisp will not run (ever) on operating systems or architectures that cannot support this FFI" ... or you define the FFI as optional from the word go.[1] I dunno ... maybe you could say "On POSIX machines with a C core, we require the following C interface, on other architectures all the following macros expand to calls to ERROR". Don't try to define a generic Foreign Function Interface. Define a C-function interface. Allow some leeway. Say "should" a lot instead of "must". That gets you most of the way anyway, for a large part of today's computing environment. (... he said, with exactly zero knowledge of Franz's / Lispworks's / DigiTool's various markets ...) -- Larry [1] "Standardizing FFI" reminds me of "prayer in school" (in the USA). "If you make it strong enough to do any good, it'll do harm. If you make it weak enough not to do any harm, it can't possibly do any good." _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
