Re: [Caml-list] Re: Generalized Algebraic Datatypes
On 30/10/2010 1:14 AM, Jacques Garrigue wrote: On 2010/10/30, at 8:01, Jacques Le Normand wrote: Note that, as in Jacques's examples, the constructor function was not curryfied. (type t = A of bool * int) would generate a function (A : bool * int -> t). Actually, curryfied constructors are not allowed, so this is not accepted. (Existential types are allowed, which may have confused the other Jacques) I was not confused at all. Jacques Carette PS: ;-) ___ 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] Why is this allowed?
bluestorm wrote: It is actually not the case that type structure items can be shadowed : # module A = struct type t = int;; type t = int end;; Error: Multiple definition of the type name t. Names must be unique in a given structure or signature. Exactly. My desired would be for this non-shadowing restriction to be extended to all types, not just type structure items. Shadowing at the value level is an entirely different issue, and is perfectly fine as it is. Jacques ___ 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] Why is this allowed?
Nice trick - but my 'problem' [1] regards arbitrary valid OCaml code and how to serialize code values. The issue seems to be that one needs to attach an arbitrarily large typing environment to each part of a value, as there is no global typing environment which will do the job (because of shadowing). Jacques [1] Actually 'our' problem, in that this arose from some issues in metaocaml, and I am working with Oleg to figure out what is going on. Interestingly, this never arose in 3.09 and before. Till Varoquaux wrote: AFAIK you are allowed to shadow just about anything in implementations. If you wanted to keep the exact same interface but retain the ability to avvoid the shadowing issue on the labels you could do: module Foo = struct type t = Foo end type foo = Foo.t = Foo module Foo2 = struct type t = Foo | Bar end type foo2 = Foo2.t = Foo | Bar HTH, Till On Mon, May 31, 2010 at 10:46 AM, Jacques Carette wrote: type foo = Foo let x = Foo type foo2 = Foo | Bar let y = Foo let z = (x,y) ;; I thought that re-using of algebraic labels was not allowed - but apparently it is? Note that this means that it is impossible to "text" print such structures and hope to recover them uniquely. This also causes very subtle issues when Marshal'ing, and grave issues for code generation [think metaocaml]. Jacques ___ 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 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 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] Why is this allowed?
Lukasz Stafiniak wrote: But what when someone includes or opens a module with Foo after "type foo = Foo"? What when someone opens it locally in an expression? I would be fine if type-level shadowing was disallowed for all those cases. Does a variant value have a unique type with a unique path so that it would be possible to guarantee that within this unique path there are no type *definitions* that override a variant name? That would be nice. Jacques On Mon, May 31, 2010 at 4:46 PM, Jacques Carette wrote: type foo = Foo let x = Foo type foo2 = Foo | Bar let y = Foo let z = (x,y) ;; I thought that re-using of algebraic labels was not allowed - but apparently it is? ___ 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] Why is this allowed?
type foo = Foo let x = Foo type foo2 = Foo | Bar let y = Foo let z = (x,y) ;; I thought that re-using of algebraic labels was not allowed - but apparently it is? Note that this means that it is impossible to "text" print such structures and hope to recover them uniquely. This also causes very subtle issues when Marshal'ing, and grave issues for code generation [think metaocaml]. Jacques ___ 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] Unicode solutions
I need to be able to lex/parse and pretty-print unicode with caml. I am aware of several 'solutions' for each part, but I would choose to use whatever library seamlessly allows me to both parse and build pretty-printers for unicode-based input. For example, it is unclear to me that module Print in Batteries integrates well with UTF8.t - but that could just be a documentation issue. Camomile seems to be good for the representation part, but does not seem to offer lex/parse and pretty-print modules. It seems like ulex + dypgen works for the front-end part. Back-end? [It's not clear to me that ulex + menhir works] Jacques ___ 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] Compiling 3.11.2 using cygwin
Sorry, in that first paragraph it should be "build/partial-install.sh can't find config/config.sh". Jacques Jacques Carette wrote: I am trying to compile 3.11.2 using cygwin, with a non-standard -prefix. I have tried various prefixes, all unsuccessfully. Everything seems to proceed fine during compilation, the only hiccup is that "make install" complains it can't find build/partial.sh, but otherwise everything seems 'fine'. But if I try to start the newly installed binary, it immediately dies because it can't find pervasives.cmi (even though it is there, in lib/ocaml/pervasives.cmi right beside bin/ocaml). I looked on the archives of caml-list and on mantis, and did not find anything helpful. I am at a loss as to what to do now. Any ideas? Jacques ___ 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 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] Compiling 3.11.2 using cygwin
I am trying to compile 3.11.2 using cygwin, with a non-standard -prefix. I have tried various prefixes, all unsuccessfully. Everything seems to proceed fine during compilation, the only hiccup is that "make install" complains it can't find build/partial.sh, but otherwise everything seems 'fine'. But if I try to start the newly installed binary, it immediately dies because it can't find pervasives.cmi (even though it is there, in lib/ocaml/pervasives.cmi right beside bin/ocaml). I looked on the archives of caml-list and on mantis, and did not find anything helpful. I am at a loss as to what to do now. Any ideas? Jacques ___ 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] general question, was Re: OCaml is broken
I agree with most of what Dario Teixeira wrote, except for one small quibble: Dario Teixeira wrote: Last but not least, Ocaml plays a central role in multiple INRIA projects, which means its creators have all the reason to continue maintaining it and improving it for the foreseeable future (and there's some interesting goodies in the upcoming 3.12 release, for example). Actually, this gives these projects an incentive to insure that Ocaml survives, which gives an incentive for some 'maintenance engineers' to be kept on-staff to insure that Ocaml does not bit-rot. This gives only quite partial incentive to a team of researchers (the creators of Ocaml) to do maintenance (as that is usually not research, thus not the kind of work of interest to researchers). And entropy is a real problem -- Ocaml is now quite mature, which means that radical changes are well nigh impossible; this is a serious disincentive for researchers. End of quibble. Personally, I would really really want to see a 4.00 release which really warrants that name. The 3.XX line can be maintained for a few more years while people switch, in the same way gcc did this. In any case, I have nevertheless voted with my time and effort: I have 1 large project being implemented in Ocaml, 3 medium ones in metaocaml, although I must admit that I have some 'research' code in Haskell (and in Maple, but that's another story). Jacques ___ 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] Ocaml clone detector
Erik de Castro Lopo wrote: > Maybe it would help if you explained what a "clone detector" > is. > A "clone" is software-engineering speak for "duplicated code". Exactly what qualifies as 'duplicated code' and how to efficiently find such (without too many false positives nor false negatives) is still fairly active research. This is a huge issue in languages without decent abstraction features, and less so otherwise (or so it seems). Jacques ___ 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] Width subtyping
Dario Teixeira wrote: In other words, polymorphic variants provide a very elegant solution for subtyping with sum types. Is there some brilliant idea that could do the same for product types? The dual of sums is products. Open (labelled) sums are "polymorphic variants". Their duals are open (labelled) products are "rows" (which O'Caml already supports, through its objects). See TAPL for a nice introduction to the type theory of labelled records with subtyping (i.e. rows). Jacques PS: note that O'Caml's products are positional while its sums are labelled, so the duality present in the theory isn't as clear there. The better dual for O'Caml's sums is really records. ___ 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] Shared types: dependency in modules with polymorphic type
One modification which will get you a long way towards your goal is to remove the : VB from Hugo Ferreira wrote: module VB1 : VB = struct ... While this may look like it is just "type checking", it in fact does more and makes sure that VB1.t, to the outside world, is abstract. This stops any possibility of unification with 'like' types. Same with Make_U. Note that VB1 will still be of type VB, and you can be sure of that because the constraint in Make_U's signature will enforce it -- only a bit later than at declaration time, at use-time. My question is: is their any way I may organize the modules or indicate shared types in order to use a (very extensive) VB interface (Or VB1 module)? Specifically how do I enforce the shared type: U1.instance VB1.t = U1.t = Make_U(VB1).t First, try the above. It may help. If it does not, then you will need to add explicit sharing constraints. But which sharing constraints are *really* needed will be the ones revealed by first removing the type annotations you currently have. Note that you should not have to re-organize your modules at all to achieve this [at least, not in this example]. Jacques ___ 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] Defining a family of functors
Andrej Bauer wrote: Because of problems like these I sometimes wish I had first-class modules. I wonder how different that is from having first-class polymorphic records, actually. Perhaps a bit of camlp4 to wrap up records in module-like notation would do the trick. If your modules do not define new types, then the main difference is that of name spaces (records pollute the global namespace, modules define local namespaces). However, I could not get far with modules that only define new values (functions). Bottom line: I too very much wish for first-class, higher-order modules. As O'Caml already has open and closed products (viz rows and records), open and closed sums (viz polymorphic and 'normal' variants), the resulting system could steal back the 'elegant' monicker that has drifted towards Haskell. Jacques ___ 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] ocaml 3.11, Vista 64/cygwin/gcc4
Has anyone managed to compile 3.11 on Vista 64 under cygwin using gcc4 [and without flexlink]? Compilation of byterun/interp.c fails miserably, with most _caml_ symbols returning 'undefined reference's. Strangely, configure thinks that my system is 32 bits, which is quite possibly another source of problems. Jacques PS: I'll soon enough install some flavour of Ubuntu on this machine too, which should fix my problems. But in the meantime, I would still like to be able to keep on working! ___ 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] Defining a family of functors
Without the projections, you can do it via a higher-order Functor which does a fold, ie lifting to the Functor level what one usually does to get an n-ary product out of a binary product. With the projections, as this involves name-generation, I don't see how to do it without using camlp4. Even my favourite sledgehammer, metocaml, can't help here. Jacques Michaël Grünewald wrote: I am facing a situation that could be solved by ``defining a family of functors'', I describe the problem and would be very glad to get your views about it. To illustrate the situation, I will suppose A1, ..., An are modules implementing the same signature S, let's say S contains the usual opertations on groups (mathematical groups, you can replace this by vector spaces, or whatever). It is easy to write a Product2 functor Product2: A1:S -> A2:S -> S2 producing an implementation for the direct product (with signature S) of the groups A1 and A2, plus injections j1 : A1.t -> S2.t and j2: A2.t -> S2.t and corresponding projections (the type t denotes the module thingie, as usual). This extension of S is here written S2. My problem is ``how do I remove the 2'' ? Would it be possible to define a functor scheme [:)] Productn: A1:S -> .. -> An:S -> Sn able to instantiate concrete functors for any value of n ? It is possible to generate automatically appropriate code for small values of n, but I am looking for a better approach. It is simple to get close of the solution in the object paradigm, since I can simply put objects in an array and iterate over this array (IIRC this is the aggregate design pattern), but I do not see an easy way to define injections and projections. ___ 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] polymorphic variants, long form
Luc Maranget wrote: What is the proper 'long name' of a polymorphic variant? module S = struct type a = [`Foo of int] end How do I refer to `Foo without opening S? Both S.`Foo and `S.Foo are syntax errors. Jacques 'Foo does the job, it does not refer to any previous type definition. % ocaml Objective Caml version 3.11.0 # `Foo;; - : [> `Foo ] = `Foo Just a few minutes after I sent my email, I remembered the answer myself: unlike normal variants, polymorphic variants are not scoped but affect the namespace in a GLOBAL way. Both extremely convenient and non-modular at the same time. Jacques ___ 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] polymorphic variants, long form
What is the proper 'long name' of a polymorphic variant? module S = struct type a = [`Foo of int] end How do I refer to `Foo without opening S? Both S.`Foo and `S.Foo are syntax errors. Jacques ___ 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] Private types in 3.11, again
Hmmm, a variant of your code may be exhibiting a bug in ocaml 3.11.0. In your signature, change the +'a t signature to type +'a t = private [< elem_t ] and remove all annotations from the definition of sprint2. Then, as defined, one gets the error message File "bug2.ml", line 26, characters 0-223: Error: Signature mismatch: Modules do not match: sig val sprint2 : ([< `Bold of 'a list | `Text of string ] as 'a) -> string end is not included in sig val sprint2 : 'a Node.t -> string end Values do not match: val sprint2 : ([< `Bold of 'a list | `Text of string ] as 'a) -> string is not included in val sprint2 : 'a Node.t -> string which is not very informative, especially since expanding 'a Node.t gives exactly what the compiler reports as the first argument of sprint2. To coax the compiler to be more helpful, on places the definition of sprint2 outside a module (but still in the same file as Node), and instead the result is: File "bug2.ml", line 30, characters 26-29: Error: This expression has type Node.elem_t list but is here used with type 'a Node.t list Type Node.elem_t = [ `Bold of Node.elem_t list | `Text of string ] is not compatible with type 'a Node.t = [< `Bold of Node.elem_t list | `Text of string ] Types for tag `Text are incompatible [That point to the seq in List.map sprintf2 seq]. Here is where the potential bug is: how is string incompatible with string? [If this is a bug, I'll add it to the database] Jacques ___ 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] private types - suggestion
[See full code below] I have encountered a fairly subtle issue with private types which doesn't occur otherwise. The source of the issue, I believe, is actually the need to have a 'row variable' available to be able to use 'private' on a polymorphic variant. In the code below (a massive simplification of my actual case), f compiles, but g does not, with error Error: This pattern matches values of type [> `Operator of 'a * 'b list * 'c S.pk ] but is here used to match values of types S.operator Types for tag `Operator are incompatible (pointing to the line that starts with | `Operator ...) First suggestion: could the error message please include what the incompatibility is? Second suggestion: could the type S.operator be (also) given in its 'expanded' form? It would be useful to know what the compiler thinks the type S.operator actually is. Third suggestion: in this particular case, could the error message include some hints that the problem is one of [< ] vs [> ] ? [if my understanding of the issue is correct!] I will add these suggestions to the bug system next, but I figured others on this list might benefit from my experience in debugging this issue in my code. Jacques PS: I actually don't want the intermediate type pk, po, pb and ps to be visible at all outside of S, but I do not know how to achieve that without adding another layer of indirection. Any advice along these lines would be appreciated. PPS: I experimented with variance annotations too, thinking that that might do the trick, but to no avail. --- module S : sig type 'a pk = KType | KFormula | Kind of 'a pb and 'a po = [`Operator of string * 'a pk list * 'a pk ] and 'a pb = [`Thing of string] type 'a ps = ['a po | 'a pb] type se = se ps type operator = private [< se po] end = struct type 'a pk = KType | KFormula | Kind of 'a pb and 'a po = [`Operator of string * 'a pk list * 'a pk ] and 'a pb = [`Thing of string] type 'a ps = ['a po | 'a pb] type se = se ps type operator = se po end open S (* this one works *) let f (o:operator) : string = match o with | `Operator(s, [], S.KType) -> s | `Operator(_,_,_) -> failwith "nope" (* this one doesn't ! *) let g (o:operator) : string = match o with | `Operator(s, [], S.KType) -> s | _ -> failwith "nope" ;; ___ 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] Defining type that requires hashtables with recursive definition
Hugo Ferreira wrote: I am attempting to define a type so: type node = | Node of links | Leaf of int And I want to implement links as a hashtable whose keys and values are also of type node. type node = | Node of links | Leaf of int and links = (node, node) Hashtbl.t should do it. Jacques ___ 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] Debugging the compiler
Nothing like the holidays for a little playing around with some ideas by modifying a compiler... Having got the hang of bootstrapping the compiler [with help from old caml-list postings], I managed to get quite a few things working, but now I have a bug. I dug around the configure scripts and the Makefiles, and did not see any ready-made way to compile the compiler with debugging enabled - is this possible? I searched the archives for help on this topic, but came up empty-handed. Any and all advice on 'debugging the compiler' would be most appreciated. Jacques ___ 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] Typing Dynamic Typing in ocaml?
Stéphane Glondu wrote: 2) How do I embed 'dynamically known' data into a single ocaml data-structure? [...] You might be interested by the following: http://gforge.inria.fr/plugins/scmsvn/viewcvs.php/trunk/lib/dyn.ml?rev=5920&root=coq&view=markup Scarily enough, I do believe that that is exactly what I need. I guess I was hoping to avoid Obj, but this may be one of those instances where it is indeed the most reasonable compromise. Jacques ___ 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] Typing Dynamic Typing in ocaml?
I have two (related) questions: 1) Has anyone transcribed the TypeRep library into ocaml? http://people.cs.uu.nl/arthurb/dynamic.html 2) How do I embed 'dynamically known' data into a single ocaml data-structure? More specifically, I am experimenting with a (new) language which allows deduction and computations to be performed with equal ease on its terms. This language uses ocaml has the host meta-language (ie the interpreter is written in ocaml). I would like to be able to use arbitrary ocaml data-structures to represent some of my terms, when these terms are known to come from specific theories. For example, I would like to use Bigint to represent integers, but without exposing that per se. Perhaps a better way to phrase this would be to say that I want to have a "generic external data container" type in my language terms, which I can instantiate in multiple different ways (in the same program), with data handled in different modules, without having to change the 'generic' data-structure everytime I add a new module. Polymorphic variants of course come to mind - but they would force me to add a new type parameter to all my types, which I would rather avoid. I would be quite happy to use polymorphic variants if I could 'hide away' the extra type parameter involved with open variants. My attempts at hiding this parameter (with existentials) has been too successful, in that once hidden I can't extract my data from this container anymore [which is the correct behaviour for the compiler]. I thought of using objects too, but my data does not really have any common structure, so the object would be a pure container. I cannot see any advantage over polymorphic variants, and all the same headaches of an 'extra' polymorphic parameter remain. Jacques ___ 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] Using camlp4 in extensions
Mauricio Fernandez wrote: I believe he's not referring to simultaneous use of pa_monad and another extension in user code, but of Camlp4MacroParser *in* the sources of pa_monad. That's right. Since pa_monad is build with ocamlc -I +camlp4 -pp camlp4orf -c pa_monad.ml changing that to ocamlc -I +camlp4 -pp "camlp4orf Camlp4MacroParser.cmo" -c pa_monad.ml might work. Definitely worth exploring, thanks! Jacques ___ 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] Using camlp4 in extensions
Question: is there a way to use a camlp4 extension *inside* the definition of another? AFAIK, extensions are not ordered, so trying to use camlp4 to deal with IFDEF in the source of a syntax extension (like pa_monad) to switch between 3.10 and 3.11 [to deal with the new private and lazy features] does not seem possible. Or have I missed something? Jacques ___ 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] announce: pa_monad 6.0
pa_monad has been updated to work with Objective Caml 3.11.0. Quite a lot of maintenance work has also been performed (including a renumbering of the versions to be less haphazard). See http://www.cas.mcmaster.ca/~carette/pa_monad/index.html for details. Jacques, Lydia and Oleg ___ 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] OCaml 3.11.0 release candidate
In the CYGWIN32, SUPPORT_DYNAMIC_LINKING version of 3.11.0+rc1, file unix.c has the following lines: 178: return flexdll_dlopen(libname, flags); 193: return flexdll_dlsym(flexdll_dlopen(NULL,0,1), name); My version of gcc is extremely unhappy about line 193 [and says so loudly by quitting], since it corresponds to a call to flexdll_dlopen with an incorrect number of parameters. Jacques ___ 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] Notes from testing OCaml 3.11.0+beta1 on Fedora
Richard Jones wrote: ocaml-pa-monad -- Stricter module naming restrictions in 3.11: ocamlc -warn-error AX -g -pp 'camlp4orf -I . pa_monad.cmo' -c pythagorean-triples.ml File "pythagorean-triples.ml", line 1, characters 0-1: Warning X: bad source file name: "Pythagorean-triples" is not a valid module name. File "pythagorean-triples.ml", line 1, characters 0-1: Error: Error-enabled warnings (1 occurrences) We are just about to release a new version of pa-monad which will fix this problem. Jacques ___ 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] Re: Metaprogramming features
Jon Harrop wrote: So the translation from MetaOCaml to OCaml is not obvious at all. This begs the question: could another formulation of MetaOCaml avoid these complications without losing expressiveness? No. See some of the early papers of Taha and papers from Sheard around the same time. BTW, F#'s metaprogramming features are much much less powerful than metaocaml's. We tried to use them to generalize some previous work I (with some other colleagues) had done in metaocaml, but couldn't. Essentially, F#'s splices are first-order only. Jacques ___ 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] Metaprogramming features
A number of you are already aware of the following feature request: http://caml.inria.fr/mantis/view.php?id=4608 whose text reads === I really wish that the basic features of metaocaml, namely .< >., .~ and .! were included in OCaml proper. The many other experimental features of metaocaml could stay 'experimental', those are the 3 which are sorely needed. Note that OCaml could be really ahead of Haskell here (with its untyped Template Haskell, which is closer to camlp4 than to metaocaml) by being the first production language to have _typed_ metaprogramming facilities. === This feature request is currently the entry in Mantis which has (by far!) the largest number of comments from separate people, as well as now being the entry with the most comments overall. Please add your voice to the chorus! Jacques ___ 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] More fun with variants and constraints
[One of my previous difficulties was alleviated by putting variance
annotations on my variables, which was not at all obvious from the
documentation, other than a vague hint that these are not automatically
inferred; I put annotation everywhere in the code below, but +'d is the
only one that matters].
In my actual code, I now have some routines that take a huge amount of
time to compile (I gave up after 30 minutes). Looking into why that
might be, I have produced the following code which shows the issue:
type +'a a0 = [`A of 'a ]
type +'a a1 = [`B of 'a ]
type +'a a2 = [`C of 'a ]
typed = [`D of int ]
type +'a f1 = ['a a0 | d]
type +'a f2 = ['a a1 | d]
type (+'a,+'b,+'c) e = ['b a0 | 'a a1 | 'c a2 | d]
type (+'a,+'b,+'c) c = ('a,'b,'c) e
constraint 'a = [< 'b f1]
constraint 'b = [< 'a f2]
constraint 'c = [< 'c a2 ]
type +'d cc = 'd
constraint 'd = [< ('a,'b,'c) c]
(* This craps out with 'cc' being an inexact variant
let is_cc = function
| #cc -> true
| _ -> false
*)
let id_cc (x: 'd cc) = x
let build (i:int) : 'd cc = `A (`B (`D i))
let a1 = build 1
;;
The type of a1 is reported as
val a1 :
[< `A of [< ([< 'a f1 > `D ] as 'b) f2 > `B ] as 'a
| `B of 'b
| `C of
[< 'c a2 ] as 'c &
[< 'd a2 ] as 'd &
[< 'e a2 ] as 'e &
[< 'f a2 ] as 'f
| `D of int
> `A ]
What is puzzling is the type in `C. Why are there 4 (identical!)
possibilities? I played around some, and the 4 is equal to the number
of constraints in the program.
The issue is, in my 'real' code, there are 33 constraints. Simple
values now have types that take pages and pages of output.
How do I still get all the polymorphism that I want without getting this
kind of blow-up?
Jacques Carette
___
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] Not a variant??
Jacques Garrigue wrote:
The message is maybe not clear enough: for pattern-matching and
inheritance, you need an "exact" variant type, i.e. a type whose lower
and upper bounds are identical.
Indeed - I would suggest that the error include some clearer diagnostics
that indicate how the variant is 'inexact'.
The standard workaround is to write:
type c0 = [a | b]
type 'a c = 'a constraint 'a = [< c0]
This got me further, thanks. But not far enough...
Here is a simple example of the problems I am now running into:
type 'a a = [`A of 'a ]
type 'a b = [`B of 'a ]
typed = [`D ]
type ('a,'b) e = ['b a | 'a b | d]
type ('a,'b) c = ('a,'b) e
constraint 'a = [< 'b a ]
constraint 'b = [< 'a b ]
type 'd cc = 'd
constraint 'd = [< ('a,'b) c]
let is_cc = function
| #cc -> true
| _ -> false
;;
(* complains that cc is not a variant type when trying to define is_cc *)
Jacques Carette
___
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] Not a variant??
The function f1 below works fine -- so type d is seen to be a variant type. However, f2 does not compile because type c is *not* a variant type. However, if one looks at O'Caml's output for type c, it visually looks like a variant, while that of d does not. This is highly confusing. This looks like a bug to me -- both c and d should be recognized as variant types. Jacques type a = [`A ] type b = [`B ] type 'a c = 'a constraint 'a = [< a | b] ;; type 'a d = 'a constraint 'a = b ;; let f1 = function | #d -> true | _ -> false let f2 = function | #c -> true | _ -> false ;; ___ 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] What is the correct way to do this?
I am trying to define a complex AST via polymorphic variants and
constraints. I want to encode my static knowledge of the AST into the
types as much as possible. I have gotten 'close', but not 'close
enough'.
Any help would be most appreciated. Note that I do mean
Jacques
type symbol = S of string
(* translation of kind[] *)
type 't prekind = KType | KFormula | Kind of 't
(* Needed for P-Expr-2 *)
type ('t,'f,'p) prekinded =
KDType of 't
| KDFormula of 'f
| KDTerm of 'p * 't
type ('t,'f,'p) pretyp =
[ `TypeBase of symbol
| `TypeApplyTerm of symbol * ('t,'f,'p) prekinded list (*
specialization of P-Expr-2 *)
| `TypeApp of 't * 'p (* P-Expr-4 *)
| `TypeDepFun of symbol * 't * 't ] (* expanded P-Expr-5 *)
type 't preoperator = [`Operator of (symbol * 't prekind list *
't prekind)] (* P-Expr-1 *)
type ('t,'f,'p) preformula =
[ `FBase of symbol
| `FApplyTerm of symbol * ('t,'f,'p) prekinded list (*
specialization of P-Expr-2 *)
| `FExists of symbol * 't * 'f ]
(* for improper expressions [S-expressions or raw symbols] *)
type 'e preunknown = [ `UE of 'e list | `US of symbol]
type ('t,'e,'f,'p) preterm =
[ `TermBase of symbol
| `ApplyTerm of symbol * ('t,'f,'p) prekinded list * 't (* P-Expr-2 *)
| `TermVar of symbol * 't (* P-Expr-3 *)
| `FunApp of 'p * 'p (* P-Expr-6 *)
| `FunAbs of symbol * 't * 'p (* P-Expr-7 *)
| `IfTerm of 'f * 'p * 'p (* P-Expr-8 *)
| `DefDescr of symbol * 't * 'f (* P-Expr-10 *)
| `IndefDescr of symbol * 't * 'f (* P-Expr-11 *)
| `Quote of 'e (* P-Expr-12 *)
| `Eval of 'p (* P-Expr-13 *)
| `OrderedPair of 'e * 'e ]
(* translation of p-expr[], four sorts of p-expr *)
type ('t,'e,'f,'p) preproper = 'p
constraint 't = [< ('t,'f,'p) pretyp]
constraint 'f = [< ('t,'f,'p) preformula]
constraint 'p = [< ('t,'f,'p) pretyp | ('t,'f,'p) preformula
| ('t,'e,'f,'p) preterm | 't preoperator ]
constraint 'e = [< ('t,'f,'p) pretyp | ('t,'f,'p) preformula
| ('t,'e,'f,'p) preterm | 't preoperator
| 'e preunknown ]
type ('t,'e,'f,'p) preexpression = 'e
constraint 't = [< ('t,'f,'p) pretyp]
constraint 'e = [< ('t,'f,'p) pretyp | ('t,'f,'p) preformula
| ('t,'e,'f,'p) preterm | 't preoperator
| 'e preunknown ]
constraint 'f = [< ('t,'f,'p) preformula]
constraint 'p = [< ('t,'f,'p) pretyp | ('t,'f,'p) preformula
| ('t,'e,'f,'p) preterm | 't preoperator ]
(* here is where things fail -- I want to define convenient short-forms
for the types to that
I can annotate my code. *)
type proper = 'p
constraint 'p = ('t,'e,'f,'p) preproper
The compiler then complains with [where line 81 is the defining line for
'proper' above:
File "types.ml", line 81, characters 4-65:
A type variable is unbound in this type declaration.
In definition
[< `ApplyTerm of
symbol *
([< ('b, [< ('b, 'c, 'a) preformula ] as 'c, 'a) pretyp ] as 'b, 'c,
'a)
prekinded list * 'b
| `DefDescr of symbol * 'b * 'c
| `Eval of 'a
| `FApplyTerm of symbol * ('b, 'c, 'a) prekinded list
| `FBase of symbol
| `FExists of symbol * 'b * 'c
| `FunAbs of symbol * 'b * 'a
| `FunApp of 'a * 'a
| `IfTerm of 'c * 'a * 'a
| `IndefDescr of symbol * 'b * 'c
| `Operator of symbol * 'b prekind list * 'b prekind
| `OrderedPair of
([< `ApplyTerm of symbol * ('b, 'c, 'a) prekinded list * 'b
| `DefDescr of symbol * 'b * 'c
| `Eval of 'a
| `FApplyTerm of symbol * ('b, 'c, 'a) prekinded list
| `FBase of symbol
| `FExists of symbol * 'b * 'c
| `FunAbs of symbol * 'b * 'a
| `FunApp of 'a * 'a
| `IfTerm of 'c * 'a * 'a
| `IndefDescr of symbol * 'b * 'c
| `Operator of symbol * 'b prekind list * 'b prekind
| `OrderedPair of 'd * 'd
| `Quote of 'd
| `TermBase of symbol
| `TermVar of symbol * 'b
| `TypeApp of 'b * 'a
| `TypeApplyTerm of symbol * ('b, 'c, 'a) prekinded list
| `TypeBase of symbol
| `TypeDepFun of symbol * 'b * 'b
| `UE of 'd list
| `US of symbol ]
as 'd) *
'd
| `Quote of 'd
| `TermBase of symbol
| `TermVar of symbol * 'b
| `TypeApp of 'b * 'a
| `TypeApplyTerm of symbol * ('b, 'c, 'a) prekinded list
| `TypeBase of symbol
| `TypeDepFun of symbol * 'b * 'b ]
as 'a the variable 'a is unbound
I can 'fix' that by changing the first line to
type 'p proper = 'p
but that kind-of defeats the point, doesn't it?
___
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] Why is this coercion necessary?
Here is a much simplified version from a (much) larger problem I have recently encountered: type 'a a = [`A of 'a b] and 'a b = [`B of 'a a] and 'a c = [`C ] type 'a d = [ 'a a | 'a b | 'a c] type e = e d # this code gives an error (details below) let f1 (x:e) : e = match x with | `A n -> n | `B n -> n | `C -> `C # this works let f2 (x:e) : e = match x with | `A n -> (n :> e) | `B n -> (n :> e) | `C -> `C f1 gives an error on the "| `B n -> n" line, pointing to the second 'n' with This expression has type e a but is used with type e b These two variant types have no intersection Indeed, they have no intersection, but they have a union! That is what it seems the coercion in f2 'forces' the type-checker to realize, and all works fine. But of course, such coercions end up polluting my code all over the place (since the actual example is made of 9 types with 20 tags in total, and the 'recursive knot' requires 2 parameters to close properly). So, is this a bug? Is there a way to avoid these coercions? Jacques ___ 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] Troublesome nodes
Wolfgang Lux wrote: This problem is apparently easy to solve. Just don't expect an exact super_node_t list argument for the bold function. Instead use val bold : [< super_node_t] list -> nonlink_node_t in the signature and let bold seq = `Bold (seq :> super_node_t list) in the body of the Node module's definition. Indeed, works like a charm. You don't even need the coercion in the body of 'bold' for it to work. This will hopefully allow me to remove some coercions from my own code, and use subtype annotations in the types. Jacques ___ 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] Troublesome nodes
The ingenious use of a recursive module signature seems to be the source of the problem here. If one defines 'bar' inside the module Node, it works fine [but is clearly useless]. What surprises me is that the code (below) also gives the exact same error. In other contexts, I have managed to get such annotations (see the definition of the bold function) to 'work', but not here. I am quite puzzled by this, so if you do get an answer to your question offl-ist, I would appreciate if you could forward it on. Jacques PS: because I am actually using metaocaml for other projects, I am using ocaml 3.09 for my tests, so it is possible that something is different in 3.10. module Node : sig type nonlink_node_t type link_node_t type super_node_t val text: string -> nonlink_node_t val bold: super_node_t list -> nonlink_node_t val see: string -> link_node_t val mref: string -> nonlink_node_t list -> link_node_t end = struct type 'a p1 = [ `Text of string | `Bold of 'a list ] type 'a p2 = [ `See of string | `Mref of string * 'a p1 list ] type 'a p3 = [ 'a p1 | 'a p2 ] type super_node_t = super_node_t p3 type nonlink_node_t = super_node_t p1 type link_node_t = super_node_t p2 let text txt = `Text txt let bold seq = `Bold (seq :> super_node_t list) let see ref = `See ref let mref ref seq = `Mref (ref, seq) end;; Dario Teixeira wrote: Hi, Thanks Jeremy, that's quite ingenious. However, I've hit a problem in the definition of the constructor functions (the full code + compiler error is below). Now, I know that nonlink_node_t is a subset of super_node_t, and therefore any variant valid for nonlink_node_t is also acceptable for super_node_t. But how do I tell this to the compiler? (Note that having users of the module manually casting types with :> is something I would rather avoid). Thanks again, Dario module rec Node: sig type nonlink_node_t = [ `Text of string | `Bold of Node.super_node_t list ] type link_node_t = [ `See of string | `Mref of string * nonlink_node_t list ] type super_node_t = [ nonlink_node_t | link_node_t ] val text: string -> nonlink_node_t val bold: super_node_t list -> nonlink_node_t val see: string -> link_node_t val mref: string -> nonlink_node_t list -> link_node_t end = struct type nonlink_node_t = [ `Text of string | `Bold of Node.super_node_t list ] type link_node_t = [ `See of string | `Mref of string * nonlink_node_t list ] type super_node_t = [ nonlink_node_t | link_node_t ] let text txt = `Text txt let bold seq = `Bold seq let see ref = `See ref let mref ref seq = `Mref (ref, seq) end open Node let foo = text "foo" let bar = bold [text "bar"] Error: This expression has type Node.nonlink_node_t but is here used with type Node.super_node_t The first variant type does not allow tag(s) `Mref, `See __ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html ___ 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 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] Phantom types: transparency vs rogue unification
How about leaving your type opaque but changing your implementation of parse to let parse s = Stringies.make (float_of_string s) ? In my tests, this works as you intended. Note that I would personally implement Stringies_IO a Functor over Stringies rather than having explicit dependencies. Jacques ___ 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] PLMMS - last call for papers
into full papers, to appear in a special issue of the Journal of Automated Reasoning. There will be a separate submission and review phase for this, where papers from both PLMMS 2007 and 2008 will be considered. Programme Committee --- Jacques Carette (Co-Chair) (McMaster University, Canada) John Harrison (Intel Corporation, USA) Hugo Herbelin (INRIA, Ecole polytechnique, France) James McKinna (Radboud University Nijmegen, Netherlands) Ulf Norell (Chalmers University, Sweden) Bill Page Christophe Raffalli(Universite de Savoie, France) Josef Urban(Charles University, Czech Republic) Stephen Watt (ORCCA, University of Western Ontario, Canada) Makarius Wenzel (Co-Chair) (Technische Universitaet Muenchen, Germany) Freek Wiedijk (Radboud University Nijmegen, Netherlands) Important Dates --- * Submission deadline - 5 May 2008 * Notification of acceptance - 6 June 2008 * Final version - 7 July 2008 (approximately) * Workshop - 28-29 July 2008 ___ 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
