Re: Compiler translation of array indexing

[Andreas Rossberg <rossberg@ps.uni-sb.de>]

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