From: Jonathan T Bryant <jtbryant@valdosta.edu>
To: caml-list@yquem.inria.fr
Subject: A Few Questions
Date: Sun, 17 Dec 2006 20:51:55 -0500 (EST) [thread overview]
Message-ID: <6471679.1166406715475.JavaMail.jtbryant@valdosta.edu> (raw)
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
next reply other threads:[~2006-12-18 1:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-18 1:51 Jonathan T Bryant [this message]
2006-12-18 3:18 ` [Caml-list] " skaller
2006-12-19 22:31 ` Nathaniel Gray
2006-12-19 6:15 oleg
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=6471679.1166406715475.JavaMail.jtbryant@valdosta.edu \
--to=jtbryant@valdosta.edu \
--cc=caml-list@yquem.inria.fr \
/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