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 VAA04246 for caml-redistribution; Wed, 19 Jan 2000 21:57:24 +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 SAA25080 for ; Wed, 19 Jan 2000 18:08:53 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id SAA16032; Wed, 19 Jan 2000 18:08:52 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id SAA15007; Wed, 19 Jan 2000 18:08:31 +0100 (MET) From: Markus Mottl Message-Id: <200001191708.SAA15007@miss.wu-wien.ac.at> Subject: Re: Compiler translation of array indexing To: Pierre.Weis@inria.fr (Pierre Weis) Date: Wed, 19 Jan 2000 18:08:31 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <200001191425.PAA15370@pauillac.inria.fr> from "Pierre Weis" at Jan 19, 2000 03:42:06 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis > This work had also produced a safe value I/O system for Objective > Caml, that is a fully typechecked and safe polymorphic input/output > set of primitives for Objective Caml. > The design and implementation is described into the following > (forcoming) article : http://pauillac.inria.fr/~weis/articles/jfla2000.ps.Z Wow! This is really interesting stuff! I don't know much French, but if I get the main ideas of the article, the techniques presented in it give quite some new perspectives to programming in statically typed languages in general and in OCaml specifically. So far, one of the valid arguments of people using dynamically typed languages is that I/O in statically typed languages is very inflexible. The implementation of the ideas presented in this article would, however, provide a strong counter argument: then we would not only have flexible, but also *safe* I/O! Since it is very time consuming for me to read the French version, I'd like to ask a short question here: The article says that the name of types and constructors is dropped for the conversion to the interchange format. But what about types like: type t = Foo | Bar How are such cases treated? Another program might define this as type t = Bar | Foo and possibly means the same thing with the same constructors, however, the internal representation might be completely different (maybe due to order of constructors). Of course, as long as all constructors take parameters of different types like in type t = String of string | Int of int | ... there is always a unique translation. Are there primitives for disambiguating such cases? E.g. my program reads in data from another program, I see that it gets the constructors the wrong way round so I just use some primitive to get it right again? > We also plan to distribute Jun's implementation in the near future, to > let you play with it. This would be great! I am looking forward to this! Best regards, Markus Mottl -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl