Hi,
just a set of probably stupid questions.
1) Given how upgrading of array elements is described in the ANSI
spec, it is impossible for an implementation to support specialized
arrays whose elements are (UNSIGNED-BYTE 8) if it also wants to
provide specialized arrays with elements of type (SIGNED-BYTE 8). Am I
correct?
2) Assuming that the answer to 1) is T, how I can give ECL access to
all of the possible array types of C? Would that be impossible?
As a side note, currently, ECL supports specialized arrays with
elements BIT, (BYTE 8), (UNSIGNED-BYTE 8), FIXNUM, CHARACTER,
SHORT-FLOAT, LONG-FLOAT and T.
Best regards,
Juanjo
In article <···························@posting.google.com>,
Juanjo <····@arrakis.es> wrote:
>1) Given how upgrading of array elements is described in the ANSI
>spec, it is impossible for an implementation to support specialized
>arrays whose elements are (UNSIGNED-BYTE 8) if it also wants to
>provide specialized arrays with elements of type (SIGNED-BYTE 8). Am I
>correct?
I don't think so. Which part of the description do you think prohibits it?
Neither of those types is a subtype of the other, but even if they were I
don't think there's anything prohibiting specialized arrays for subtypes.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, 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.
Barry Margolin <··············@level3.com> writes:
> In article <···························@posting.google.com>,
> Juanjo <····@arrakis.es> wrote:
>>1) Given how upgrading of array elements is described in the ANSI
>>spec, it is impossible for an implementation to support specialized
>>arrays whose elements are (UNSIGNED-BYTE 8) if it also wants to
>>provide specialized arrays with elements of type (SIGNED-BYTE 8). Am I
>>correct?
>
> I don't think so. Which part of the description do you think prohibits it?
> Neither of those types is a subtype of the other, but even if they were I
> don't think there's anything prohibiting specialized arrays for subtypes.
This is probably the hideously amusing "specialized array element
types must form a group under type intersection" requirement that Paul
Dietz found. The resolution for Juanjo is probably one of either
"ignore the requirement" or else to provide a specialized array on
(UNSIGNED-BYTE 7).
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Barry Margolin <··············@level3.com> writes:
> In article <···························@posting.google.com>,
> Juanjo <····@arrakis.es> wrote:
>>1) Given how upgrading of array elements is described in the ANSI
>>spec, it is impossible for an implementation to support specialized
>>arrays whose elements are (UNSIGNED-BYTE 8) if it also wants to
>>provide specialized arrays with elements of type (SIGNED-BYTE 8). Am I
>>correct?
>
> I don't think so. Which part of the description do you think prohibits it?
> Neither of those types is a subtype of the other, but even if they were I
> don't think there's anything prohibiting specialized arrays for subtypes.
This is probably the hideously amusing "specialized array element
types must form a lattice under type intersection" requirement that
Paul Dietz found. The resolution for Juanjo is probably one of either
"ignore the requirement" or else to provide a specialized array on
(UNSIGNED-BYTE 7).
Cheers,
Christophe
[superseded to fix (I hope) the terminology]
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> [superseded to fix (I hope) the terminology]
A 'lower semilattice', actually (a lattice has both
a meet and a join operator, but there is no requirement
that the union of two specialized array element types
is also a specialized array element type.)
Paul
In article <··············@lambda.jcn.srcf.net>,
Christophe Rhodes <·····@cam.ac.uk> wrote:
>Barry Margolin <··············@level3.com> writes:
>
>> In article <···························@posting.google.com>,
>> Juanjo <····@arrakis.es> wrote:
>>>1) Given how upgrading of array elements is described in the ANSI
>>>spec, it is impossible for an implementation to support specialized
>>>arrays whose elements are (UNSIGNED-BYTE 8) if it also wants to
>>>provide specialized arrays with elements of type (SIGNED-BYTE 8). Am I
>>>correct?
>>
>> I don't think so. Which part of the description do you think prohibits it?
>> Neither of those types is a subtype of the other, but even if they were I
>> don't think there's anything prohibiting specialized arrays for subtypes.
>
>This is probably the hideously amusing "specialized array element
>types must form a lattice under type intersection" requirement that
>Paul Dietz found. The resolution for Juanjo is probably one of either
>"ignore the requirement" or else to provide a specialized array on
>(UNSIGNED-BYTE 7).
OK, I remembered a recent message about a problem with upgraded array
element types, but didn't remember who wrote it. I just read Paul's
message and he's apparently right.
I think the problem is that we didn't take into account that compound types
are not likely to have specialized array types, because the implementation
can't generally find a single representation type to cover it. The rule
about (subtypep A B) => (subtypep (UAET A) (UAET B)) probably should make
an exception when the upgraded type is T.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, 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.
Barry Margolin wrote:
> I think the problem is that we didn't take into account that compound types
> are not likely to have specialized array types, because the implementation
> can't generally find a single representation type to cover it. The rule
> about (subtypep A B) => (subtypep (UAET A) (UAET B)) probably should make
> an exception when the upgraded type is T.
Note, however, that some types that this is affecting in real implementations
are integer subrange types on which SUBTYPEP must succeed. For example, SBCL
needs to add unsigned-byte 7, 15, and 31. There are plenty of cases where A
is a subtype of B, neither (UAET A) nor (UAET B) are T, but (UAET A) is not
a subtype of (UAET B).
There's also the small matter than the definition of UAET talks about subtype,
not SUBTYPEP, and subtype is defined in the glossary by the usual mathematical
definition of subset. It's apparently supposed to work on arbitrary types, including
those built with SATISFIES.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> There's also the small matter than the definition of UAET talks
> about subtype, not SUBTYPEP, and subtype is defined in the glossary
> by the usual mathematical definition of subset. It's apparently
> supposed to work on arbitrary types, including those built with
> SATISFIES.
I was having a good day until you said that.
It's now 9:30 am. Thanks.
Christophe
"well, we'll ignore that one for now"
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
In article <······················@dls.net>,
Paul F. Dietz <·····@dls.net> wrote:
>There's also the small matter than the definition of UAET talks about subtype,
>not SUBTYPEP, and subtype is defined in the glossary by the usual mathematical
>definition of subset. It's apparently supposed to work on arbitrary
>types, including
>those built with SATISFIES.
While it may say that, I don't see how anyone could reasonably expect it to
be taken literally. If SUBTYPEP can't determine the relationship, how
could MAKE-ARRAY do better? They're both part of the same implementation,
and either it knows or it doesn't. MAKE-ARRAY doesn't have access to a
magic "type oracle" that SUBTYPEP doesn't know about.
--
Barry Margolin, ··············@level3.com
Genuity Managed Services, a Level(3) Company, 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.
Barry Margolin wrote:
> While it may say that, I don't see how anyone could reasonably expect it to
> be taken literally.
Of course. Taken at face value, it implies U-A-E-T is undecidable. :)
Paul