[Openmcl-devel] Type declaration question

[Dan Weinreb]

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.

-- Dan

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
> Sudhir
>  
> 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  
>> shorthand;
>> 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,  
>> though
>> 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  
>> declarations
>> 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  
>> declaration);
>> 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?
>>>  
>>> Thanks
>>> Sudhir
>>>  
>>> _______________________________________________
>>> Openmcl-devel mailing list
>>> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
>>> http://clozure.com/mailman/listinfo/openmcl-devel
>>>  
>>>  
>>>       
>  
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com <mailto:Openmcl-devel at clozure.com>
> http://clozure.com/mailman/listinfo/openmcl-devel
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20090527/870d7663/attachment.htm>