From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 0A180BC0A for ; Mon, 18 Dec 2006 02:52:02 +0100 (CET) Received: from mailx.valdosta.edu (mailx.valdosta.edu [168.18.130.251]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id kBI1q0hu027719 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 18 Dec 2006 02:52:01 +0100 Received: from blazemail.valdosta.edu (blazemail.valdosta.edu [168.18.130.208]) by mailx.valdosta.edu (8.13.8/8.13.8) with ESMTP id kBI1pvkP009574 for ; Sun, 17 Dec 2006 20:51:57 -0500 (EST) (envelope-from jtbryant@valdosta.edu) Received: from luminis (luminis [168.18.130.219]) by blazemail.valdosta.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with SMTP id <0JAG008PK56JXL@blazemail.valdosta.edu> for caml-list@yquem.inria.fr; Sun, 17 Dec 2006 20:51:55 -0500 (EST) Date: Sun, 17 Dec 2006 20:51:55 -0500 (EST) From: Jonathan T Bryant Subject: A Few Questions To: caml-list@yquem.inria.fr Message-id: <6471679.1166406715475.JavaMail.jtbryant@valdosta.edu> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.1.279297, Antispam-Engine: 2.4.0.264935, Antispam-Data: 2006.12.17.172933 X-Miltered: at discorde with ID 4585F440.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 ocaml:01 semantics:01 camlp:01 functor:01 semantically:01 syntax:01 sig:01 functor:01 sig:01 struct:01 struct:01 russo's:01 inference:01 val:01 I've been reasearching into a parallel extension to OCaml (based on Reppy's CML and the OCaml Event module). Mostly it's extending the semantics of channels and using CamlP4 to add syntactic constructs for concurrency, but there are a few extensions I'm having trouble with because of OCaml language "problems", and so I have a few questions. 1) Why can't a functorized module be used as a functor to another module? I don't know if this is semantically not possible or if I am just doing it wrong. I've played around with the syntax and reread the manuals, but I can't seem to find a solution. For example: module type AModule = sig type t end module type BModule = functor (A : AModule) -> sig type t type s = A.t end module S : sig type t end module Make = functor (B : BModule) -> S with type t = B.t (* This is what fails *) module AImpl = struct type t = int end module BImpl = functor (A : AModule) -> struct type t = int type s = A.t end module X = Make (BImpl (AImpl)) 2) Why, in general, are there not first class modules? I've looked at Russo's paper on this and it shouldn't conflict with static typing or type inference. Again, for example, why isn't this allowed: val make : ('a -> 'b) -> ('a -> 'c) -> sig type t val x : 'a -> 'b val y : 'a -> 'c end let make a b = struct type t = int let x = a let y = b end module X = make (fun x -> x) (fun y -> y) It doesn't seem like it would be very different from the already allowed immediate objects and local module bindings. 3) Since CML's threads are implemented via continuations, speculative computation is allowed because threads are simply GCed once they are not referenced any more. Since OCaml's threads are implemeted via system calls, is this still the case or do threads need to be manually joined? I've run into some instances where I can't create any more threads because the "Thread limit" of 1024 has been reached, but in code where nowhere near that many threads should be left active. Is this limit an OCaml limit or a system limit? Does it make a difference whether using native code and system threads vs. bytecode and vmthreads? Also, what about threads that are not referenced anymore but should still be running (i.e., "background services" and the like)? Is there any way to keep the GC from collecting them? 4) I've found that in sending functions across sockets, I can only send them between copies of the exact same binary image. Is it possible to marshal functions to different binaries of the same code, i.e., different platforms? Again, does native vs. bytecode make a difference? 5) One possible extension is a vector type. Is it possible as is to make the type inference engine "as is" include the size of the underlying array as part of the type information or does that require modifications to the type system? Adding to the type information allows runtime size checks to be avoided and allows code generation to take advantage of external vector processors and/or GPUs. The ideal setup is vectors that are unboxed arrays of fixed length, similar to tuples. Thanks, --Jonathan Bryant