Swaroop Sridhar wrote:
>> Is there a reason not to have > aloc[3]?
>>
>
> The problem here is that when we see the expression aloc[3], we don't
> have enough syntactic information to determine if the type of aloc is
> an array (having at least 4 elements) or a vector.
>
> We can support this syntax of aloc's type has already resolved to some
> array/vector type. This is similar to the st.f field selection syntax
> for structures.
>
> It is possible to infer types that are variable over array/vector types
> (same for structures), at the cost of complicating the inferred types.
>
> It is definitely possible to support this syntax using different
> syntactic constructs for example: aloc[3] for array subscript and
> vec{3} for vector subscript.
>
The latter is very akin to OCaml's approach. Well, since I'm
overloading, what about using type-classes? Something like:
(deftypeclass (Indexable 'a 'b)
(tyfn 'a 'c)
[] : (fn ('a int) 'c)
)
(definstance (Indexable array 'b)
[] = array-nth
)
(definstance (Indexable vector 'b)
[] = vector-nth
)
Well, you get the gist. If type-classes like these have no runtime
overhead, it might be worth pursuing.
PKE
--
Pål-Kristian Engstad ([EMAIL PROTECTED]),
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
"It is better to have 100 functions operate on one data structure
than 10 functions on 10 data structures." -- NN
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
