Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Andreas Rossberg <rossberg@ps.uni-sb.de>
Cc: caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Why must types be always defined at the top level?
Date: 24 Jun 2004 06:21:36 +1000	[thread overview]
Message-ID: <1088022094.1941.84.camel@pelican.wigram> (raw)
In-Reply-To: <40D9AFAF.3040405@ps.uni-sb.de>

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


  reply	other threads:[~2004-06-23 20:21 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-22 22:41 Richard Jones
2004-06-22 22:53 ` Markus Mottl
2004-06-22 23:32   ` skaller
2004-06-23 12:01     ` Andreas Rossberg
2004-06-23 14:45       ` skaller
2004-06-23 16:28         ` Andreas Rossberg
2004-06-23 20:21           ` skaller [this message]
2004-06-23 20:52             ` skaller
2004-06-24 14:27               ` John Hughes
2004-06-24 16:47                 ` Andreas Rossberg
2004-06-24 17:30                   ` Markus Mottl
2004-06-24 17:45                 ` Xavier Leroy
2004-06-24 19:46                   ` John Hughes
2004-06-24 19:56                     ` David Brown
2004-06-24 19:57                     ` William D. Neumann
2004-06-24 20:13                       ` Olivier Andrieu
2004-06-24 23:26                     ` Brian Hurt
2004-06-25 10:20                     ` skaller
2004-06-25 11:07                       ` Basile Starynkevitch [local]
2004-06-25 12:30                         ` skaller
2004-06-25 14:38                           ` [Caml-list] Thread and kernel 2.6 pb still there in CVS Christophe Raffalli
2004-06-25 16:08                             ` [Caml-list] " Marco Maggesi
2004-06-25 16:32                               ` Markus Mottl
2004-06-28 15:08                             ` [Caml-list] " Xavier Leroy
2004-06-28 18:50                               ` Benjamin Geer
2004-06-29  2:26                               ` Christophe Raffalli
     [not found]                                 ` <7AFB5F64-C944-11D8-975C-00039310CAE8@inria.fr>
     [not found]                                   ` <40E11621.3050709@univ-savoie.fr>
2004-07-05 15:14                                     ` Christophe Raffalli
2004-07-05 16:34                                       ` Xavier Leroy
2004-07-06  9:33                                         ` Alex Baretta
2004-07-08 13:51                                           ` Christophe Raffalli
2004-07-08 15:03                                             ` Xavier Leroy
2004-07-09 23:21                               ` Donald Wakefield
2004-07-10 10:56                                 ` Damien Doligez
2004-06-24 23:23                   ` [Caml-list] Why must types be always defined at the top level? Brian Hurt
     [not found]                     ` <Pine.LNX.4.44.0406241813370.4202-100000@localhost.localdom ain>
2004-06-26 23:08                       ` Dave Berry
2004-06-25  1:59                   ` Yaron Minsky
2004-06-24 23:08                 ` Brian Hurt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1088022094.1941.84.camel@pelican.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@inria.fr \
    --cc=rossberg@ps.uni-sb.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox