CLIM mail archive
[Prev][Next][Index][Thread]
Re: menu-bar
Date: Thu, 5 May 1994 18:55:37 -0400
From: miller@cs.rochester.edu
To: "William M. York" <york@parc.xerox.com>
Cc: colin@franz.com, ncramer@BBN.COM, abramson@verdi.sra.com, clim@BBN.COM
Subject: Re: menu-bar
References: <9405050032.AA09414@vapor.Franz.COM>
<94May5.154016pdt.32390@sparkie.parc.xerox.com>
>>>>> "William" == William M York <york@parc.xerox.com> 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
language extensions.
Regards,
Brad Miller
I also believe that vendor-supplied extensions are a good thing.
I would only ask that the "clim" package be sacrosanct, much like
the ANSI "common-lisp" package. It is good hygiene to put new
symbols in other packages, "clim-extensions" for example.
The keyword :menu-bar wouldn't apply, of course, but the class
name MENU-BAR would.
jeff morrill
Follow-Ups:
References:
Main Index |
Thread Index