CLIM mail archive
Date: Thu, 5 May 1994 15:55:37 -0700
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
>>>>> "William" == William M York <firstname.lastname@example.org> writes:
William> Of course, I don't have to tell you where I stand on these
William> issues, but I thought that I'd raise the point as a way of
William> publicly checking the state of things. I think everyone
William> loses in the long run when individual vendors extend
William> outside the spec, even when those extensions are good ideas
William> in and of themselves.
I disagree with this completely. If that had been the attitude with CL,
then nobody would have any support for Defsystem, Multiprocessing, or
FFI (to name three :-), at all without "ANSI permission".
Vendors should be able (need to be able) to provide upward compatible
extensions if for no other reason than to support their customers. So
long as these are clearly identified as non-portable extensions, I don't
see a problem, and they provide a valuable testbed for future portable
I didn't make myself clear. I am not objecting to continued
development. I am concerned about tinkering with the portable "core"
of CLIM without any mechanism in place for updating all the various
vendor releases. As several have said, vendor-specific extensions,
when clearly marked as such (e.g. the proposed a separate package for
extensions) are fine. However, the reality is that people are now
writing CLIM applications in one environment which will not port
freely to other platforms, and are apparently doing so without
intending to, if I can judge by the "Hey, my app doesn't work on the
XXX platform!" bug reports I see.
If no one in the CLIM user community cares about this, I am certainly
not going to harp on it. I long ago expended whatever resources I had
set aside for trying to direct the course of CLIM (though I remain an
interested party given that I need to track the current state of
things in order to implement a specific platform port). I merely
thought that I would raise the issue as an opportunity for people to
voice their opinions or concerns. Given the lack of response, I say
"carry on". I am happier to have diverging CLIM development efforts
than no CLIM development efforts, but I think that the added effort to
keep things in synch would be worthwhile.
As for your specific CL examples, DEFSYSTEM is properly outside the
definition of the language, and the differences between Lisp vendor
implementations of the multi-tasking and FFI mechanisms is one of the
biggest headaches for writers of portable CL programs. All three
examples far pre-date the standardization of the language. I think
that a better analogy to CLIM would be different keyword options taken
by the sequence functions in different CL implementations.
Main Index |