From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA05117; Wed, 23 Jun 2004 22:21:43 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA02781 for ; Wed, 23 Jun 2004 22:21:42 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i5NKLdEV032448 for ; Wed, 23 Jun 2004 22:21:40 +0200 Received: from [192.168.1.200] (ppp215-31.lns1.syd2.internode.on.net [203.122.215.31]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i5NKLa4Y008177; Thu, 24 Jun 2004 05:51:37 +0930 (CST) Subject: Re: [Caml-list] Why must types be always defined at the top level? From: skaller Reply-To: skaller@users.sourceforge.net To: Andreas Rossberg Cc: caml-list In-Reply-To: <40D9AFAF.3040405@ps.uni-sb.de> References: <20040622224125.GA24785@redhat.com> <20040622225321.GB31368@fichte.ai.univie.ac.at> <1087947151.29427.82.camel@pelican.wigram> <40D97122.8000909@ps.uni-sb.de> <1088001930.1941.31.camel@pelican.wigram> <40D9AFAF.3040405@ps.uni-sb.de> Content-Type: text/plain Message-Id: <1088022094.1941.84.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 24 Jun 2004 06:21:36 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 40D9E653.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 rossberg:01 endmatch:01 'type:99 intermodule:01 intermodule:01 recursion:01 recursion:01 nesting:01 namespaces:01 namespaces:01 typedefs:01 refute:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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