Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] Why must types be always defined at the top level?
[ 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] Why must types be always defined at the top level?
On Thu, 2004-06-24 at 02:28, Andreas Rossberg wrote:

> However, a stamp based semantics is a purely operational approach and 
> has no proper explanation in type theory. 

What has scoping got to do with it though?

In Felix there is a quirk where you can do this:

fun f():(1->t) * (t->0) = {
  type t = "int"; 
  fun a():t={ return 1; }
  fun b(x:t):0={ print_int x; }
}

The client of this function doesn't know the name 't',
and doesn't need to:

match f() with
| (?a, ?b) => { b(a()); }
endmatch;

There isn't anything in the binding algorithm
that would make this fail, and values of the
type can still be used.

Of course if a *value* nested in the function
escaped it would be a disaster. But a type is
always static, so you can just treat the function
scope as a module scope when it comes to types
I would have thought.

AFAICS 'type theory' is just another name for
basic category theory anyhow :)

> > Oh? Ocaml does not support forward calls of named functions
> > across compilation unit boundaries.
> 
> Granted, but then it said "intermodule fun calls", not "intermodule fun 
> recursion" in your table.

The issue isn't recursion per se: it's being able to call a function
defined in an arbitrary compilation unit. I should have said
inter-unit calls though.

> It is not just nesting functions. Consider local namespaces, template 
> namespaces, template typedefs, to name just a few illegal combinations. 

Yes, you're right.

> > Please note the table was not intended to be taken
> > seriously on a technical front.
> 
> That's understood. Still had to refute some of its more biased content. ;-)

There is a serious point there though. Ocaml is still quite quirky
in the same way as C++ is. I've run into quite a few annoyances,
like no local exceptions, cant mix recursive classes and types,
etc .. all have workarounds, but some are extremely ugly,
especially forward calling via reference hack. I just wouldn't
have expected that kind of problem in an FPL.

-- 
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