| Author |
Message |
|
Ashley Yakel
#1 / 10
|
 Collection Element Type? The DRM (< http://www.*-*-*.com/ #HEADIN...>): An object X is an instance of a limited collection type
limited(C, of: T2, size: S) if and only if all of the
following are true:
...
The element type of X is equivalent to T2.
How does Dylan determine the element type of some general instance X of
<collection>? My best guess is that it looks at the method defined on
'element' specialised for object-class(X), or something.
--
Ashley Yakeley, Seattle WA
|
| Sat, 26 May 2001 03:00:00 GMT |
|
 |
|
Ashley Yakele
#2 / 10
|
Collection Element Type?
Quote: >>I was hoping for something like: >>x = make(<mumble>, of: T);
>>of(x) == T;
>>Did you ever consider something along these lines?
>It was part of the proposal for user-defined limited collection
>types. That whole half of the proposal was dropped. It was late
>in the game, and we didn't want to rush in any more features than
>we had to at that point.
OK. But Dylan always knows the element type of any given collection object, even though there isn't an 'of' function, right? --
Ashley Yakeley, Seattle WA
|
| Sun, 27 May 2001 03:00:00 GMT |
|
|
|
Andrew Shali
#3 / 10
|
Collection Element Type?
Quote:
>>You say make(limited(<mumble>, of: T)), where <mumble> is
>><table>, <object-table>, <array>, <vector>, <simple-vector>,
>><stretchy-vector>, <string>, or <range>. In other words,
>>you instantiate an instantiable limited collection.
>>This answer is so simple, it makes me think I must have missed
>>something in your question.
>I had incorrectly assumed that make() could only be called on classes.
No, you can have instantiable types. Quote: >So will >object-class(make(limited(<mumble>, of: T))) ==
>object-class(make(<mumble>))
The direct class of a limited collection object is not defined. I believe it is defined that the class will be the same class or a subclass of the class that was passed to limited. This is definitely in the DRM, though I don't have time to dig up chapter and verse right now. Quote: >...always be true? >I was hoping for something like:
>x = make(<mumble>, of: T);
>of(x) == T;
>Did you ever consider something along these lines?
It was part of the proposal for user-defined limited collection types. That whole half of the proposal was dropped. It was late in the game, and we didn't want to rush in any more features than we had to at that point.
|
| Sun, 27 May 2001 03:00:00 GMT |
|
|
|
Ashley Yakele
#4 / 10
|
Collection Element Type?
Quote: >You say make(limited(<mumble>, of: T)), where <mumble> is ><table>, <object-table>, <array>, <vector>, <simple-vector>, ><stretchy-vector>, <string>, or <range>. In other words, >you instantiate an instantiable limited collection. >This answer is so simple, it makes me think I must have missed
>something in your question.
I had incorrectly assumed that make() could only be called on classes. So will
object-class(make(limited(<mumble>, of: T))) ==
object-class(make(<mumble>))
...always be true?
I was hoping for something like:
x = make(<mumble>, of: T);
of(x) == T;
Did you ever consider something along these lines?
--
Ashley Yakeley, Seattle WA
|
| Sun, 27 May 2001 03:00:00 GMT |
|
|
|
Andrew Shali
#5 / 10
|
Collection Element Type?
Quote:
>>>I was hoping for something like:
>>>x = make(<mumble>, of: T);
>>>of(x) == T;
>>>Did you ever consider something along these lines?
>>It was part of the proposal for user-defined limited collection
>>types. That whole half of the proposal was dropped. It was late
>>in the game, and we didn't want to rush in any more features than
>>we had to at that point.
>OK. But Dylan always knows the element type of any given collection
>object, even though there isn't an 'of' function, right?
In theory this information could be compiled away. The ability to perform an introspective operation at runtime is not part of the specification. Whether any implementation would actually be able to be aggressive enough to compile this away, I can't say.
|
| Mon, 28 May 2001 03:00:00 GMT |
|
|
|
Ashley Yakele
#6 / 10
|
Collection Element Type?
Quote: >>OK. But Dylan always knows the element type of any given collection >>object, even though there isn't an 'of' function, right? >In theory this information could be compiled away.
For particular programs, of course, but not in general. Given a general instance of <collection> x, and a type T, Dylan must know how to calculate instance?(x,limited(<collection>, of: T))
..so it must know whether the element type of x is equivalent to T.
I'm surprised there isn't a built-in element-type function:
define function element-type (c :: <collection>) => t :: <type>
For my formalisation efforts, I'm going include the functionality of such
an 'element-type' as a primitive for my algorithms.
--
Ashley Yakeley, Seattle WA
|
| Mon, 28 May 2001 03:00:00 GMT |
|
|
|
P T Withingto
#7 / 10
|
Collection Element Type?
Quote:
>>>>>OK. But Dylan always knows the element type of any given collection
>>>>>object, even though there isn't an 'of' function, right?
>>>>In theory this information could be compiled away.
>>>For particular programs, of course, but not in general. Given a general
>>>instance of <collection> x, and a type T, Dylan must know how to calculate
>>>instance?(x,limited(<collection>, of: T))
>>>..so it must know whether the element type of x is equivalent to T.
>>Hm. Now that I read that, it sure sounds like it to me, but I think we
>>are missing something here, because it was always explained to me that
>>instance of limited types could always be computed directly from the type
>>heirarchy. That is, #[1, 2, 3, 4, 5] is not an instance of
>>limited(<vector>, of: <integer>), but as(limited(<vector>, of:
>><integer>), #[1, 2, 3, 4, 5]) is.
>Presumably you don't want your instancep test to have to look at every
>element of the vector to verify that it is an integer.
Agree, but if you read only the paragraph at the top of p. 127 in the DRM, you are left with the impression that is what you have to do. (Which is why I suspect I am missing something.) ________________________________________________________________
Callitrope/The Art of Computing <http://www.callitrope.com>
post:Callitrope/168 Old Sandwich Road/Plymouth/MA/02360-2507/USA
|
| Tue, 29 May 2001 03:00:00 GMT |
|
|
|
P T Withingto
#8 / 10
|
Collection Element Type?
Quote:
>>>OK. But Dylan always knows the element type of any given collection
>>>object, even though there isn't an 'of' function, right?
>>In theory this information could be compiled away.
>For particular programs, of course, but not in general. Given a general
>instance of <collection> x, and a type T, Dylan must know how to calculate
>instance?(x,limited(<collection>, of: T))
>..so it must know whether the element type of x is equivalent to T.
Hm. Now that I read that, it sure sounds like it to me, but I think we are missing something here, because it was always explained to me that instance of limited types could always be computed directly from the type heirarchy. That is, #[1, 2, 3, 4, 5] is not an instance of limited(<vector>, of: <integer>), but as(limited(<vector>, of: <integer>), #[1, 2, 3, 4, 5]) is. ________________________________________________________________
Callitrope/The Art of Computing <http://www.callitrope.com>
post:Callitrope/168 Old Sandwich Road/Plymouth/MA/02360-2507/USA
|
| Tue, 29 May 2001 03:00:00 GMT |
|
|
|
Mark Nahabedia
#9 / 10
|
Collection Element Type?
Quote:
>>>>OK. But Dylan always knows the element type of any given collection
>>>>object, even though there isn't an 'of' function, right?
>>>In theory this information could be compiled away.
>>For particular programs, of course, but not in general. Given a general
>>instance of <collection> x, and a type T, Dylan must know how to calculate
>>instance?(x,limited(<collection>, of: T))
>>..so it must know whether the element type of x is equivalent to T.
>Hm. Now that I read that, it sure sounds like it to me, but I think we
>are missing something here, because it was always explained to me that
>instance of limited types could always be computed directly from the type
>heirarchy. That is, #[1, 2, 3, 4, 5] is not an instance of
>limited(<vector>, of: <integer>), but as(limited(<vector>, of:
><integer>), #[1, 2, 3, 4, 5]) is.
Presumably you don't want your instancep test to have to look at every element of the vector to verify that it is an integer.
|
| Tue, 29 May 2001 03:00:00 GMT |
|
|
|
Andrew Shali
#10 / 10
|
Collection Element Type?
Quote:
>>>>>>OK. But Dylan always knows the element type of any given collection
>>>>>>object, even though there isn't an 'of' function, right?
>>>>>In theory this information could be compiled away.
>>>>For particular programs, of course, but not in general. Given a general
>>>>instance of <collection> x, and a type T, Dylan must know how to calculate
>>>>instance?(x,limited(<collection>, of: T))
>>>>..so it must know whether the element type of x is equivalent to T.
>>>Hm. Now that I read that, it sure sounds like it to me, but I think we
>>>are missing something here, because it was always explained to me that
>>>instance of limited types could always be computed directly from the type
>>>heirarchy. That is, #[1, 2, 3, 4, 5] is not an instance of
>>>limited(<vector>, of: <integer>), but as(limited(<vector>, of:
>>><integer>), #[1, 2, 3, 4, 5]) is.
>>Presumably you don't want your instancep test to have to look at every
>>element of the vector to verify that it is an integer.
>Agree, but if you read only the paragraph at the top of p. 127 in the
>DRM, you are left with the impression that is what you have to do.
>(Which is why I suspect I am missing something.)
I don't have time to find the chapter and verse to quote, but I'm pretty certain the DRM is explicit about this. Just because a collection happens to contain only integers, that doesn't make it a limited collection. The limited-type membership test has nothing to do with looking at the contents of the collection.
|
| Tue, 29 May 2001 03:00:00 GMT |
|
| |
|
