From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA11896 for caml-red; Tue, 22 Aug 2000 10:32:40 +0200 (MET DST)
Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA07516 for <caml-list@pauillac.inria.fr>; Tue, 22 Aug 2000 03:16:25 +0200 (MET DST)
Received: from localhost.localdomain (brian-boitano230.zip.com.au [210.23.147.230])
	by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e7M1GLf25454
	for <caml-list@inria.fr>; Tue, 22 Aug 2000 03:16:21 +0200 (MET DST)
Received: from maxtal.com.au (IDENT:root@localhost [127.0.0.1])
	by localhost.localdomain (8.9.3/8.8.7) with ESMTP id LAA07156;
	Tue, 22 Aug 2000 11:17:08 +1000
Message-ID: <39A1D494.EA23B59A@maxtal.com.au>
Date: Tue, 22 Aug 2000 11:17:08 +1000
From: John Max Skaller <skaller@maxtal.com.au>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Manuel Fahndrich <maf@microsoft.com>, caml-list@inria.fr
Subject: Re: Return type of procedures?
References: <2CCC2A4C8D41EC4991B547B3595F1A7251A326@red-pt-01.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: weis@pauillac.inria.fr

Manuel Fahndrich wrote:
> 
> We are having a related problem with unit and void in a language we design
> at MSR called Vault. The problem we ran into was with polymorphism. If you
> have a polymorphic function in your language (such as the identity id : 'a
> -> 'a), you could still end up in the situation you are trying to avoid,
> namely by saying:
> 
>         id (p ()),
> 
> where p : unit -> void
> 
> In this example, one could check the instance type, but in general, one can
> hide these instances inside other polymorphic functions and procedures and
> that approach is impractical.

My language supports polymorhpism, but only at the  module level:
if you want parametric polymorphism, you must put the function
in a module, currently the slightly hacked:

	module ident[<T>] { id: T-> T; }

This means that when the function is used, the module must
be instantiated:

	x = ident[<void>].id (y);

and the error is detected at instantiation time.
The instantiation is not done yet, because it is currently
a 'hack' in that it takes a listr of C++ style types as
arguments, instead of a module: this is because I haven't
defined any concept of 'interface=signature' yet.
Partly, that is because I'm unhappy with the fact that
functions are called with 'positional' arguments,
whereas modules would be called with 'named' arguments:

	functor ident[<type T;>] { id: T-> T; }
	x = ident[<T=void>].id(y);

Here, the contents of the [<>] brackets are a 'module expression',
which could be an anonymous module (as shown) or a named one
(not shown), and I have yet to figure out the syntax to use
so these are handled regularly. I note that functor application 
should be transparent, given:

	module Int { type t = int; }

we should be able to write

	(ident Int) . id y

as for any 'other' function application (where . binds
tighter than application).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net