[Sorry for possible duplicates messages. I typed this in my
university news server four days ago and I haven't seen it
in the Usenet yet. Hence my use of Deja]
Hi,
I am in a process of doing some major changes to the typechecking
routines of ECLS which mostly implies a non-consing function which
normalizes types for #'subtypep, #'typep and #'coerce.
During this process I have found that ECL, Clisp and CMUCL don't
really complain when they find something which could be a type but
actually is not. Say, for instance that 'FOO is not a type nor a class
name. Then (subtypep 'foo 'integer) gives '(nil nil) in all these
implementations.
I wonder whether it is both portable and ANSI compliant to let the
interpreter complain about these bogus type-specifiers. I do think it
would be the right thing. It would imply that unsupported types
(i.e. conditions, stream classes, etc) would raise errors which is ok
since, after all they are not implemented. Besides, I have browsed the
Hyperspec and there is a list of valid type specifiers which I also
interpret as a support to my opinion.
I would like to hear your thoughs about this.
By the way, the former source release (0.0b) of ECL has a couple of
absolute paths hardcoded in a pair of C files. Removing them will
allow compilation to proceed. I uploaded a fixed set of source
files to http://est202.sub37.uclm.es/jjgarcia/ecls.tgz
Further fixes will have to wait a bit longer because I am working on
making ECLS to bootstrap itself starting only from a C compiler and no
lisp compiled files.
Cheers
Juanjo
--
Juan Jose Garcia Ripoll www: http://est202.sub37.uclm.es/jjgarcia
Dpto. de Matematicas job: ········@ind-cr.uclm.es
E.T.S.I. Industriales home: ····@arrakis.es
Univ. de Castilla-La Mancha, Ciudad Real E-13071 (Spain)
Sent via Deja.com http://www.deja.com/
Before you buy.
From: Tim Bradshaw
Subject: Re: Questions about type specifiers
Date:
Message-ID: <ey3u2hn2qiz.fsf@cley.com>
* worm wrote:
> During this process I have found that ECL, Clisp and CMUCL don't
> really complain when they find something which could be a type but
> actually is not. Say, for instance that 'FOO is not a type nor a class
> name. Then (subtypep 'foo 'integer) gives '(nil nil) in all these
> implementations.
Unless I misread the spec, they aren't allowed to do that in any case
because:
`subtypep is permitted to return the values false and false only
when at least one argument involves one of these type specifiers:
and, eql, the list form of function, member, not, or, satisfies,
or values. (A type specifier `involves' such a symbol if, after
being type expanded, it contains that symbol in a position that
would call for its meaning as a type specifier to be used.) One
consequence of this is that if neither type-1 nor type-2 involves
any of these type specifiers, then subtypep is obliged to
determine the relationship accurately. In particular, subtypep
returns the values true and true if the arguments are equal and do
not involve any of these type specifiers.'
> I wonder whether it is both portable and ANSI compliant to let the
> interpreter complain about these bogus type-specifiers.
I think so.
--tim