--- Larry Clapp <[EMAIL PROTECTED]> wrote:
> 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. I suppose. But since any standard produced by anybody but ANSI would have minimal "official" weight in any case, the only reason for such a user response to a community produced standard (for some definition of "community") would presumably be some non-negligible benefit obtained via real merit and/or utility of the standard. And in this case, minimal compliance would consist simply of including the spec lisp files and loading them at request. > > 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. :) <<I <3 Packages.>> Parse error ;-) You mean in less than three 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.) Well, I don't know about some of those, but I imagine Linux, Windows, MacOSX, and maybe FreeBSD would be an excellent start. And in the case of FFI I wasn't thinking so much of the actual details as defining some sort of standard high level FFI that lower level FFIs could implement backends for. That way, anybody could write once for the top level FFI and run anywhere the toplevel FFI was implemented. > 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] "Community Lisp will not run (ever) on operating systems or architectures that cannot support this FFI" - I might be OK with that, personally. If a platform can't support the features of the FFI, then the best Community Lisp that could run on that platform would be crippled compared to other FFIs, and true "write once, run anywhere" could never happen in any case. Alternatively, perhaps it could be something like "if OS/compiler supports feature X, it must be handled thus..." I agree a universal FFI would be difficult to specify, but it would be EXTREMELY useful. > 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. I have a feeling language specific features might wind up being inevitable, although minimizing that would be a good thing. Whatever is needed to end the current situation of having to do a different FFI dance for each lisp implementation you want to use a particular library in would be what interests me. > 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 ...) I suppose that makes sense. I suppose the argument "pick an implementation and go with it" makes sense too, for my concerns. When one implementation: a) has a robust, cross platform FFI (cross platform for all major desktop operating systems) b) works with SLIME using all available features on all platforms c) has most of the major significant lisp libraries working well on it (cl-pdf, cl-typesetting, McCLIM, Garnet, etc. etc. etc.) d) is fully ANSI compliant or potentially so e) and is well documented and cleanly coded I might be inclined to agree. But with the lisp community's efforts diffused across so many different implementations and with useful non-trivial work happening uniquely on many different implementations, it's hard to avoid the desire that they all get together on the details below the current "library level" developments. I realize that this is unfair of me though, since I don't actually do any of the implementation work for the various lisps. It's just frustrating to have so many puzzle pieces from so many different puzzles - it makes it hard to assemble the complete picture. > [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." I would agree that you might want to limit the focus of the standard to modern desktop operating systems like Windows, Linux, etc. but on those platforms the lack of one uniform solution makes picking a single lisp for a large scale program using many different libraries a bit of a challenge - there is seldom a "ready made" solution. Anyway. I don't mean any offense, and I appreciate the pointer that my focus may be too narrowly centered on the desktop OS part of Lisp usage. 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
