Re: [Caml-list] optional functions in modules
Core's approach to this is to use options. (Technically, we use a type called Or_error.t, which has a useful error message in the error-variant, but it's the same idea.) On Thu, May 10, 2012 at 2:44 PM, Goswin von Brederlow goswin-...@web.de wrote: Yitzhak Mandelbaum yitzh...@cs.princeton.edu writes: Hi, Is there any common wisdom regarding the inclusion of optional functions in a module signature? The two most obvious approaches involve 1) a pair of boolean flag and a function, where the function raises an exception if unimplemented OR 2) using the option type. I see pros/cons to each approach, but am curious if there's any (unofficial) standard approach. Yitzhak - Yitzhak Mandelbaum The extunix module has a trifold solution for this: * First there is the ExtUnix.All module that has all functions in it. Functions that are not available raise Not_available with function name as an argument. * Second there is ExtUnix.All.have : string - bool option (** [have name] @return indication whether function [name] is available - [Some true] if available - [Some false] if not available - [None] if not known e.g. [have eventfd] *) * Third there is ExtUnix.Specific containing only functions available on this platform. MfG Goswin -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Non-blocking IO interface design
On Tue, Apr 10, 2012 at 4:21 AM, Daniel Bünzli daniel.buen...@erratique.ch wrote: Anil, Thanks for the analysis. The I/O loop is being called twice for the non-blocking version, as it receives the `Await signal, does the Unix syscall, and then jumps into decode_src. Presumably a full non-blocking version would have to register with a select handler if it gets an EAGAIN at this point, Yes. In terms of the number of system calls, the non-blocking one is more efficient, as it uses a 16KB buffer versus the 4K reads done by the blocking version. Yes, the 4K reads are a limitation of pervasives channels. For each mechanism I used the largest buffer that the OCaml runtime uses. Looking at the two decoders in src/se.ml, it looks like the non-blocking one allocates closures on every loop, which the blocking one doesn't. This is so it can store the continuation in d.k for the next loop. Yes, that's a side effect of writing in continuation passing style in general since continuations are often partially applied functions. I believe this particular performance issue is fixed in the upcoming 4.0 release, based on some work by OCamlPro. So to summarise, instead of storing a continuation closure, it would probably be better to explicitly store the state in d.k to minimise allocation? Maybe, but keep in mind that s-expressions are very simple to parse. It may be obvious in this case but depending on what you decode defining/storing the state may become complex. Cps is an easy and general way to solve the problem while keeping the whole thing reasonably readable. But do you maybe see another pattern that I don't ? The library looks very useful by the way: I have exactly the same issue with several Lwt-only protocol libraries we're developing at the moment. Would love to use yours before the first release of them to make them more independent of the underlying I/O mechanism... That would be nice, I'm glad if you can somehow reuse the pattern. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
Are you familiar with type-conv and the family of syntax-extensions that go
along with it? You can do thinks like:
type t = { foo: int; bar: string }
with sexp, compare, bin_io
and automatically get sexp-conversion functions, a comparison function, and
binary protocol converters. And type-conv has been used to build other
type-directed functions by other people outside of Jane Street.
The latest version is available on bitbucket, and we'll have a new blessed
release in a few days.
https://bitbucket.org/yminsky/ocaml-core/
Note that this is done purely syntactically, and yet gets you there.
y
On Wed, Mar 7, 2012 at 6:49 AM, Matej Košík
5764c029b688c1c0d24a2e97cd7...@gmail.com wrote:
Hi,
I would like to print out the response of a modified Ocaml's typechecker
to various inputs.
One way to do it would be to write a pretty-printer by hand.
Before I do that, I would like to apply deriving machinery:
http://code.google.com/p/deriving/wiki/Introduction
to this (chore) job.
In some cases I do not know what to do.
E.g., file types/types.mli contains the following definition:
and value_kind =
Val_reg
| Val_prim of Primitive.description
| Val_ivar of mutable_flag * string
| Val_self of
(Ident.t * type_expr) Meths.t ref *
(Ident.t * mutable_flag * virtual_flag * type_expr) Vars.t ref *
string * type_expr
| Val_anc of (string * Ident.t) list * string
| Val_unbound
If I add
deriving (Show)
at the end of the above definition, I get an error:
Error: Unbound module Meths.Show_t
That is expected but I am not sure what to do. That is, I am not sure
what is the official way to deriving-sify the Meth module which
defined in the following way:
module Meths = Map.Make(OrderedString)
without the need to modify files map.ml{i,}.
Is something like that possible?
Thank you very much in advance for any help.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Custom let bindings
We use monads quite a bit, and the lack of a monadic syntax has been a long-running issue for us at Jane Street. I'd love to see some kind of monadic syntax land. I've seen the proposal, and it seems highly plausible. Also, having a special operator (let!) has been proposed as part of this I believe, and that seems like a good idea too. y On Fri, Jan 20, 2012 at 7:39 AM, Mehdi Dogguy me...@dogguy.org wrote: Hi, I noticed that Alain Frisch tried to add custom let bindings (see r11894 and r11906) but it was reverted later on (see r11960) because no consensus was reached (among OCaml Core team, I guess). AFAIR, I don't remember seeing this on the caml-list. I'd personally vote for its inclusion as I can see some uses for it. As any syntaxic sugar, it is something we can live without but it could make things easier to read or to express. FTR, the proposal is to add the following: “let.e0 p = e1 in e2” will be expanded to “e0 e1 (fun p - e2)”. I'm not sure which part of the proposal was not agreed on (the syntaxic details let.e0 or the whole proposal). Any input from the core team would be appreciated. What do others think about it? Regards, -- Mehdi Dogguy -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/**wws/info/caml-listhttps://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/**ocaml_beginnershttp://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-**bugshttp://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Core (and associated libraries) on bitbucket!
For those who are interested in getting a look at a development version of the next release of the Core suite of OCaml libraries, Core is now hosted on bitbucket. http://bitbucket.org/yminsky/ocaml-core/wiki/Home We're still working on making installation smoother and easier, as well as solving portability problems. But please take a look. There's also a discussion list: http://groups.google.com/forum/#!forum/ocaml-core This represents a new and more open development model for us, and we hope that as a result we'll be able to better interact with and accept patches from the community, and that Core will become a base that many people can use for building OCaml applications. y -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Examples where let rec is undesirable
For what it's worth, my feeling is that even if there weren't technical reasons to require the rec'' marking for recursive functions, I would want it as a language feature. Recursive definitions are harder to understand than non recursive ones, and it's helpful to have the static guarantee that only definitions so marked will be allowed to refer to themselves. This makes it hard to mistakenly refer to yourself, which I think is a real source of error. y On Jan 2, 2012 5:38 PM, Diego Olivier Fernandez Pons dofp.oc...@gmail.com wrote: List, I was wondering if there was any reason not to make let rec the default / sole option, meaning cases where you clearly don't want a let rec instead of let (only in functions, not cyclic data). Diego Olivier -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
For just this reason, the hashtables in Core have been reimplemented to use an AVL tree in the buckets. That way, even when you have pathological collisions, you degrade gracefully to O(log n) per operation, instead of O(n), where n is the number of keys in the hashtable. y On Fri, Dec 30, 2011 at 11:44 AM, Gerd Stolpmann i...@gerd-stolpmann.dewrote: Hi, there was recently a security alert for web services that use hash tables to store web form parameters sent via POST (so that millions of such parameters can be sent in a single request). It is possible to keep the web service busy for hours with such a DoS (denial of service) attack. The type of attack boils down to a problem in most hash table implementations, namely that the hash functions are invertible, and it is possible for a malicious user to construct lots of keys that all map to the same bucket of the hash table, creating a mass collision. The text of the alert: http://www.nruns.com/_downloads/advisory28122011.pdf I'd like to discuss this issue, because it is not restricted to the processing of web requests, but may also occur for all other data coming from untrusted sources. The web is only the most exposed area where this issue exists. So how is Ocaml affected? The hash functions used in recent Ocaml releases are also insecure in the above mentioned sense (currently MurmurHash3, and even a simpler hash function in previous releases). A quick survey of the Internet revealed at least one site that tries to break it. Probably a good cryptographer could do it in minutes. A pure Hashtbl.add of the constructed keys does not yet lead to the performance degradation, but a Hashtbl.replace, and of course Hashtbl.find after the table is built up will. So it depends very much of the details of the programs whether they are affected or not. I've just checked that Ocamlnet uses only Hashtbl.add to collect POST parameters, so it is not directly vulnerable. But if the crafted request is actually served by a handler, the handler would get a degraded table, and could show in turn bad performance (again leading to DoS). What are possible fixes? 1) Avoid hash tables in contexts where security is relevant. The alternative is Set (actually a balanced binary tree), which does not show this problem. 2) Use cryptographically secure hash functions. 3) Use randomized hash tables. The trick here is that there is not a single hash function h anymore, but a family h(1)...h(n). When the hash table is created, one of the functions is picked randomly. This makes it impossible to craft an attack request, because you cannot predict the function. I don't think 1) is viable - hash tables are too wide spread, and are loved by programmers because of their good performance. 2) would be good in extremely critical contexts - although it is then again questionable, because it is likely to have worse performance than 1). So, the question is how to do 3). I see two problems here: a) how to define the family of hash functions. Is it e.g. sufficient to introduce an initialization vector for the Murmurhash algorithm, and fill it randomly? How to get a random number that is good enough? b) the Hashtbl in the standard library does not allow it to set the hash function dynamically. Maybe one can get this effect by using first-class modules (haven't checked). Anyway, I think these problems are difficult enough to deserve some discussion here. At least I cannot solve them immediately, and this problem may exist for lots of Ocaml applications. Gerd -- Gerd Stolpmann, Darmstadt, Germanyg...@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details:http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Hashtbl and security
It's not clever in that way. It does try to do a good job of keeping the memory impact of the tree low, but you maintain O(1) by having a low load factor, and therefore trees of constant size. You can take a look at the code here: https://bitbucket.org/yminsky/ocaml-core/src/8e757d8f7309/base/core/lib/core_hashtbl.ml (Don't rely on that repo too much yet, btw. We're probably going to blow it away and create a new one in the next couple of days. But going forward, we plan on using bitbucket as a place to work together with the community on Core.) y On Fri, Dec 30, 2011 at 2:01 PM, David Allsopp dra-n...@metastack.comwrote: Yaron Minsky wrote: For just this reason, the hashtables in Core have been reimplemented to use an AVL tree in the buckets. That way, even when you have pathological collisions, you degrade gracefully to O(log n) per operation, instead of O(n), where n is the number of keys in the hashtable. I'm resisting the temptation to hack-it-and-see: does your implementation do anything clever to maintain Hashtbl's O(1) insertion time (e.g. Hashtbl.add updates a list and then the first call to Hashtbl.find or Hashtbl.mem moves any items from the list to the AVL). Or does doing that impact general performance too much? In the POST web scenario (or processing HTTP request headers), for example, degrading Hashtbl.add from O(1) to O(log n) is only acceptable if you know that you'll query all the fields in the POST (which isn't necessarily true). David -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] Async, a monadic concurrency library
I admit to a certain amount of ambivalence to releasing Yet Another Monadic Concurrency library. (I don't think Equeue is in quite the same category, since it has such a different style of interface.) But I think we had good reasons for creating Async. As I said in my blog post, the differences in error-handling and interleaving policy were enough that we really felt we needed a different library. And now that we've created it, there are multiple reasons to release it. For one thing, we want it for out own open-source projects outside of the office! And it's a precondition for us for releasing other software that we've developed internally that depends on Async. As an aside, we use lots of OCaml libraries developed outside our walls: RES, PCRE, Lacaml, Postgres bindings and OUnit and xml-light, to name some off the top of my head. y On Wed, Oct 26, 2011 at 3:33 AM, Gerd Stolpmann i...@gerd-stolpmann.dewrote: Which is already the third one (Equeue and Lwt being the others). I'm very up to reinventing the wheel, but I guess there is some reason. Does Janestreet use any open source libraries? Or does the commitment not go that far? Gerd Am Dienstag, den 25.10.2011, 20:32 -0400 schrieb Yaron Minsky: While we're in the announcing mood, I wanted to announce the first public release of Async, Jane Street's monadic concurrency library. You can find out more about Async here: http://ocaml.janestreet.com/?q=node/100 y -- Gerd Stolpmann, Darmstadt, Germanyg...@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details:http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de *** Searching for new projects! Need consulting for system *** programming in Ocaml? Gerd Stolpmann can help you. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [ANN] Async, a monadic concurrency library
It's an excellent question, and one I don't yet have a good feel for. It would be great to find some kind of modus vivendi which would allow the libraries to interoperate. For now, it hasn't been too big of an issus, since the external libraries we've needed haven't been Lwt-based. But it would be nice to solve the problem nonetheless. y On Wed, Oct 26, 2011 at 7:18 AM, ri...@happyleptic.org wrote: As an aside, we use lots of OCaml libraries developed outside our walls: RES, PCRE, Lacaml, Postgres bindings and OUnit and xml-light, to name some off the top of my head. What if someday you want to use an external library that uses lwt ? Will it be possible to mix the two ? Since this kind of monadic library can easily impose its behavior on all other library around (if for nothing else than the exception mechanism to use), I have the feeling that for us mere users choosing between lwt and async is to choose between two large sets of incompatible libraries, am I wrong ? -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] [JOB] OCaml Developer at Jane Street
Whoops. The link to the post on Async was busted, but it is now fixed. On Tue, Oct 25, 2011 at 6:25 PM, Yaron Minsky ymin...@janestreet.comwrote: Jane Street is looking to hire functional programmers for our offices in New York, London and Hong Kong. We're looking for both interns for this upcoming summer as well as full-time hires. Jane Street has the largest team of OCaml developers in any industrial setting, and probably the world's largest OCaml codebase. We use OCaml for running our entire business, supporting everything from statistical research to systems administration to automated trading systems. If you're interested in using OCaml to solve real-world problems, there's no better place. Jane Street has (in my humble opinion) a great work environment. It has a very informal feel --- if you dress much nicer than a t-shirt in jeans, you'll look out of place --- but it's also an intellectually challenging place where you get to wrestle with hard problems and learn about the subject matter of trading, a fascinating field in its own right. There's also a strong focus on education, with both on the job training and a system of formal classes. We also have a strong commitment to OCaml and to open-source software. We released our Core suite of libraries a few years back, and we continue to extend the reach of our public releases. And we have and will continue to financially support projects to improve the OCaml ecosystem. Compensation is more than competitive, and no prior experience with finance is required. Here are some resources you can use to learn more about Jane Street and what we do. - A talk I gave at CMU about how and why we use OCaml http://ocaml.janestreet.com/?q=node/61 - Our technical blog: http://ocaml.janestreet.com If you want to get a flavor of our approach to software, you might be interested in looking at Async, a monadic concurrency library we just released: http://ocaml.janestreet.com/?q=node/100 Follow this link to apply: http://janestreet.com/apply y -- Yaron Minsky -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] [ANN] Async, a monadic concurrency library
While we're in the announcing mood, I wanted to announce the first public release of Async, Jane Street's monadic concurrency library. You can find out more about Async here: http://ocaml.janestreet.com/?q=node/100 y -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Dependent types ?
As written, the behavior of the types might not be what you expect, since
addition of two 16 bit ints may result in an int that requires 17 bits.
When using phantom types, you need to be especially careful that the types
mean what you think they mean.
On Sep 26, 2011 8:13 AM, Denis Berthod denis.bert...@gmail.com wrote:
Hello,
I think that achieving something very near from what you whant is
relatively easy using phantom types.
That avoid the boxing/unboxing in records.
type i16
type i32
module SizedInt:
sig
type 'a integer
val int16: int - i16 integer
val int32: int - i32 integer
val add: 'a integer - 'a integer - 'a integer
end
=
struct
type 'a integer = int
let int16 x = x
let int32 x = x
let add x y = x + y
end
then
open SizedInt
let bar =
let x = int16 42 in
foo x
must have type i16 integer - i16 integer
Regards,
Denis Berthod
Le 26/09/2011 13:42, Jocelyn Sérot a écrit :
Hello,
I've recently come across a problem while writing a domain specific
language for hardware synthesis
(http://wwwlasmea.univ-bpclermont.fr/Personnel/Jocelyn.Serot/caph.html).
The idea is to extend the type system to accept size annotations for
int types (it could equally apply to floats).
The target language (VHDL in this case) accept generic functions,
operating on ints with variable bit width and I'd like to reflect this
in the source language.
For instance, I'd like to be able to declare :
val foo : int * int - int
(where the type int is not annotated, i.e. generic)
so that, when applied to, let say :
val x : int16
val y : int16
(where 16 is a size annotation),
like in
let z = foo (x,y)
then the compiler will infer type int16 for z
In fact, the exact type signature for foo would be :
val foo : ints * int s - ints
where s would be a size variable (playing a role similar to a type
variable in, for ex : val map : 'a list - ('a -'b) - 'b list).
In a sense, it has to do with the theory of sized types (Hughes and
Paretto, .. ) and dependent types (DML for ex), but my goal is far
less ambitious.
In particular, i dont want to do _computations_ (1) on the size (and,
a fortiori, don't want to prove anything on the programs).
So sized types / dependent types seems a big machinery for a
relatively small goal.
My intuition is that this is just a variant of polymorphism in which
the variables ranged over are not types but integers.
Before testing this intuition by trying to implement it, I'd like to
know s/o has already tackled this problem.
Any pointer - including well, this is trivial ! ;-) - will be
appreciated.
Best wishes
Jocelyn
(1) i.e. i dont bother supporting declarations like : val mul : intn
* intn - int 2*n ...
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] A limitation of with type declarations for first-class modules
On Tue, Sep 20, 2011 at 5:03 PM, Alain Frisch alain.fri...@lexifi.comwrote: The important point is that package types (the ... in a type expression (module ...) or in an expression (module M : ...)) are not module types. Syntactically, they are indeed a subset of module types, but it is a strict subset, and they obey different rules than module types. Package types live at the boundary between types and module types. In a packing expression (module M : ...), the package type must produce a well-typed module type. This is why you cannot write (module M : S with type t = 'a), because S with type t = 'a is not a proper module type. But (module S with type t = 'a) is a correct type. Package types must also support all operations on types, including equality, unification, etc. For instance, unifying (module S1 with type t = 'a) and (module S2 with type t = 'b) is defined as checking than S1 and S2 are equivalent paths and unifying 'a and 'b. The fact that a package type can also be seen as a module type is nowhere used in this definition. (Of course, one must be careful when defining equality of package types that it does not allow to cast a module from one module type to an incompatible one.) There is some flexibility in both the definition of admissible package types and the definition of equality between package types. For instance, I don't see any problem or difficulty in your proposal of allowing constraints on types nested in sub-modules (but this should be checked carefully). Feel free to open a feature request for this! Will do. Similarly, one could allow with type t := constraints in addition to with type t =. Is there a need for that? I haven't seen one yet, but I'll keep my eyes out. One could also relax equality of package types (module S1 with ...) and (module S2 with ...) by checking that S1 and S2 expand to structurally equivalent module types (with the exact same ordering between value components!). Would that replace the dependence on paths that you describe above? The use of paths has turned out to be pretty fragile in my experience, with module types that should have been the same showing up as different in the presence of rebinding of module signatures, which we would normally do as a way of improving concision and readability. y -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] A limitation of with type declarations for first-class modules
For some reason, 1st-class modules have more restrictive with syntax, which turns out to be a practical problem. The main constraint is that with constraints do not seem to be able to refer to sub-modules. Consider the following code snippet: module type Foo = sig type t end module type Bar = sig module Foo : Foo end (* compiles *) let g (type a) (m : (module Foo with type t = a)) = () (* fails to compile with a syntax error *) let f (type a) (m : (module Bar with type Foo.t = a)) = () Of course, ordinary modules have no such constraint. Any thoughts as to what is going on here, and whether it can be fixed? This has really restricted designs I've been using, forcing me to flatten out structures that are more naturally nested. y -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
