Some error/condition standardization anyone?

[Marco Antoniotti]

Hi

I have the following problem (here below in CCL and LW)

CCL:

marcoxa$ ccl
AM I BEING LOADED?
Welcome to Clozure Common Lisp Version 1.5-r13651 (DarwinX8632)!
? (ignore-errors (read))
foo::bar

NIL
#<CCL::SIMPLE-READER-ERROR #xC48489E>
?


LWM:

CL-USER 1 > (ignore-errors (read))
foo:
NIL
#<CONDITIONS:PACKAGE-NOT-FOUND-READER 21BA3B93>

CL-USER 2 >

Other Lisps behave similarly. I.e. they don't agree on the type of the error that they need to generate.

Now, this is a specific case for me: having a consistent READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS error signaled would simplify some code writing.

Doesn't anybody think that it would be a good thing to have a CDR suggesting an agreed upon extension of the CL standard ERROR/CONDITION hierarchy?

Cheers

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.

[Didier Verna]

Content preview: Marco Antoniotti wrote: > Now, this is a specific case for
me: having a consistent > READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS

error signaled would simplify some code writing. > > Doesn't anybody think

that it would be a good thing to have a CDR > suggesting an agreed upon extension
of the CL standard ERROR/ > CONDITION hierarchy? [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/459>

Now, this is a specific case for me: having a consistent
READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS
error signaled would simplify some code writing.
Doesn't anybody think that it would be a good thing to have a CDR
suggesting an agreed upon extension of the CL standard ERROR/
CONDITION hierarchy?

+1

I have faced the same problem in the past, although on a different set
of conditions.

[Steve Haflich]

Post by Marco Antoniotti
Now, this is a specific case for me: having a consistent
READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS
error signaled would simplify some code writing.

I agree with the sentiment, what is the specific proposal may need more
work. Would you want this same condition to be signaled for this form?

(defpackage :foo
(:use :not-yet-loaded))

That's an error, but not a reader error the way reading not-yet-loaded:bar
would be. Still, it would be nice if these shared a common superclass
because what the application might want to do to handle would be the same.
Unfortunately, the condition system does not portably support multiple
inheritance.

[Marco Antoniotti]

Content preview: On Jun 27, 2011, at 19:26 , Steve Haflich wrote: > > Marco
Antoniotti wrote: > > > > > Now, this is a specific case for me: having a
consistent > > > READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS

error signaled would simplify some code writing. > > I agree with the

sentiment, what is the specific proposal may need more work. [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/461>

Now, this is a specific case for me: having a consistent
READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS
error signaled would simplify some code writing.

I agree with the sentiment, what is the specific proposal may need more work.

Of course... this is jut one example. There may be other cases, plus unexplored ones: FILE-ERROR is rather underspecified, so are PARSE-ERROR and PROGRAM-ERROR. I'd like to see a discussion started....

Would you want this same condition to be signaled for this form?
(defpackage :foo
(:use :not-yet-loaded))
That's an error, but not a reader error the way reading not-yet-loaded:bar would be. Still, it would be nice if these shared a common superclass because what the application might want to do to handle would be the same.

These would both be PACKAGE-ERRORs, but different

Unfortunately, the condition system does not portably support multiple inheritance.

Yes, I'll grant you that and see where you are going. This is another CDR: The Condition system should use the CLOS algorithm to determine/use/offer multiple inheritance derived properties.

Cheers

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.

[Robert Strandh]

Content preview: Hello Marco, Marco Antoniotti writes: > > Doesn't anybody
think that it would be a good thing to have a CDR > suggesting an agreed upon
extension of the CL standard > ERROR/CONDITION hierarchy? Definitely! While
working on a portable implementation of the functions in the sequences dictionary
I found that I frequently wanted more specific conditions to indicate that
some sequence is not a proper sequence, that some values <start,end> are
not valid bounding index designators, etc. [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/462>

Hello Marco,

Post by Marco Antoniotti
Doesn't anybody think that it would be a good thing to have a CDR
suggesting an agreed upon extension of the CL standard
ERROR/CONDITION hierarchy?

Definitely! While working on a portable implementation of the
functions in the sequences dictionary I found that I frequently wanted
more specific conditions to indicate that some sequence is not a
proper sequence, that some values <start,end> are not valid bounding
index designators, etc.

I would certainly consider contributing to such a CDR document, in
particular in areas where I have already experienced the need for more
specific conditions.

Take care,

[Matthew Mondor]

Content preview: On Tue, 28 Jun 2011 01:16:16 +0200 Robert Strandh <strandh-***@public.gmane.org>
wrote: > I would certainly consider contributing to such a CDR document,
in > particular in areas where I have already experienced the need for more

specific conditions. [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/463>

On Tue, 28 Jun 2011 01:16:16 +0200

I would certainly consider contributing to such a CDR document, in
particular in areas where I have already experienced the need for more
specific conditions.

It would also be nice to suggest behaviour for character
encoding/decoding conditions and recovery restarts. In implementations
supporting unicode streams for instance, UTF-8 decoding/encoding errors
can happen inadvertently on streams with unicode external formats, and
user code must be able to cope gracefully.

[Marco Antoniotti]

Content preview: On Jun 28, 2011, at 11:57 , Matthew Mondor wrote: > On Tue,
28 Jun 2011 01:16:16 +0200 > Robert Strandh <strandh-***@public.gmane.org> wrote: > >>
I would certainly consider contributing to such a CDR document, in >> particular
in areas where I have already experienced the need for more >> specific conditions.

Post by Matthew Mondor

It would also be nice to suggest behaviour for character > encoding/decoding

conditions and recovery restarts. In implementations > supporting unicode
streams for instance, UTF-8 decoding/encoding errors > can happen inadvertently
on streams with unicode external formats, and > user code must be able to
cope gracefully. [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/465>

Post by Matthew Mondor
On Tue, 28 Jun 2011 01:16:16 +0200

I would certainly consider contributing to such a CDR document, in
particular in areas where I have already experienced the need for more
specific conditions.

It would also be nice to suggest behaviour for character
encoding/decoding conditions and recovery restarts. In implementations
supporting unicode streams for instance, UTF-8 decoding/encoding errors
can happen inadvertently on streams with unicode external formats, and
user code must be able to cope gracefully.

This is IMHO very complicated instead, for the simple reason that it seems to me that each implementation disagrees on the actual interface to UNICODE and UTF-8. IMHO what is needed before this is a "standardization" of UNICODE, UTF-8, etc features across implementations. Whether this is achievable or not it is a matter of debate.

--
MA

Post by Matthew Mondor
--
Matt
_______________________________________________
pro mailing list
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.

[Marco Antoniotti]

Content preview: On Jun 28, 2011, at 02:48 , Daniel Weinreb wrote: > > I'd
love to see this standardized. Should we put in the work to come > up with
a proposal before checking with the implementors to > see whether they're
interested in implementing whatever > we come up with? There might be compatibility
issues, > too. It would have to be a pretty big proposal to cover > even
the basic cases... -- Dan [...]

Content analysis details: (-0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/464>

I'd love to see this standardized. Should we put in the work to come
up with a proposal before checking with the implementors to
see whether they're interested in implementing whatever
we come up with? There might be compatibility issues,
too. It would have to be a pretty big proposal to cover
even the basic cases... -- Dan

I agree that this should be worked on cooperatively. I do not know if this should be a "big" proposal. My feeling is that the people interested (I am one) should come up with a preliminary outline with an initial goal of being the least intrusive possible into an implementation guts.

Cheers
--
MA

===========================================

Post by Marco Antoniotti
Now, this is a specific case for me: having a consistent
READER-ERROR-BECAUSE-THERE-IS-NO-SUCH-PACKAGE-THAT-THE-SYSTEM-KNOWS
error signaled would simplify some code writing.

I agree with the sentiment, what is the specific proposal may need more work.

Of course... this is jut one example. There may be other cases, plus unexplored ones: FILE-ERROR is rather underspecified, so are PARSE-ERROR and PROGRAM-ERROR. I'd like to see a discussion started....

Would you want this same condition to be signaled for this form?
(defpackage :foo
(:use :not-yet-loaded))
That's an error, but not a reader error the way reading not-yet-loaded:bar would be. Still, it would be nice if these shared a common superclass because what the application might want to do to handle would be the same.

These would both be PACKAGE-ERRORs, but different

Unfortunately, the condition system does not portably support multiple inheritance.

Yes, I'll grant you that and see where you are going. This is another CDR: The Condition system should use the CLOS algorithm to determine/use/offer multiple inheritance derived properties.
Cheers
--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY
Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.
_______________________________________________
pro mailing list
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro

--
Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.

[Erik Winkels]

Content preview: On 28 jun. 2011, at 13:34, Marco Antoniotti <antoniotti.marco-***@public.gmane.org>
wrote: > > I agree that this should be worked on cooperatively. I do not
know if this should be a "big" proposal. Perhaps a first step would be gathering
up all the work-around / wrapper code that people have produced to deal with
these issues? [...]

Content analysis details: (-100.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[194.109.24.35 listed in list.dnswl.org]
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/473>

Post by Marco Antoniotti
I agree that this should be worked on cooperatively. I do not know if this should be a "big" proposal.

Perhaps a first step would be gathering up all the work-around / wrapper code that people have produced to deal with these issues?

[Pascal Costanza]

Content preview: On 27 Jun 2011, at 17:47, Marco Antoniotti wrote: > Doesn't
anybody think that it would be a good thing to have a CDR suggesting an agreed
upon extension of the CL standard ERROR/CONDITION hierarchy? [...]

Content analysis details: (-102.3 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[134.184.129.112 listed in list.dnswl.org]
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/475>

Post by Marco Antoniotti
Doesn't anybody think that it would be a good thing to have a CDR suggesting an agreed upon extension of the CL standard ERROR/CONDITION hierarchy?

I think this is a good idea, and would be of great practical value.

It may a good idea to use ISLISP as a starting point. ISLISP is more or less a subset of Common Lisp with an almost identical condition system, but has a defined condition hierarchy that is more detailed than that of ANSI CL. Although there are not a lot of ISLISP implementations around, I think it would be of value to try to be compatible with ISLISP in this (and other) regards.

See http://www.islisp.info/specification.html

Pascal


--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.