Re: [Caml-list] Tuples (covariant immutable arrays)
type +'a t = (int - 'a) * int let get (a: 'a t) i = (fst a) i let length (a: 'a t) = snd a let of_array (a: 'a array) : 'a t = let a' = Array.copy a in (Array.get a', Array.length a') should be enough -- 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
Hi Diego. I think one of the best reason to *not* have let rec as the default is shadowing. Say you have a function that expect a string as an argument let foo s = and you realize that it's the job of the callee and not the caller to check that the string is escaped. You can just change it to: let foo s = let s = escape s in And before you say let's just do this for function and not for other values, let's remember that nothing separate a function from a value syntactically (it's a functional language, a function *is* a value), only typing can. And you can't type your program before you know its structure, and let vs let rec is part of the structure. Then on top of that we can add that it makes compilation faster, optimization easier, and code clearer (and, of course, backward compatibility :))! Cheers Alexandre On Mon, Jan 2, 2012 at 5:37 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] Re: New experimental ARM backend [was: OCaml maintenance status / community fork (again)]
Hi Benedikt On Sun, Dec 18, 2011 at 1:08 PM, Benedikt Meurer benedikt.meu...@googlemail.com wrote: [1] https://github.com/downloads/bmeurer/ocaml-arm/ocaml-arm-3.12.1+20111218-benchmark.pdf Could you by any chance give the execution time (one should be enough since we have the ratio) and measurement technique of your benchmarks? Thanks in advance Alexandre -- 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] OCaml maintenance status / community fork
Hi all, I will not jump in the how to save OCaml from dying because nothing moves discussion. But just in the nothing moves discussion. On Tue, Dec 6, 2011 at 2:52 PM, ivan chollet ivan.chol...@gmail.com wrote: The current status of OCaml is more than stable enough to serve its goals, which are to teach computer science to french undergrads and provide a playground for computer languages researchers. First, french undergrads sadly often still use camllight... Which is not the case for example of Harvard undergrad (http://www.seas.harvard.edu/courses/cs51/lectures.html) and some UPenn one (http://www.seas.upenn.edu/~cis341/). But you are right that I can't find any well known university out of France using OCaml to teach computer science... And for the computer languages researchers part, I'll refer you to http://caml.inria.fr/consortium/ A fork could possibly get traction from the community, but you would have to provide interesting features that the real OCaml does not provide. Bug fixes won't be enough. So now, here is my real problem. What are those famous so wanted feature that this fork will provide? And what makes you (a plural you) think that ocaml is such a slowly moving and evolving language? According to the caml web site, in the past two years, we've seen native dynlink, polymorphic recursion and first class module making there way into the language. According to what can be found on the trunk of the ocaml svn, the next release will have GADTs. And the compiler have also been modified to incorporate things like a nice multiprecision library (http://forge.ocamlcore.org/projects/zarith/) and some backends have been added. Except maybe haskell and Scala, can you really name me a programming language that in fact evolves that quickly, and basically without ever breaking backward compatibility? I really don't think that any of python, perl, java, C, C++ would really win. But I might be wrong. So before saying we need to fork the OCaml compiler to add much needed patches, it would be nice to minimally agree on witch patches are so much needed. Because if the community can't agree on this, I doubt the future of this potential fork will be so bright. My 2c. -- 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] Include question
On Tue, Nov 8, 2011 at 10:10 AM, Gabriel Scherer gabriel.sche...@gmail.com wrote: If you want some module of your system to be parametrized by another module (to be able to pass either a concrete module or a mockup module), you should use a functor. And if you don't want to pollute your entire code with functor when it's in fact for testing and not part of the logic of the application, you can use the functor of the poor: you put your net_lib.ml in a real_src sub directory, and the mockup net_lib.ml (same name) in mockup_src, and then you change wich subdir is in the path. Less pretty, but less invasive too! Other dirty option (yerk): you put your net_lib module in a reference over a first class module, and you dynamically change it to point to the mockup version when you want to test it (but this will probably not work in many situations, like with abstract types) -- 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] Priority queues
I have the impression that none of the proposed solution allows to increase/reduce the priority of an element, which is necessary for the Dijkstra. (But I don't know any that does) - Alexandre 2011/6/30 Michael Ekstrand mich...@elehack.net: On 06/30/2011 07:33 AM, Jean-Christophe Filliātre wrote: I have an implementation of priority queues on my web page: http://www.lri.fr/~filliatr/software.en.html Look for heap. Note that it contains 2 implementations: one imperative and one persistent. Help yourself I've used this heap implementation with good success. Batteries Included also contains a heap implementation (BatHeap) - if the OP is using Batteries, he can just use that heap as well. - Michael -- 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
