Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Polymorphism and the "for" loop
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Polymorphism and the "for" loop
On Fri, 2004-10-22 at 17:38, Jon Harrop wrote:

>  Surely a "procedure" 
> returns no information, which can be achieved by returning the only value 
> from a type representing a singleton set, i.e. _the_ value of the type unit.

Clearly is can, since that what Ocaml does. But as I pointed
out it fails to prevent certain abuses. 

> >  type void = []
> 
> Why not "`void"?

Because `void is a value so if you write:

type void = [`void]

all you've done is define a non-canonical unit,
which is categorically *not* a void :)

> I've been wondering about this recently: how do the compilers store types 
> which contain "unit". 

If the compiler is smart it just optimises it away.
Felix usually optimises it away. In Ocaml, it can't
always be optimised away:

> For example, if we have a tree:
> 
> type 'a 'b tree = Leaf of 'a | Node of 'b * 'a 'b tree * 'a 'b tree
> 
> Does a "unit unit tree" take up less space than a "int int tree"?

No, this isn't possible usually, because any polymorphic
algorithm using this data structure expects a fixed
layout in memory.

So in this case, a dummy value must exist.

This problem can't arise in Felix or C++, because
they both use extensional polymorphism
(compile time instantiation).

The only way this might work in Ocaml is if 
the pointer to value was replaced by NULL,
but that would require a NULL check, and slow
down the algorithm for all types just to save
some memory in degenerate cases.

> The reason I'm asking is that it might be nice to generalise data structures 
> as much as possible and then specialise them using "unit" arguments.

If you use a functor, the compiler might be able to 
optimise it away.

I think you can assume most uses like this:

let f () = ...

	f () 

actually don't pass the () around: that's such an obvious
thing to optimise. Still, there must be a version
of f that isn't optimised, otherwise you couldn't
pass it to a higher order function.


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners