[Caml-list] Extending Set - strange behavior of abstract type
I tried to extend the standard Set module with new operations. I got error messages about type incompatibilities (the Set.S.t as exposed by my implementation and Set.S.t used by functions from the original Set). I have reduced my code to the following small example: module Set = struct module Make (Ord : Set.OrderedType) = struct module Set = Set.Make(Ord) include Set end end module OrdChar = struct type t = char let compare = compare end module Raw1 = Set.Make (OrdChar) module Raw2 = Set.Make (struct type t = char let compare = compare end) let aaa (aa : Raw1.t) (bb : Raw1.Set.t) = (aa = bb) let aaa (aa : Raw2.t) (bb : Raw2.Set.t) = (aa = bb) Only the last line results in an error: Error: This expression has type Raw2.Set.t but is here used with type Raw2.t All the rest of the code compiles correctly. It means that types Raw1.t and Raw1.Set.t can be unified. My question is: why these nearly identical statements results in different behavior of the type t? I'd really prefer Raw1 and Raw2 to be identical. I use ocaml 3.11.0. Dawid ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Extending Set - strange behavior of abstract type
Dawid Toton d...@wp.pl wrote: I tried to extend the standard Set module with new operations. I got error messages about type incompatibilities (the Set.S.t as exposed by my implementation and Set.S.t used by functions from the original Set). I have reduced my code to the following small example: module Set = struct module Make (Ord : Set.OrderedType) = struct module Set = Set.Make(Ord) include Set end end module OrdChar = struct type t = char let compare = compare end module Raw1 = Set.Make (OrdChar) module Raw2 = Set.Make (struct type t = char let compare = compare end) let aaa (aa : Raw1.t) (bb : Raw1.Set.t) = (aa = bb) let aaa (aa : Raw2.t) (bb : Raw2.Set.t) = (aa = bb) Only the last line results in an error: Error: This expression has type Raw2.Set.t but is here used with type Raw2.t That is a known limitation of Ocaml's module system: type equivalence is only propagated through a syntactic subset of module expressions, so called paths (which consist of only module names, dot access, and functor applications). Roughly, in your example, Raw1.t is just an abbreviation for Set.Make(OrdChar).t, which in turn abbreviates Set.Make(OrdChar).Set.t, which expands to Set.Set.Make(OrdChar).t. In all these type names the bits before the .t are in path form, which makes the type expressions legal. Raw2.t, on the other hand, would expand to Set.Make(struct ... end).t - however, literal structures are not allowed in paths, so this type expression is illegal, and Ocaml simply forgets the equivalence. The workaround is never to apply a functor to an anonymous structure if you care about maximum type propagation. Just name it, which is easy enough in most cases. /Andreas ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] overbld (ocaml+libraries under mingw) - binary release
Hello. I've finally resolved the 'license' question that was worrying me for a long time because of my stupidity, and now we are ready to present windows binary installer of OCaml/MinGW + libraries. Moreover, there are _two_ installers. They share in common the following features: - OCaml+libraries for win32 mingw - Fresh versions of OCaml, fresh versions of libraries. New libraries are added too, if they are cool _and_ portable, _or_ if you want to share the library or the way to compile it under mingw and you have tested the library somehow. - Set the environment variables (either source /path/set-vars.sh for bash or call c:\path\set-vars.bat for windows shell) and use OCaml, misc OCaml libraries, MinGW, MSYS, Mercurial, ActiveState Tcl/Tk, GTK, 7zip. Things that are specific to binary builds: - You don't need to compile anything to use OCaml+libraries. - You can install it only to fixed path, due to hardcoded paths in OCaml, findlib and maybe some other libraries. Things that are specific for source builds: - You can get new sources instantly, before the compilation process that installer runs, and you can update sources anytime you need (that's a direct way to contribute (very welcome!). If you have installed the sources, you can add new library or fix something in old libraries quickly, and share the results, and so on -- the opensource works!). - Mercurial repository for sources, MercurialQueues for testing new features (for example, you can apply mq patches to test new unreleased OCaml 3.12 from SVN trunk or to see my miserable attempts to port JoCaml under MinGW). Here is the list of libraries in overbld: batteries camlidl camltemplate camlzip camomile cryptokit deriving extlib findlib json-static json-wheel lablgtk2 lwt menhir objsize ocaml-bitstring ocaml-sqlite3 ocaml-ssl ocamlgraph ocamlnet omake ounit pa_do pa_safeuse pcre-ocaml react sexplib type-conv ulex xmlm The installers are distributed via BitTorrent (due to large size). The .torrent files are available at http://sourceforge.net/projects/overbld/files/ The project is hosted at http://sf.net/projects/overbld/ , since sourceforge allows the read-only access to repository for anonymous users, but there is a mirror on http://forge.ocamlcore.org/projects/overbld/ (updated manually). Due to the nature of DVCS, there is an exact copy of the repository in the source installer. Please, use our bugtracker ( http://sourceforge.net/tracker/?group_id=280863atid=1191746 ) for feedback and bug reports, new [possible] features, suggestions and so on. We really appreciate your feedback! With best regards, the guys that do the dirty work: Dmitry Grebeniuk, Roman Sokolov. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Re: Extending Set - strange behavior of abstract type
On 27-04-2010, Dawid Toton d...@wp.pl wrote: I tried to extend the standard Set module with new operations. I got error messages about type incompatibilities (the Set.S.t as exposed by my implementation and Set.S.t used by functions from the original Set). I have reduced my code to the following small example: module Set = struct module Make (Ord : Set.OrderedType) = struct module Set = Set.Make(Ord) include Set end end module OrdChar = struct type t = char let compare = compare end module Raw1 = Set.Make (OrdChar) module Raw2 = Set.Make (struct type t = char let compare = compare end) let aaa (aa : Raw1.t) (bb : Raw1.Set.t) = (aa = bb) let aaa (aa : Raw2.t) (bb : Raw2.Set.t) = (aa = bb) Only the last line results in an error: Error: This expression has type Raw2.Set.t but is here used with type Raw2.t All the rest of the code compiles correctly. It means that types Raw1.t and Raw1.Set.t can be unified. My question is: why these nearly identical statements results in different behavior of the type t? I'd really prefer Raw1 and Raw2 to be identical. You just have to propagate the type by hand: module Set = struct module Make (Ord : Set.OrderedType) = struct include Set.Make(Ord) module Set : Set.S with type t = t = Set.Make(Ord) end end The type t = t do the trick. The first t is bound inside Set and the other comes from include Set.Make(Ord). Regards Sylvain Le Gall ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
