Pierre Weis wrote:
>
> To summerize, I really would like to write
> v.(1) instead of Array.get v 1
> s.(1) instead of String.get s 1
>
> I would consider as an additional benefit of the new type system, if I
> could use:
> t.("ok") instead of Hashtbl.find t "ok",
> l.("ok") instead of List.assoc "ok" l.
Recent work by Mark Jones tries to make this work in Haskell/Hugs by
extending multi parameter type classes with dependency annotations:
http://www.cse.ogi.edu/~mpj/fds.html
Using dependency annotations, one can declare a class like (in some
mixed Haskell/Caml pseudo syntax):
class Index 'c 'i 'e | 'c -> 'i 'e where
.() : 'c -> 'i -> 'e
(note that all parameters have kind *) and instances
instance Index ('a array) int 'a
instance Index string int char
instance Index (('a,'b) Hashtbl.t) 'a 'b
instance Index (('a*'b) list) 'a 'b
These should provide the desired type-driven behaviour for indexing. The
dependency annotation ('c -> 'i 'e) in the class ensures that index and
element type are determined by the collection type. For example, the
compiler could infer the following:
[|1;2;3|].(0) : int
"hello".(3) : char
[(2,39);(4,0)].(2) : int
fun i -> "hello".(i) : int -> char
Note however, that overloading can quickly become ambiguous, even with
dependencies. While
let f x = x.(0)
would be possible and have qualified type like
(Index 'c int 'e) => 'c -> 'e,
the only slightly more involved
let g x = x.(0).(0)
would not be allowed without additional type annotations since
(Index 'c1 int 'c2, Index 'c2 int 'e) => 'c1 -> 'e
is an ambiguous type.
Best regards,
- Andreas
This archive was generated by hypermail 2b29 : Tue Jan 25 2000 - 09:45:49 MET