From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: weis
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA17263 for caml-redistribution; Wed, 19 Jan 2000 21:57:56 +0100 (MET)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA16611 for <weis@pauillac.inria.fr>; Wed, 19 Jan 2000 18:34:03 +0100 (MET)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id SAA16840
	for <Pierre.Weis@inria.fr>; Wed, 19 Jan 2000 18:34:01 +0100 (MET)
Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Jan 2000 09:33:54 -0800 (Pacific Standard Time)
Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21)
	id <DA7J6R7Q>; Wed, 19 Jan 2000 09:33:53 -0800
Message-ID: <7CD674FF54FBD21181D800805F57CD54821B89@RED-MSG-44>
From: Simon Peyton-Jones <simonpj@microsoft.com>
To: "'Pierre Weis'" <Pierre.Weis@inria.fr>, dmcclain@azstarnet.com
Cc: caml-list@inria.fr
Subject: RE: Compiler translation of array indexing
Date: Wed, 19 Jan 2000 09:33:27 -0800
X-Mailer: Internet Mail Service (5.5.2650.21)
Sender: weis

| > Instead of translating as in OCAML to Array.get and
| > Array.set, they could be translated into some equivalent to
| > 
| > x.(n)  ->  module_of(type_of x).get(x, n)
| 
| There are strong theoretical difficulties to obtain a type_of function
| embedded into a statically & strongly type checked language such as
| Caml. 

It's perhaps worth mentioning that one way of achieving
this effect is to use type-driven overloading, as Haskell
does.  One could say

	class Array a where
	  (.) :: a elt -> Int -> elt
	  ... more operations...

(Here 'a' is a type variable ranging over type constructors
of kind *->*.)

Now for each type (constructor) T that you want to make an
instance of Array, you would say

	instance Array T where
	  (.) = ...your implemention of indexing for T...


Such type classes are, however, fully implemented in Haskell.  
However, type classes (not to be confused with object oriented
classes as in OCaml) form quite a large design space, and its
interaction with OCaml classes and modules are quite unknown (to me
anyway).  


There's a paper about the type-class design space at
	http://research.microsoft.com/~simonpj/papers/multi.ps.gz

Simon