Version française
Home     About     Download     Resources     Contact us    
Browse thread
Re: Compiler translation of array indexing
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <mottl@m...>
Subject: Re: Compiler translation of array indexing
> 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