Is this form legal?
(HANDLER-CASE 23 (:NO-ERROR (V) (1+ V)) (ERROR NIL 42))
It appears that the spec requires that the :NO-ERROR clause be the last
one:
Macro HANDLER-CASE
Syntax:
handler-case expression [[{error-clause}* | no-error-clause]] => result*
clause::= error-clause | no-error-clause
error-clause::= (typespec ([var]) declaration* form*)
no-error-clause::= (:no-error lambda-list declaration* form*)
What is the appropriate action?
signal an error? (GCL: handler-case not implemented :-)
warn and return 23? (CLISP)
warn and return 24?
return 24? (Allegro, LispWorks, CMUCL, CormanLisp)
return 23?
Thanks!
--
Sam Steingold (http://www.podval.org/~sds)
(let((a'(list'let(list(list'a(list'quote a)))a)))`(let((a(quote ,a))),a))
In article <·············@xchange.com>, Sam Steingold <···@gnu.org> wrote:
>Is this form legal?
>
>(HANDLER-CASE 23 (:NO-ERROR (V) (1+ V)) (ERROR NIL 42))
>
>It appears that the spec requires that the :NO-ERROR clause be the last
>one:
>
>Macro HANDLER-CASE
>Syntax:
>handler-case expression [[{error-clause}* | no-error-clause]] => result*
>clause::= error-clause | no-error-clause
>error-clause::= (typespec ([var]) declaration* form*)
>no-error-clause::= (:no-error lambda-list declaration* form*)
>
>What is the appropriate action?
>signal an error? (GCL: handler-case not implemented :-)
>warn and return 23? (CLISP)
>warn and return 24?
>return 24? (Allegro, LispWorks, CMUCL, CormanLisp)
>return 23?
I think it should be the same as:
(handler-case 23 (nonexistent-condition (v) (1+ v)) (error nil 42))
I.e. outside the last clause, the keyword :NO-ERROR has no special meaning,
so it should try to look it up as the name of a condition type (I don't
think there's a restriction against using keywords as condition names,
although it's certainly a bad idea).
Since a symbol that doesn't name an existing type is not a valid typespec,
I think the consequences of this code are undefined, so any behavior is
permitted. So as long as you don't have a condition type named :NO-ERROR,
an implementation could recognize this keyword outside the last clause as
well (as Allegro, LispWorks, CMUCL, and CormanLisp all seem to do -- but
I'll bet they don't do the "right" thing if you define a :NO-ERROR
condition).
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Sam Steingold wrote:
> Is this form legal?
>
> (HANDLER-CASE 23 (:NO-ERROR (V) (1+ V)) (ERROR NIL 42))
>
> It appears that the spec requires that the :NO-ERROR clause be the last
> one:
>
> Macro HANDLER-CASE
> Syntax:
> handler-case expression [[{error-clause}* | no-error-clause]] => result*
> [...]
That is strange. Why do you think the spec requires that no-error is last?
What does the [[..|..]] notation mean? If it is the same as used in CLHS, it
explicitly requires no ordering. As I read the CLHS, the no-error-clause is
optional and if used can be in any order in relation to the error-clauses
(even in between error clauses).
//Lennart
Lennart Staflin <·····@lysator.liu.se> writes:
> Sam Steingold wrote:
>
> > Is this form legal?
> >
> > (HANDLER-CASE 23 (:NO-ERROR (V) (1+ V)) (ERROR NIL 42))
> >
> > It appears that the spec requires that the :NO-ERROR clause be the last
> > one:
> >
> > Macro HANDLER-CASE
> > Syntax:
> > handler-case expression [[{error-clause}* | no-error-clause]] => result*
> > [...]
>
> That is strange. Why do you think the spec requires that no-error is last?
> What does the [[..|..]] notation mean? If it is the same as used in CLHS, it
> explicitly requires no ordering. As I read the CLHS, the no-error-clause is
> optional and if used can be in any order in relation to the error-clauses
> (even in between error clauses).
Indeed, I don't see anything in the HANDLER-CASE definition that would
require an ordering, and certainly the notation:
[[{error-clause}* | no-error-clause]]
means the same as:
{error-clause}* [no-error-clause] {error-clause}*
That is, if I can still read this notation we invented, it is to be read:
any sequence hving elements in any order
chosen from among possible elements which are
any number of error-clauses
and zero or one no-error-clauses.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>Indeed, I don't see anything in the HANDLER-CASE definition that would
>require an ordering, and certainly the notation:
> [[{error-clause}* | no-error-clause]]
>means the same as:
> {error-clause}* [no-error-clause] {error-clause}*
>That is, if I can still read this notation we invented, it is to be read:
> any sequence hving elements in any order
> chosen from among possible elements which are
> any number of error-clauses
> and zero or one no-error-clauses.
Interesting. Your original Conditions proposal to X3J13, which is
incorporated essentially verbatim in CLTL2, does say that the
no-error-clause must be last. It says, "As a special case, the <typespec>
can also be the symbol :NO-ERROR in the last clause." I don't remember
X3J13 making any conscious decision to change that (there's no relevant
cleanup mentioned in the HyperSpec), do you? Did the document editor slip
this change in silently, or is my memory faulty?
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <······@genuity.net> writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> >Indeed, I don't see anything in the HANDLER-CASE definition that would
> >require an ordering, and certainly the notation:
> > [[{error-clause}* | no-error-clause]]
> >means the same as:
> > {error-clause}* [no-error-clause] {error-clause}*
> >That is, if I can still read this notation we invented, it is to be read:
> > any sequence hving elements in any order
> > chosen from among possible elements which are
> > any number of error-clauses
> > and zero or one no-error-clauses.
>
> Interesting. Your original Conditions proposal to X3J13, which is
> incorporated essentially verbatim in CLTL2, does say that the
> no-error-clause must be last. It says, "As a special case, the <typespec>
> can also be the symbol :NO-ERROR in the last clause."
Yeah, I double-checked this (not that I doubted you, but just for
independent confirmation) and agree it does say that in Revision 18
of the condition system.
> I don't remember
> X3J13 making any conscious decision to change that (there's no relevant
> cleanup mentioned in the HyperSpec), do you? Did the document editor slip
> this change in silently, or is my memory faulty?
My sources are offline at the moment so I can't check.
But a few moments thought suggest that either first or last should be
conceptually rational, so maybe that's the reason for the change.
Not sure why it's allowed anywhere, but maybe just generality.
The no-error and error clauses aren't type-overlappable, so aren't
really forced to be ordered.
As to whether I accidentally or intentionally slipped this in, or
whether it was directed as a rider in some other issue, I'm not sure
without the source. I will note, though, that there are surely some
things I was directed to do where I screwed up and didn't bracket the
change with a marker saying I did the change for reason of that issue.
That change-due-to-cleanup tracking was done manually, not
automatically, and it was sufficiently easy to screw up that I'm just
sure it happened more than once.