Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: Return type of procedures?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Max Skaller <skaller@m...>
Subject: Re: Return type of procedures?
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