From: Drew McDermott
Subject: Standardizing 'package-error' and other black boxes
Date:
Message-ID: <3CDAFCF8.6010108@yale.edu>
Has anyone given any thought to defining more precisely what the
structure of, say, a 'package-error' is? It's easy to write a handler
that catches package errors, but hard to know what to do with them.
But, in Allegro, if you muck around a bit you discover that the error
that prints as
Exporting the symbol so-and-so from the `whatsit' package
would cause some packages that use the `whatsit' package to have
two accessible but distinct symbols with the same print name.
The packages and conflicting symbols are: ...
has as its excl:format-arguments slot something like
(1 (uninterned-version-of-offending symbol) exporting-package
list-of-pairs)
where each element of 'list-of-pairs' is of the form
(package-name conflicting-symbol).
(Of course, there is an excl:format-string slot to which this data
structure fits perfectly.)
So, if you want to catch all the conflicts and, say, do a
shadowing-import to make the errors go away, you can peek into the
excl:format-arguments slot and get the information you want.
Obviously, this is extremely blecherous and implementation-dependent.
I was on the verge of saying, Why don't we standardize the error
classes a bit better, when I realized I would get a flood of
complaints of the form: "Don't just ask for something to be done, do
it!"
So I guess the question is, does there exist a repository of proposed
further standardizations of Common Lisp that Franz, Xanalys, the CMUCL
people, etc. look at in order to synchronize their implementations? Is
there a way to comment on the proposals? Would the existence of such an
institution be a major pain for implementors, or a major help?
In addition to the standard error classes, multiprocessing and
foreign-function interfaces come to mind as things that would be nice
to have informal standards for. Such informal standards might
eventually get moved into some future revision of ANSICL.
-- Drew McDermott
Drew McDermott <··············@yale.edu> writes:
> In addition to the standard error classes, multiprocessing and
> foreign-function interfaces come to mind as things that would be nice
> to have informal standards for.
For FFIs, I think the UFFI project is (partly) an attempt to discover
what should be standardized by creating a portability layer over all
the implementations' FFIs. Of course, there's the added benefit of
being able to use that portability layer now. :)
> Such informal standards might eventually get moved into some future
> revision of ANSICL.
Assuming anyone wants to deal with ANSI any more. But I think most of
what you've discussed here is more in the realm of "extension" than
"modification", so layered standards would work. Some consortium of
the various implementations' developers would be nice, along with, of
course, a few honorary members. :)
The main issue, I think, would be figuring out how to make such a
system affordable for the developers of the non-commercial
implementations, but maybe if we kept the meetings primarily virtual,
it might not be much of an issue. I propose that some influentual
member of the CL community create a mailing list for this. (Yeah yeah,
I'm just shifting the work to someone else, but it's not like I would
be able to manage (what with my not having a decent network connection
for the near future) or get much respect for this myself.)
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- ············@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
From: Steven M. Haflich
Subject: Re: Standardizing 'package-error' and other black boxes
Date:
Message-ID: <3CDB595F.3080104@alum.mit.edu>
Drew McDermott wrote:
> So I guess the question is, does there exist a repository of proposed
> further standardizations of Common Lisp that Franz, Xanalys, the CMUCL
> people, etc. look at in order to synchronize their implementations? Is
> there a way to comment on the proposals? Would the existence of such an
> institution be a major pain for implementors, or a major help?
>
> In addition to the standard error classes, multiprocessing and
> foreign-function interfaces come to mind as things that would be nice
> to have informal standards for. Such informal standards might
> eventually get moved into some future revision of ANSICL.
Yes, it is called INCITS/J13, the comittee formerly known as X3J13.
<enter gentle chiding mode>
You, or Yale, or anyone else who believes he or his organization is
concerned with Lisp standardization is welcome to join at any time.
You can contact me (as Chair of INCITS/J13) or www.incits.org.
</enter gentle chiding mode>
Now, before all the great wags of comp.lang.lisp chime in about how
laborious are the official standards processes, I'd like on one hand to
agree, but on the other hand to point out that a lot has been done in
the past few years to streamline the standardization process so that it
is more compatible with internet time. It is still long, of course, for
reasons I won't expound here, but there is a recent "fast track" process
whereby an existing de-facto standard can be adopted in a process
requiring only a few months. Of course, this works only if there already
exists a well-drafted text for a standard at which one can point. The
issues you name are more in the line of new work, but if people were
serious and already mostly in agreement about the content of the
standard, extensions to ANSI CL could still be enacted in something like
a year.
From: Don Geddis
Subject: Re: Standardizing 'package-error' and other black boxes
Date:
Message-ID: <m3helffpcd.fsf@maul.geddis.org>
Drew McDermott <··············@yale.edu> writes:
> So I guess the question is, does there exist a repository of proposed further
> standardizations of Common Lisp that Franz, Xanalys, the CMUCL people,
> etc. look at in order to synchronize their implementations? Is there a way
> to comment on the proposals? Would the existence of such an institution be a
> major pain for implementors, or a major help?
I've long thought that would be a great idea. A single location where could
be collected various well-thought out proposals to extend Common Lisp. New
proposals could be posted in order to solicit criticism (much as Franz already
does with some of their efforts). Multiple incompatible proposals could also
exist.
But at least if an implementor was interested in avoiding gratuitous
incompatibility, they could look to such a site and say, "my version of Lisp
corresponds to ANSI, plus the extensions documented in proposals #3, #7, and
#8." That would allow bug reports along the line "the implementation doesn't
correspond to ANSI," to also permit "it misses the spec on proposal #7 (that
you are claiming to adhere to)".
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org ···@geddis.org
In article <··············@maul.geddis.org>,
Don Geddis <···@geddis.org> wrote:
> Drew McDermott <··············@yale.edu> writes:
> > So I guess the question is, does there exist a repository of proposed further
> > standardizations of Common Lisp that Franz, Xanalys, the CMUCL people,
> > etc. look at in order to synchronize their implementations? Is there a way
> > to comment on the proposals? Would the existence of such an institution be a
> > major pain for implementors, or a major help?
>
> I've long thought that would be a great idea. A single location where could
> be collected various well-thought out proposals to extend Common Lisp. New
> proposals could be posted in order to solicit criticism (much as Franz already
> does with some of their efforts). Multiple incompatible proposals could also
> exist.
>
> But at least if an implementor was interested in avoiding gratuitous
> incompatibility, they could look to such a site and say, "my version of Lisp
> corresponds to ANSI, plus the extensions documented in proposals #3, #7, and
> #8." That would allow bug reports along the line "the implementation doesn't
> correspond to ANSI," to also permit "it misses the spec on proposal #7 (that
> you are claiming to adhere to)".
The Scheme community has "SRFI", http://srfi.schemers.org/ .
" The "Scheme Requests for Implementation" (SRFI) process is a
new approach to helping Scheme users to write portable and yet
useful code. It is a forum for people interested in coordinating
libraries and other additions to the Scheme language between
implementations. "
Sounds like a good idea to me.