The spec for TYPECASE and ETYPECASE talks about `normal-clauses' and
`otherwise-clauses'. ETYPECASE can't have an otherwise-clause in the
normal way.
A normal-clause is (type form*)
An otherwise-clause is ({otherwise | t} form*)
type is a type specifier
This is kind of marginally consistent (but it is consistent, I
think). T is a type specifier, so, is:
(etypecase x
(t "this is OK"))
OK or not? I think it isn't, but I'm not sure. It probably doesn't
matter since such a form is rather a silly use of ETYPECASE. But on
the other hand I can imagine programs generating code like this.
--tim
Tim Bradshaw <···@cley.com> writes:
> The spec for TYPECASE and ETYPECASE talks about `normal-clauses' and
> `otherwise-clauses'. ETYPECASE can't have an otherwise-clause in the
> normal way.
>
> A normal-clause is (type form*)
> An otherwise-clause is ({otherwise | t} form*)
> type is a type specifier
>
> This is kind of marginally consistent (but it is consistent, I
> think). T is a type specifier, so, is:
>
> (etypecase x
> (t "this is OK"))
>
> OK or not? I think it isn't, but I'm not sure. It probably doesn't
> matter since such a form is rather a silly use of ETYPECASE. But on
> the other hand I can imagine programs generating code like this.
It's OK.
The clause you're showing isn't a t/otherwise clause (because
etypecase doesn't define such a clause). It is just a clause.
We got tripped up on this, and don't do the right thing in 6.2
[although the workaround is to say ((t) "this is OK") instead ].
However, I have changed it in our next version, so it will allow
the atomic form of the type.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> (etypecase x
> (t "this is OK"))
>
> OK or not? I think it isn't, but I'm not sure.
Quick, sweep this under the rug before some comp.lang.schemer stumbles on it!
;)
Kaz Kylheku wrote:
> Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
>
>> (etypecase x
>> (t "this is OK"))
>>
>>OK or not? I think it isn't, but I'm not sure.
>
>
> Quick, sweep this under the rug before some comp.lang.schemer stumbles on it!
It's ok. In fact, a test much like this is in the gcl ansi-tests.
(Similar tests exist for CCASE, ECASE, and CTYPECASE.)
The reason it is ok is that ETYPECASE contains a list of
normal clauses only, so the final clause is a normal clause.
Paul
Paul F. Dietz <·····@dls.net> wrote:
+---------------
| Kaz Kylheku wrote:
| > Tim Bradshaw <···@cley.com> wrote:
| >> (etypecase x
| >> (t "this is OK"))
| >>OK or not? I think it isn't, but I'm not sure.
| > Quick, sweep this under the rug before some comp.lang.schemer stumbles on it!
| It's ok. In fact, a test much like this is in the gcl ansi-tests.
| (Similar tests exist for CCASE, ECASE, and CTYPECASE.)
+---------------
Oops! CMUCL thinks otherwise (pun intended!):
> (etypecase 'foo
(t "this is OK"))
Error in function COMMON-LISP::CASE-BODY:
No default clause allowed in ETYPECASE: (T "this is OK")
...
Restarts:
0: [ABORT] Return to Top-Level.
0] vso 4
(DOLIST (CASE CASES)
(COND ((ATOM CASE) (ERROR "~S -- Bad clause in ~S." CASE NAME))
((MEMQ (CAR CASE) '(T OTHERWISE))
(IF ERRORP
(#:***HERE***
(ERROR "No default clause allowed in ~S: ~S" NAME CASE))
(PUSH `(,T ,NIL ,@(REST CASE)) CLAUSES)))
((AND MULTI-P (LISTP (FIRST CASE)))
(SETF KEYS (APPEND (FIRST CASE) KEYS))
(PUSH
`((OR
,@(MAPCAR #'(LAMBDA (KEY) `(,TEST ,KEYFORM-VALUE ',KEY))
(FIRST CASE)))
,NIL ,@(REST CASE))
CLAUSES))
(T (PUSH (FIRST CASE) KEYS)
(PUSH `((,TEST ,KEYFORM-VALUE ',(FIRST CASE)) ,NIL ,@(REST CASE))
CLAUSES))))
Hmmm... But if (listp (first case))... ;-} ;-}
> (etypecase 'foo
((or t) "this is OK"))
"this is OK"
>
-Rob
-----
Rob Warnock, PP-ASEL-IA <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Paul F. Dietz <·····@dls.net> wrote:
> +---------------
> | Kaz Kylheku wrote:
> | > Tim Bradshaw <···@cley.com> wrote:
> | >> (etypecase x
> | >> (t "this is OK"))
> | >>OK or not? I think it isn't, but I'm not sure.
> | > Quick, sweep this under the rug before some comp.lang.schemer stumbles on it!
> | It's ok. In fact, a test much like this is in the gcl ansi-tests.
> | (Similar tests exist for CCASE, ECASE, and CTYPECASE.)
> +---------------
>
> Oops! CMUCL thinks otherwise (pun intended!):
>
> > (etypecase 'foo
> (t "this is OK"))
Run a more recent CMUCL...
CMU Common Lisp 18e-pre, built 2003-01-26 on melbourne, running on localhost.localdomain
Send questions to ··········@cons.org. and bug reports to ·········@cons.org.
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (etypecase 'foo
(t "this is OK"))
Warning: Bad style to use T or OTHERWISE in ECASE or CCASE
; In: ETYPECASE 'FOO
; (ETYPECASE 'FOO (T "this is OK"))
; Warning: Bad style to use T or OTHERWISE in ECASE or CCASE
;
"this is OK"
*
Paul
In article <······················@speakeasy.net>,
Rob Warnock <····@rpw3.org> wrote:
>Paul F. Dietz <·····@dls.net> wrote:
>+---------------
>| Kaz Kylheku wrote:
>| > Tim Bradshaw <···@cley.com> wrote:
>| >> (etypecase x
>| >> (t "this is OK"))
>| >>OK or not? I think it isn't, but I'm not sure.
>| > Quick, sweep this under the rug before some comp.lang.schemer stumbles on it!
>| It's ok. In fact, a test much like this is in the gcl ansi-tests.
>| (Similar tests exist for CCASE, ECASE, and CTYPECASE.)
>+---------------
>
>Oops! CMUCL thinks otherwise (pun intended!):
>
> > (etypecase 'foo
> (t "this is OK"))
>
> Error in function COMMON-LISP::CASE-BODY:
> No default clause allowed in ETYPECASE: (T "this is OK")
> ...
While this error seems inappropriate, a warning might be reasonable.
What's the point of using ETYPECASE rather than TYPECASE if you explicitly
handle all types?
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, Woburn, 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.
From: Tim Bradshaw
Subject: Re: An obscurity with ETYPECASE
Date:
Message-ID: <ey3lm0msnts.fsf@cley.com>
* Barry Margolin wrote:
> While this error seems inappropriate, a warning might be reasonable.
> What's the point of using ETYPECASE rather than TYPECASE if you explicitly
> handle all types?
The case I thought of is where the form is being generated by
something which wants to make sure that unknown types do get an error,
but which isn't smart enough to notice that the types it is making
clauses for include T.
--tim