[Openmcl-devel] Type declaration question
dlw at itasoftware.com
Wed May 27 10:59:47 PDT 2009
OK. The only issue is that the Hyperspec is internally inconsistent.
I think we agree that the following is just a mistake:
"(typespec var*) is an abbreviation for (type typespec var*)".
So what CCL is doing is correct.
Kent M Pitman wrote:
> I didn't go back and research what I wrote, but in my mind I think
> (/typespec/ /var/*) is only usable for a restricted set of names
> (mostly legacy names like fixnum, etc. just as for many [but maybe not
> the exact same set] of those names there are type predicates by name
> rather than the TYPEP function) and that the only generally safe thing
> to do in type declarations is (TYPE /typespec/ /var/*). It is true
> that for all valid (/typespec/ /var/*) it means (TYPE /typespec/
> /_var_/*), but maybe there is a passage that has this restriction
> which is just hidden, hard to find, or exists only in my mind. J
> *From:* Dan Weinreb [mailto:dlw at itasoftware.com]
> *Sent:* Tuesday, May 26, 2009 3:51 PM
> *To:* Sudhir Shenoy
> *Cc:* Gary Byers; Openmcl-devel Devel; Kent Pitman
> *Subject:* Re: [Openmcl-devel] Type declaration question
> [CC'ing Kent Pitman, just in case he's interested, even
> though it's "not his job" any more. Kent, start at the
> bottom of this mail, as usual...]
> Sudhir Shenoy wrote:
> Hi Gary,
> Thanks for that (as always) detailed reply. So, I guess the
> declaration was being silently ignored prior to this.
> However, in the Hyperspec (under the section on Declaration TYPE,
> i.e., Body/d_type.htm), it is explicitly stated (in Notes) that
> "(typespec var*) is an abbreviation for (type typespec var*)".
> Indeed, it does, and that's inconsistent with section 3.3.2, so we have
> a problem.
> I don't
> know if this applies to compound type specifiers but in any case it is
> no biggie since I can simply use the longer form everywhere.
> Yes, I think that's a good idea.
> Many thanks
> On May 26, 2009, at 11:20 AM, Gary Byers wrote:
>> "(DECLARE (TYPE (UNSIGNED-BYTE 64) FOO))" says that FOO is of type
>> (UNSIGNED-BYTE 64) within the scope of that declaration.
>> In some cases, the TYPE declaration specifier can be omitted;
>> "(DECLARE (FIXNUM FOO)) is shorthand for "(DECLARE (TYPE FIXNUM FOO)".
>> The spec may be a little unclear about which cases allow this
>> section 3.3.2 describes a declaration as being something whose CAR
>> is a "declaration identifier", and the glossary defines a "declaration
>> identifier" to be one of a predefined set of symbols or a symbol which
>> specifies a type; it doesn't seem to allow compound type specifiers
>> (like (UNSIGNED-BYTE 64)) to be used as declaration identifiers,
>> other passages in the spec suggest that they should be allowed here.
>> (See <http://trac.clozure.com/openmcl/ticket/465>).
>> I don't think that CCL has ever allowed compound type specifiers to
>> be used as declaration identifiers. Prior to some changes that Gail
>> made in the trunk a few weeks ago, it tended to quietly ignore
>> that it couldn't make sense of (and that would include cases where a
>> compound type specifier was being used as shorthand for a TYPE
>> a warning is now signaled in that case.
>> On Tue, 26 May 2009, Sudhir Shenoy wrote:
>>> Can anyone tell me what the proper declaration for a 64 bit unsigned
>>> integer is? I was using "(declare ((unsigned-byte 64) foo))" which I
>>> am fairly sure worked prior to CCL 1.3 but now I get a compilation
>>> warning and the fasl is not generated. I checked the CLHS and there
>>> doesn't seem to be an upper bound on the number of bits in the
>>> unsigned-byte declaration.
>>> I have this in some low level i/o conversion (reading in a IEEE float
>>> value of 8 bytes and converting to a Lisp number) code where I use
>>> (ldb (byte 1 63) foo) to extract the sign-bit, for example. Is
>>> there a
>>> better way to do this?
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel