[Caml-list] [OSR] Standard syntax extensions ?
Dear list, Now that the forge is up, it's time to (re)start thinking about the OSR and what we want the future of the OCaml standard distribution to look like. Other threads will be (re)spawned regarding various aspects of that distribution, but for now, I'd like to discuss which syntax extensions. Oh, and before this thread diverges again, let me underline that we're *not* discussing delivery mechanisms or ocamlfind or ocamlbuild or repositories or GODI or IDisposable or camlp4 vs. camlp5... We're also not discussing original vs. revised syntax vs. twt [yet], although if you consider that some extension would be much more useful if rendered compatible with one of these syntaxes, please mention it. Now, a few subjects I'd like to see covered: * which syntax extensions do you use so often that you consider they should be part of the language ? * which syntax extensions are very important to you but should not be included in the core language [yet] ? * which syntax extensions are good ideas and should go into one of the previous categories but miss the mark because of dependencies / cosmetic issues and/or incompatibilities with other extensions or with the latest camlp4 ? * what kind of syntactic sugar is absolutely missing from the language ? As this may come into play later, whenever you suggest an extension, don't hesitate to comment whether you believe whom this extension would serve: beginners ? power-users ? some more specific category ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [OSR] Standard syntax extensions ?
The current plans are to have two sets of extensions inside Batteries Included: * a few will be opened by default * some others will just be part of the distribution, with instructions in a common format, regarding how to activate & use them In either case, we will probably have a slightly customized ocamlbuild which doesn't need special plug-ins for these extensions (that's part of Edgar's side of the work). Cheers, David On Fri, 2008-04-25 at 09:57 -0400, Peng Zang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 24 April 2008 01:05:44 pm Dario Teixeira wrote: > > Remember the recent thread about ocamlbuild+findlib+camlp4 and the OSR > > about standardising naming conventions for syntax extensions [1]. Using > > a special ocamlbuild plugin [2], the barrier to using syntax extensions > > is so low that you can almost consider them as standard language features. > > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [OSR] Standard syntax extensions ? - voting
Good idea. Would you handle this wiki ? Cheers, David On Fri, 2008-04-25 at 00:16 +0800, Stefano Zacchiroli wrote: > What about the following 2 phases: > 1) prepare a list of nominations, maybe as a page on cocanwiki > 2) vote on them using a Doodle poll -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [OSR] Standard syntax extensions ?
If you want to work on patching the compiler itself, please get in touch with Edgar Friendly. He's getting some work done on that side. I'm more interested in libraries and camlp4. Cheers, David On Thu, 2008-04-24 at 18:02 +0100, Jon Harrop wrote: > Agreed. There are some glaring omissions, like try..finally, but they should > be fixed properly in the compiler and not using camlp macros. > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [OSR] Standard syntax extensions ?
We can do that in OCaml, actually. I've seen at least three versions of this in the Net, one of them by me. Plus it also works with streams, arrays, etc. Cheers, David On Sat, 2008-04-26 at 14:32 -0700, Arthur Chan wrote: > The python syntax goes further than just the "in" bit, in fact. They > can do list comprehensions like [for x in blah if f(x)]. Now every > functional guru will recognize this immediately as the bastardization > of List.filter. While it'd be nice to have that, I come across > List.filter much less than List.exists/mem. > > Whatever it's just a minor quibble, but this thread was about > syntax extensions, after all. -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [OSR] Standard syntax extensions ?
I think this would be useful. However, you can already do it in a slightly more complex fashion. >From the top of my mind, with let ( /* ) f g = f g let ( */ ) f g x = g f x you can achieve 1 /* mem */ [1;2;3] with the added bonus that a C programmer will never be able to read your code :) Cheers, David On Sat, 2008-04-26 at 09:53 +0200, Till Crueger wrote: > I am posting this in this thread, because this would allow us to write the > above more elegantly as: > 1 `mem` [1;2;3], which is close to what was originally proposed. > > What do you think of this? > > bye, >Till > > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Invoking the standard library ?
Dear list, I'm currently working in a ExtLib-style context in which I'm extending modules String, Stream, etc. For this, I need to include the original module, as provided in the standard library, and add stuff. Now, the trick is that I'd like to keep the same name as the original module. So, in string.ml, I'd like to be able to write something along the lines of include Inria.String to access the contents of the usual String. Now, at the moment, to do that, I need to first create my own module Inria (which imports all the modules of the standard distribution), which then lets me proceed with this manipulation. Unfortunately, that's a bit clumsy, not to mention that I haven't found a nice way to get this all to build in one go with ocamlbuild. I'd like to know if there's a better mechanism. Thanks in advance, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Invoking the standard library ?
On Tue, 2008-04-29 at 20:07 +0100, David Allsopp wrote: > I don't quite following the motivation for needing module Inria: there's no > problem with writing: > > module String = struct > include String > (* Your functions here *) > end Doesn't work whenever the module is contained in its own file. (*File string.ml*) include String let _ = print_endline "Done" (*end of file string.ml*) $ ocamlbuild string.cmo Circular build detected (string.cmi already seen in [ string.cmi; string.cmo ]) Compilation unsuccessful after building 1 target (0 cached) in 00:00:00. $ ocamldep string.ml string.cmo: string.cmo string.cmx: string.cmx $ ocamlc string.ml File "string.ml", line 1, characters 8-14: Unbound module String etc. > but I think perhaps I've not understood the problem properly. That said, why > is defining module Inria clumsy? I copied the table of contents from the > StdLib page and with a couple of %s instructions got > > module Inria = > struct > module Arg = Arg > module Array = Array > (* 34 additional lines *) > module StringLabels = StringLabels > module Sys = Sys > end > > Which is exactly what you want, right? Auto-generating the module is not hard. It's getting everything to compile without having to hand-write a Makefile (e.g. with ocamlbuild). Indeed, module Inria depends on [the original] String, [the original] Sys, etc... and I wouldn't want ocamlbuild or ocamldep to decide compiling string.ml before inria.ml. Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Invoking the standard library ?
On Wed, 2008-04-30 at 09:05 +0900, Jacques Garrigue wrote: > This is a limitation of ocaml's mapping between file names and > modules: a program cannot contain two files with the same name. > Even if you somehow succeed in doing so by tricking the compiler, > you're on your way for lots of trouble. Yeah, that's what I'm realising at the moment. Even with my Inrialib.List, I end up with "inconsistent assumptions". > It has been discussed at times that putting the standard library in a > packed module would alleviate this problem. However, this would make > it monolithic, meaning that all programs would have to include all the > standard library. Would that change the final binary ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Documenting submodules ?
Dear list, As mentioned previously, I'm working on a derivative of ExtLib (promised, I'll submit the changes within a few days). I've put together most of the features I want for now, but I'm faced with a problem of documentation. Essentially, I have a few big modules containing each a few smaller modules -- each smaller module being defined in one file. When invoking ocamldoc, either directly or through ocamlbuild + .odocl, the generated documentation only contains the name of modules, without any of the comments or even the values. Is there any ocamldoc plug-in or ocamlbuild plug-in or anything else that could help me document my code without having to rewrite everything and/or to copy and paste thousands of lines of .mli ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Should a /\ operator be possible?
Actually, I remember Xavier Leroy saying that there was no problem, as soon as we were able to decide exactly what's a symbol, what's a letter, etc. Cheers, David > In fact can we open the discussion about converting OCaml source files > into UTF-8 and allow _lots_ more symbols? eg: > > let (∪) = ... > let (⊆) = ... > > Rich. > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Core has landed
We're integrating both Camomile and ExtLib (with shared UTF8 and UChar) in Batteries Included, if you're interested. Cheers, David On Sat, 2008-05-03 at 10:08 +0100, Richard Jones wrote: > Adding stuff to the extlib UTF8 module without having the > corresponding changes in Camomile is dangerous - the two cannot then > be used at the same time. This is really a problem with extlib, it > just shouldn't be distributing this module. > > In any case, why don't you just use Camomile? > > Rich. > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Documenting submodules ?
Let me rephrase:
Case 1)
sub.ml
(** This is [Sub] *)
type t
(** This is [Sub.t]*)
main.ml
module Sub = Sub
Running ocamldoc drops the comments of sub.ml .
Case 2)
sub.ml
module SubSub = struct
type t
(** This is [SubSub.t] *)
end
main.ml
module SubSubSub = Sub.SubSub
Running ocamlc drops the comments of sub.ml -- and the very existence of
SubSub.t.
Cheers,
David
On Mon, 2008-05-05 at 10:11 +0200, Julien Signoles wrote:
> > When invoking ocamldoc, either directly or through ocamlbuild + .odocl,
> > the generated documentation only contains the name of modules, without
> > any of the comments or even the values.
>
> Usually ocamldoc works fine with submodule:
>
> = sub.ml
> (** This is {!A}. It contains a properly-documented submodule {!A.B} and a
> single value {!A.a}. *)
> module A = struct
>
>(** This is {!B}. It contains a single value {!B.b}. *)
>module B = struct let b = 1 end
>
>let a = 0
>
> end
> =
>
> $ ocamldoc -version
> Ocamldoc 3.10.1
> $ ocamldoc -html sub.ml
>
> Hope this helps,
> Julien Signoles
>
--
David Teller
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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] Documenting submodules ?
On Mon, 2008-05-05 at 10:35 +0200, Maxence Guesdon wrote: > Indeed, ocamldoc does not use the comment of sub.ml in the page generated > for main.ml. This is normal behaviour. I'm aware that it's the normal behaviour of ocamldoc. I'm just looking for a work-around or a plug-in. > You could comment the creation of the > Sub module (i.e. Main.Sub) by putting a comment around > module Sub = Sub I wrote that in my first post :) More seriously, it's ok if I have only one or two modules. But if I want to comment both the creation of Sub and the actual contents of Sub, it's not really a good method. Even more so since I have 70+ modules developed separately, which I attempt to present with a consistent Java-style package hierarchy. That would mean copying and pasting about 9000+ lines of code for the moment, with more coming, and nasty bugs lurking whenever the source packages are updated. > This is normal behaviour too. You're redefining a module here, and the > way it is defined is reflected by the html code generated by ocamldoc, with > a link on the Sub.SubSub page. I have a link to an empty Sub.SubSub page. Is that normal behaviour ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Why OCaml rocks
On Fri, 2008-05-09 at 01:39 +0100, Jon Harrop wrote: > 1. Lack of Parallelism: Yes, this is already a complete show stopper. Agreed. > 2. Printf: I think > printf is one of the reasons OCaml dominates over languages like Haskell and > SML. I'm not sure about "dominate", but yes, it's definitely one reason why I code in OCaml rather than Haskell. > 5. Strings: pushing unicode throughout a general purpose language is a > mistake, IMHO. This is why languages like Java and C# are so slow. We have a good Unicode library (see Camomile), good ropes libraries (see Community Caml) and someone is bound to write a syntax extension to provide a natural syntax for Rope literal constants. > 6. Shift-reduce conflicts: although there as aspects of OCaml's syntax that I > would like to tweak (e.g. adding an optional "end" after a "match" > or "function" to make them easier to nest), I am not bother about the > shift-reduce conflicts. Mainstream languages get by with far more serious > syntactic issues (like <<...>> in C++). That's something we may need to discuss at some point. I would really like the ability to write match a with ( | bla | bla | bla ) > 7. Not_found: I like this, and Exit and Invalid_argument. Brian's point that > the name of this exception does not convey its source is fallacious: that's > what exception traces are for. I personally prefer ExtLib's approach of redefining exceptions per-module. > 8. Exceptions: I love OCaml's extremely fast exception handling (6x faster > than C++, 30x faster than Java and 600x faster than C#/F#!). Yep. > 9. Deforestation: Brian says "Haskell has introduced a very interesting and > (to my knowledge) unique layer of optimization, called deforrestation". True, > of course, but useless theoretical piffle because we know that Haskell is > slow in practice and prohibitively difficult to optimize to-boot. Deforesting > is really easy to do by hand. Are you sure or is that just a troll ? Supero seems to improve enormously Haskell's performances and the Shootout already shows Haskell beating OCaml in several tests. > 10. Limited standard library: I agree but this is only an issue because we > are > not able to fix the problem by contributing to the OCaml distribution. That's the whole idea of Community Caml / Batteries Included. Really, feel free to contribute. > . Pattern matching over lazy values. Have you looked at the Patterns project on Google ? It provides pattern-matching over lazy values. I've used it in conjunction with my own lazy list module [1] to port Graham Hutton's Countdown problem from Haskell, and it works. > I believe these can be fixed by creating a new open source functional > language > for Linux based upon LLVM. However, the lack of a suitable GC is a complete > show stopper. The JVM is the only thing that comes close and it is unable to > support tail calls without a catastrophic performance cost, i.e. so bad that > you might as well write an interpreter. Why a full new language ? I may understand the interest of writing a new compiler for OCaml (or whichever other language) and gradually improving the forked compiler, but that's a different story altogether. Cheers, David [1] https://forge.ocamlcore.org/frs/shownotes.php?release_id=12 -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Why OCaml rocks
You can try and take a look at Zheng Li's SDFlow. In particular, functions switchn and farm. Cheers, David On Fri, 2008-05-09 at 13:58 +0200, Gabriel Kerneis wrote: > Do you have any pointer on multiplexing (or some piece of code you could > show)? This seems interesting but I can't figure out what it looks like. > > Thanks, -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Why OCaml rocks
For information, Batteries Included offers for each module an
ExceptionLess submodule, which redefines exception-throwing functions as
returning either an 'a option or, for more details, an ('a, 'b) result.
A Result module complements this with monadic operations for whoever is
interested.
Cheers,
David
On Fri, 2008-05-09 at 07:37 -0400, Ralph Douglass wrote:
> Not_found and Failure _ can be a bit annoying to watch for, so I
> suggest using Core. The default behavior for most functions is to
> return an option instead of raising an exception. There are _exn
> versions of the functions if you want exceptions.
--
David Teller
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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: Why OCaml rocks
On Fri, 2008-05-09 at 11:29 +0100, Jon Harrop wrote: > On Friday 09 May 2008 08:58:26 you wrote: > > Are you sure or is that just a troll? > > My point is that actual performance on real code is what matters and not the > number of optimizations that might theoretically apply. From the measurements > I have seen and done, Haskell is substantially slower despite its many extra > optimizations. Ok, I'll take your word on that. > > > 10. Limited standard library: I agree but this is only an issue because > > > we are not able to fix the problem by contributing to the OCaml > > > distribution. > > > > That's the whole idea of Community Caml / Batteries Included. Really, feel > > free to contribute. > > I thought Community OCaml was about tacking things on externally using macros > and extra libraries. Yes and no. * Batteries Included = ** take the legacy standard library, ExtLib, Camomile, SDFlow and other libraries (list undecided so far, but pcre, ocamlnet, camlzip are strong candidates), add some glue to get them all to work together, and build a comprehensive external library ** do the same thing for macros ** distribute everything as a GODI package with lots of dependencies * Community OCaml = use the same codebase but ** completely replace the legacy standard library ** turn this into a full, community-maintained, OCaml distribution. In either case, the objective is to achieve something JDK-like in its reach. > > Why a full new language? I may understand the interest of writing a > new > > compiler for OCaml (or whichever other language) and gradually > improving > > the forked compiler, but that's a different story altogether. > > A concurrent GC is the only major issue. Everything else is > comparatively > easy. Well, if you get to write a concurrent GC for the core of OCaml, feel free to alert the community. People might be willing to help with advanced features. Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Why OCaml **cks
On Fri, 2008-05-09 at 23:01 +0100, Vincent Hanquez wrote: > On Fri, May 09, 2008 at 11:23:50AM +0100, Jon Harrop wrote: > > > have you been hiding in a cave lately? > > > > With yo mamma. > > this actually sum up your posts and the idea contains in them pretty well. Please stop that. Both of you. -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Why OCaml rocks
On Fri, 2008-05-09 at 19:10 +0100, Jon Harrop wrote: > Parallelism is easy in F#. Now, that's a cliffhanger. Could you elaborate ? Cheers, David > > I think that the cost of copying data is totally overrated. We are doing > > this often, and even over the network, and hey, we are breaking every > > speed limit. > > You cannot afford to pay that price for parallel implementations of most > numerical algorithms. Er... Not being a specialist, I may be wrong, but I seem to remember that you can afford that, as long as you're also doing something else during that copy. > On the contrary, that is not a theoretical statement at all: it > already > happened. F# already makes it much easier to write high performance > parallel > algorithms and its concurrent GC is the crux of that capability. Examples ? Pretty please ? Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Where's my non-classical shared memory concurrency technology?
IIRC, there are already type systems which may prevent deadlocks in pi-calculus. And since pi-calculus is essentially the base for CML/OCaml's Event/lwt (I'm not 100% sure for lwt), my guess is that it shouldn't be too hard to get them to work for purely functional threaded code. The missing step would be to detect whether code is purely functional, which is a rather easy task (if tedious). The alternative to that missing step would be to detect whether impurities are localized to each thread -- something which I believe would also be quite feasible, provided you limit side-effects to the use of a well-defined, thread-local, API. Cheers, David On Tue, 2008-05-20 at 00:24 +0200, Berke Durak wrote: > Given that shared, mutable global state accessed with multiple threads > is a recipe for bugs that no amount of data hiding can solve (because > -locking-sections-don't-compose-), > did anyone invent and implement a usable type or other system for > making concurrency > and parallelism safe? > > If the answer is STM, please show me some non-trivial application that > uses it, preferably > in an impure language. -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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 variant as a witness?
Dear list, I have been thinking for some time about using polymorphic variants to encode some aspects of a types-and-effects type system in OCaml using Camlp4. While the idea is still quite fuzzy, I have the feeling that, if I could have a value (let's call it "witness") with type [> ] ref which I could "touch" into becoming [> `A] ref then [> `A | `B] ref etc. as effects `A, `B, etc. appear in the program, it could provide interesting information on the effects of the program. Now, of course, I can't define a value with type ref [> ] or even with type ref [> `dummy]. That is, when compiling a module consisting only in a declaration such as let witness = ref `dummy I'm faced with the good old "cannot be generalised" error message. This strikes me as normal -- I'm sure that, with the right modifications on witness, I could cause runtime type inconsistencies for any client attempting to read the value of witness. However, in this case, I'm not going to read any value from witness, ever. I only want to "touch" it into becoming something a tad more complex, which I could then look at with ocamlc -i or such. My question is: is there a way to hijack polymorphic variants into doing what I wish? Or to encode this behaviour somehow? Thanks, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] cost of monads
If you're interested, I'm currently putting the last touch on a paper dealing with monads in OCaml -- including some benchmarks. I'll share the data once I'm done with the writing. Cheers, David On Sat, 2008-06-21 at 11:23 -0700, Warren Harris wrote: > I'm considering writing a moderate sized program with high performance > needs in a monad / monad transformer style in ocaml. Although I > believe that this abstraction will offer me benefits in hiding some > complexity, some of the monad transformers I would like to "stack" are > quite simple (e.g. a state-transition monad), and I'm concerned that > my program will be paying a high performance cost due to high function > call overhead -- ones which cannot be optimized away due to module > boundaries. > > I know that the real answer here is "profile it and find out"... but I > thought that asking for other's experience might be a good first step. > Perhaps someone can offer a technique to make this work well, or a > word of caution on why this should be avoided. I realize that most of > the monad work happens in haskell (and I sometimes feel that I'm > reinventing the wheel -- although it's very educational!), but I'd > prefer to stick with ocaml if possible. > > Warren > -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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 variant as a witness?
On Sun, 2008-06-22 at 01:27 +0200, Christophe TROESTLER wrote: > On Sun, 22 Jun 2008 01:11:59 +0200, David Teller wrote: > > > > I could have a value (let's call it "witness") with type > > [> ] ref > > Why do you want it to be mutable? Because I know how to change the type of a reference to a polymorphic variant (the touching) -- but not the type of an immutable polymorphic variant. > > which I could "touch" into becoming > > [> `A] ref > > Are you expecting to write [touch `A witness] so [witness] becomes of > type [[> `A] ref]? If you can do with an immutable [witness], then > you can write a macro to that effet (use: [let witness' = TOUCH `A > witness]). What exactly is your purpose? Say you are developing a Camlp4-based DSL in which * file access may only be performed by some construction -- let's call it FILE * network access may only be performed by some construction -- let's call it NET. I'd like to take advantage of OCaml's type system to tell me if file access and/or network access have taken place. Now, since I'm implementing FILE and NET from within Camlp4, I can give them whichever semantics I want. For instance, FILE could mean [touch `File witness; foo] and NET could mean [touch `Net witness; bar]. If I write a program containing FILE, OCaml's type system will have inferred that the type of [witness] is [[> `File]]. Which would be great for me. Now I know I could do that with monads. I could also implement a type system for the DSL. I'm just wondering if polymorphic variants could provide an alternative. Because if they can, it may have direct applications to exception management for OCaml. > Regards, > C. Cheers, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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 variant as a witness?
On Mon, 2008-06-23 at 19:27 +0900, Jacques Garrigue wrote: > From: David Teller <[EMAIL PROTECTED]> > * first remark: ocamlc -i works even with non-generalizable types, as > it does not generate any .cmi. Interesting. I'm not sure it's usable in my case, but it's interesting. > * if you want to be still able to compile, you can write a .mli file > not including the witness. ocamlc -i on the .ml will still show you > the witness. Also a good idea. Also possibly unusable in my case, but I'll need to think about it further. > * other solution: put everything inside a function, so that the > type variable is still generalizable after typing the function. In that case, the witness remains invisible, doesn't it? Thanks, David -- David Teller Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Got GMP?
Under Debian/Ubuntu, it's libgmp-ocaml . I don't see any GODI package, though. Cheers, David On Tue, 2008-07-22 at 14:47 -0700, Shivkumar Chandrasekaran wrote: > Hi, > > Does anybody have an ocaml interface to GMP (Gnu Multi-Precision > library)? Thanks, > > --shiv-- -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Haskell vs OCaml
I'm not sure there's confluence if you factor in the resources required for such reduction, though. On Thu, 2008-08-21 at 10:47 +0200, DooMeeR wrote: > > What are the advantages/disadvantages when comparing a fork to a spoon? > > From Church's thesis, one can easily answer this question: they are > equivalent. > > The reduction is quite easy. A fork can be reduced to a spoon using a > fire, an anvil and a hammer, and a spoon can be reduced to a fork using > a saw. > > Hope this helps. > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Run-time evaluation of a Printf format string
As you may have seen in Pervasives.ml, format6 and string are actually
the same thing. Which means that you can Obj.magic your way around the
problem (gasp!) -- provided you have already checked manually that the
string actually represents the format you're interested in.
Of course, that's a tad risky. If I were you, I'd rather re-implement a
small unparsing language with a format comparable to printf's and a tiny
parser to go with it.
Does this help?
Cheers,
David
P.S.:
If you're interested, I've put together a little bit of documentation
on format* which I think can't be found in OCaml's doc [1]. Look for
"{7 Format4}" in the comments.
[1]
https://forge.ocamlcore.org/plugins/scmsvn/viewcvs.php/trunk/extlib/IO.mli?rev=23&root=batteries&view=auto
On Thu, 2008-08-28 at 15:37 +0200, Jan Kybic wrote:
> Hello,
> I would need an equivalent of Printf.sprintf where the
> format string is not constant, it is read from the command line.
> The motivation is to let the user specify a template for file names,
> such as "img%03d.png". Can this be achieved in Ocaml? It seems not, as
> Pervasives.string_of_format only accepts constant strings.
> Or is there some external library useful for this task?
>
> For the moment I have started to implement it myself for the limited
> set of format specifications I will need but if there is some more
> elegant solution I would be interested to hear about it.
>
> Thanks,
>
> Jan
>
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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] ANN: Batteries Included Release 0
Dear list, I'm happy to announce the availability of a preview release of Batteries Included. Batteries Included is a candidate standard development platform for OCaml. For this release 0, Batteries only gives access to the OCaml base library and to ExtLib. Future versions will add access to other libraries. Our final objective is to obtain a platform containing all the tools necessary for most common tasks, from data structures to XML to user interfaces to network access. More details on the blog [1]. The code may be found on OCamlForge [2]. A GODI package is being prepared. Suggestions and discussions on this mailing-list are heartily welcome. Cheers, David [1] http://dutherenverseauborddelatable.wordpress.com/2008/08/29/ocaml-batteries-included-release-0-where-it-should-all-have-begun/ [2] http://forge.ocamlcore.org/frs/?group_id=17&release_id=41 -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] ANN: Batteries Included Release 0
Auto-generated documentation has just been uploaded [3]. As you may see, the default presentation of OCamlDoc is possibly not quite what we need. If you wish to help us develop a nice OCamlDoc plug-in to obtain something more readable, please contact us. Cheers, David [3] http://forge.ocamlcore.org/docman/index.php?group_id=17&selected_doc_group_id=49&language_id=1 On Sat, 2008-08-30 at 11:37 +0200, David Teller wrote: > More details on the blog [1]. The code may be found on OCamlForge [2]. A > GODI package is being prepared. Suggestions and discussions on this > mailing-list are heartily welcome. > > Cheers, > David > > [1] > http://dutherenverseauborddelatable.wordpress.com/2008/08/29/ocaml-batteries-included-release-0-where-it-should-all-have-begun/ > > [2] http://forge.ocamlcore.org/frs/?group_id=17&release_id=41 > > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] `This expression is not a function it cannot be applied'
Or you can use ExtLib's enumerations for the purpose of abstraction.
That's what I'm doing in my parser combinator library.
Cheers,
David
On Tue, 2008-09-02 at 10:34 +0200, blue storm wrote:
> On Tue, Sep 2, 2008 at 10:26 AM, David Baelde <[EMAIL PROTECTED]> wrote:
> > This amouns to provide a cast from the abstract type to the function
> > type, while keeping the liberty on how it's implemented.
>
> If you want even more implementation liberty, you should consider
> making the internal "token collection" type abstract : you use a list
> for now, but might want to use Streams or lazy lists or what not
> someday.
>
> That would give something like that :
> module Parser : sig
> type ('a,'tok) t
> type 'tok input
> val token : ('tok -> 'a option) -> ('a,'tok) t
> val apply : ('a,'tok) t -> 'tok input -> ('a * 'tok input)
> val input_of_list : 'tok list -> 'tok input
> end = [...]
>
> ___
> 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
>
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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] Two questions on OCamlDoc
Hi everyone, I'm currently toying with OCamlDoc, with very little success. I'm attempting to do two things: * getting OCamlDoc to understand that some modules (which I can modify) contain the documentation for some other modules (which I can't) replace some modules with others * inlining the documentation for modules in modules which import those. I need a little help. Let me detail this. *** Documentation replacement *** My project uses modules M_lib1, M_lib2... which come from a variety of libraries. For each of these modules, I have created a module M_lib1_with_doc, M_lib2_with_doc, which imports the corresponding library module but tailors the documentation to my project. However, for technical reasons of mechanical generation, assuming that M_lib1 refers to M_lib2, M_lib1_with_doc still refers to M_lib2 instead of referring to M_lib2_with_doc. Consequently, when generating the documentation of M_lib1_with_doc, ocamldoc doesn't link the generated pages to the documentation of M_lib2_with_doc but rather attempts to link it to M_lib2 (and fails, as expected). Now, I could rework the mechanical generation of my modules and in time, I will. However, for the moment, I'm looking for a purely OCamlDoc-based solution. I'd like to be able to ask OCamlDoc to please consider every reference to M_lib2 as actually meaning a reference to M_lib2_with_doc. I have tried to override method [text#html_of_Ref], without much success. Is there a simple solution for this? *** Inlining modules *** I have a few modules whose sole role is to include one or two existing modules. By default, when meeting [include], OCamlDoc, ocamldoc only generates a link from the container module to the inlined module. In this case, I'd rather want the whole documentation of each of these modules to be inlined. Is that possible? Thanks in advance, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Two questions on OCamlDoc
And while I'm asking complex questions, can anyone think of a way of asking OCamlDoc to resolve [string] to [String.t], ['a list] to ['a List.t], ['a array] to ['a Array.t], etc? Thanks, David On Tue, 2008-09-02 at 13:47 +0200, David Teller wrote: > Hi everyone, > > I'm currently toying with OCamlDoc, with very little success. I'm > attempting to do two things: > * getting OCamlDoc to understand that some modules (which I can modify) > contain the documentation for some other modules (which I can't) replace > some modules with others > * inlining the documentation for modules in modules which import those. > > I need a little help. > > Let me detail this. > > *** Documentation replacement *** > My project uses modules M_lib1, M_lib2... which come from a variety of > libraries. For each of these modules, I have created a module > M_lib1_with_doc, M_lib2_with_doc, which imports the corresponding > library module but tailors the documentation to my project. However, for > technical reasons of mechanical generation, assuming that M_lib1 refers > to M_lib2, M_lib1_with_doc still refers to M_lib2 instead of referring > to M_lib2_with_doc. Consequently, when generating the documentation of > M_lib1_with_doc, ocamldoc doesn't link the generated pages to the > documentation of M_lib2_with_doc but rather attempts to link it to > M_lib2 (and fails, as expected). > > Now, I could rework the mechanical generation of my modules and in time, > I will. However, for the moment, I'm looking for a purely OCamlDoc-based > solution. I'd like to be able to ask OCamlDoc to please consider every > reference to M_lib2 as actually meaning a reference to M_lib2_with_doc. > > I have tried to override method [text#html_of_Ref], without much > success. Is there a simple solution for this? > > *** Inlining modules *** > I have a few modules whose sole role is to include one or two existing > modules. By default, when meeting [include], OCamlDoc, ocamldoc only > generates a link from the container module to the inlined module. In > this case, I'd rather want the whole documentation of each of these > modules to be inlined. > > Is that possible? > > Thanks in advance, > David > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Another question on OcamlDoc
According to the documentation, ocamlfind can manage that. Cheers, David On Tue, 2008-09-02 at 14:48 +0200, Jan Kybic wrote: >- how can I tell OcamlDoc to run a preprocessor on the file first? > (I am using ocaml+twt) -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Two questions on OCamlDoc
Okay, I've found the solution to most of my problems, thanks to Maxence. The code will be committed soon to the Batteries repository if anyone is interested. I have one more question, though: assuming that I have a reference to a [t_module] for a module with both a [.mli] and a [.ml], is there a simple way to access the underlying implementation without having to reparse [m_code]? Thanks, David On Tue, 2008-09-02 at 13:47 +0200, David Teller wrote: > Hi everyone, > > I'm currently toying with OCamlDoc, with very little success. I'm > attempting to do two things: > * getting OCamlDoc to understand that some modules (which I can modify) > contain the documentation for some other modules (which I can't) replace > some modules with others > * inlining the documentation for modules in modules which import those. -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Two questions on OCamlDoc
I'm doing some pre-treatment on the module structure before actually generating documentation. In particular, I'd like to be able to find out if the .ml contains an inclusion of some given module -- even if there is a .mli -- as this will change the resulting structure. Is there a way to do such a thing? Thanks, David On Fri, 2008-09-05 at 14:03 +0200, Maxence Guesdon wrote: > What do you mean by access ? do you want a link to a html page of the code ? > And what do you mean by "reparse the [m_code]" ? > > Regards, > > Maxence > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Two questions on OCamlDoc
Let me rephrase: I'm doing that pre-treatment from inside ocamldoc. Therefore, I don't think that running ocamldoc from ocamldoc is an option. Now, perhaps I should try and access data visible to Odoc_cross or Odoc_analyse? Cheers, David On Fri, 2008-09-05 at 14:37 +0200, Maxence Guesdon wrote: > On Fri, 05 Sep 2008 14:33:43 +0200 > David Teller <[EMAIL PROTECTED]> wrote: > > > I'm doing some pre-treatment on the module structure before actually > > generating documentation. In particular, I'd like to be able to find out > > if the .ml contains an inclusion of some given module -- even if there > > is a .mli -- as this will change the resulting structure. > > > > Is there a way to do such a thing? > > You may use ocamldoc on your .ml file and look if it contains a > Element_included_module refering to some given module. > > Does it help ? > > Regards, > > Maxence > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [ANN] Batteries Included documentation, updated preview
Dear list, We're happy to announce a new version of the API documentation, available at https://forge.ocamlcore.org/docman/index.php?group_id=17&selected_doc_group_id=49&language_id=1 . It's still a preview, but a much more readable one than what we had provided so far. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Replacing Pervasives?
Dear list, Does anyone know how I can get a module to be auto-opened by the compiler, in the same vein as Pervasives? I would very much prefer not having to tweak around the source code of ocamlc for this purpose. Thanks, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Replacing Pervasives?
Would that open anything by default? On Mon, 2008-09-08 at 12:04 +0200, Romain Bardou wrote: > I guess you could try and make your own stdlib directory, and then > call > ocamlc using: > > ocamlc -nostdlib -I mystdlib > > or something like that... > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Replacing Pervasives?
Technically, I guess I can write a Camlp4 extension just to add "open Foo" at the beginning of every file, but it seems a bit complex for such a simple task. Any other idea? Thanks, David On Mon, 2008-09-08 at 10:06 +0200, David Teller wrote: > Dear list, > > Does anyone know how I can get a module to be auto-opened by the > compiler, in the same vein as Pervasives? I would very much prefer not > having to tweak around the source code of ocamlc for this purpose. > > Thanks, > David > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Replacing Pervasives?
On Mon, 2008-09-08 at 17:06 +0200, Romain Bardou wrote: > In other word it's as if you changed your "official" > stdlib/Pervasives.cmo except that it's cleanier as you don't actually > override it (which would change your Pervasives for all your projects). > > I didn't try it though, so maybe I'm missing something. Well, I did :) Technically, it fails because you have to name your new module Pervasives and thus cause a conflict with the original Pervasives. > Basically, just use any hack which can replace your ocamlc by a script > which adds "open Myperv;;\n" before calling ocamlc ^^ Yes, that's the kind of things I have in mind. Unfortunately, it seems that ocamlc only supports one "-pp" tag. So if I use a simple "-pp 'cat myprefix.ml'", I become incompatible with Camlp4 :/ Any other idea? Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Camlp4. print variable value to target source.
On Thu, 2008-09-11 at 14:16 +0400, Сергей Плаксин wrote: > Exitst any way to do such things? > > -- > let t = <:ctyp> in > <:str_item> > > || > - > let t = Ast.TyId (_loc, Ast.IdLid (_loc, "int")); > - That doesn't look correctly typed. However, you can try replacing ?contents of t here? with $t$. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] thousands of CPU cores
On Mon, 2008-09-22 at 20:03 +0100, Jon Harrop wrote: > Sure thing. I wrote to the guys doing this work a couple of times and they > were very friendly. Apparently they are currently ironing out the last of the > bugs before going public. > > I don't think I am the only person struggling to contain my excitement. :-) * *_o/ |/ / 'nuff said -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Teaching ocaml programming
After teaching OCaml for two years, I personally suggest * Ubuntu + GODI * Emacs + Emacs-goodies (slightly customised to obtain tabs, I can send you my .emacs) + Tuareg -- (Emacs is much better than XEmacs, at least for this -- and the tabs are a tremendous help) * OcamlBuild with a myocamlbuild.ml written by you. Cheers, David On Fri, 2008-09-26 at 13:30 +0200, Andrej Bauer wrote: > Once again I am teaching a course on theory of programming languages in > which we will use ocaml to implement mini-languages. And once again I > face the question: which programming environment should we use? > > I have so far tried to use (under Windows) > 1. cygwin + ocaml + XEmacs > 2. Eclipse + OcaIDE > > The second solution worked better than the first, for the simple reason > that XEmacs is a complete mystery to students. They really, really hate > it. But even with the second soltion we had a lot of trouble, because > Eclipse is really complicated, and OcaIDE is sort of experimental and > not so good under Windows, so the whole setup was confusing and fragile. > > The requirements are very simple: > 1. easy access to toplevel (with line-editing) > 2. editor which can send stuff to toplevel, points to errors in source > code, and is not Emacs. > > Any ideas what to do? We have dual-boot machines (Windows + Ubuntu). > > Best regards, > > Andrej > > ___ > 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 > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Teaching ocaml programming
Camelia worked rather nicely for me under Windows. The required setup was not quite compatible with my needs, though, so I dropped it. Cheers, David On Fri, 2008-09-26 at 14:41 +0200, Andrej Bauer wrote: > How can there be no easy to use interface?! This is pathetic. > > Python has IDLE. Scheme has drscheme. Java has drjava. What does Haskell > have? > > I compiled Camelia (which required me to debug C++ code for the first > time in about 20 years). It's kind of ok. The user interface is a bit > broken, lots of uneccessary pop-up dialogs (e.g., for every error message). > > Andrej -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] embedding ocaml into a windows app: need gcc?
I don't know if this answers your question, but OCaml 3 now has Dynlink, i.e. a manner of dynamically loading OCaml modules from OCaml. So if you manage to get your code compiled at run-time, it shouldn't be too hard to load it. Cheers, David On Sat, 2008-09-27 at 20:27 +0100, Joel Reymont wrote: > Ideally, I would like to generate OCaml code at runtime and compile it > into something that can be loaded by a runtime of some sort. > > Compiling into a DLL would be ideal, is it possible? > > Are there are other options? -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: [ANN] ocamlbuild-ctools and symbiosis meta build engine
On Sun, 2008-09-28 at 18:39 +0200, Mikkel Fahnøe Jørgensen wrote: > 2008/9/27 Mikkel Fahnøe Jørgensen <[EMAIL PROTECTED]>: > This means developers can download a > prebuilt Symbiosis executable and a standard configuration file to > their local machine from a project file server and basically have a > build going by typing: > > symbiosis "myproject" > > This assumes available components are listed in proxy files in a > dedicated repository that the config files can identify. > > > I hope to put up an example project eventually, but at least you have > the source code now. Symbiosis looks quite interesting. I'm really looking forward to seeing an example project! Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] OCamlBuild question
Hi everyone, I'm trying to write a OCamlBuild plug-in to automatically generate the .mli corresponding to a .mlpack (for documentation purposes). I've written a [rule] which lets me depend a .mli on the corresponding .mlpack . From this .mlpack, I can obtain the list of modules involved in the construction of the pack. Now, I only have to 1. find the corresponding source .mli files 2. find the corresponding .mli.depends files 3. do a topological sort and create the destination .mli . Part 3 is no problem. On the other hand, I haven't been able to progress much with parts 1 and 2. Part 2 requires waiting until the corresponding .mli.depends have been created, but * neither [~insert:`bottom] nor [~insert:(`after foo)] seem to help here * attempting to [build] an ad-hoc list of files somehow extracted from the mlpack only gives me dependency errors * attempting [Solve.solve_target] doesn't seem to help any further. As for part 1, it requires the ability to find which source .ml / .mli correspond to a given module. I can only assume OCamlBuild offers some kind of API for this purpose, because I'd rather avoid folding through the whole tree, resolving [include] directives myself to find a .ml or a .mli which may be the right file. Does anyone have suggestions? Thanks, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: OCamlBuild question
Merci, avec ces explications, je suis enfin arrivé à faire fonctionner [build]. Maintenant, reste un problème tout bête : j'arrive à écrire le contenu de mon .mli dans _build mais pour des raisons qui m'échappent, celui-ci est effacé avant la fin de la compilation. J'ai essayé de l'ouvrir avec [open_out] et avec [with_output_file], avec le même résultat. C'est assez frustrant. Des idées ? Merci, David On Tue, 2008-09-30 at 12:40 +0200, Nicolas Pouillard wrote: > If you need (depend) on files that you statically know then the ~deps argument > is fine (~deps:["%.mli.depends"; "%.mli"]). If you need files that you only > know dynamically then the 'build' argument function is for that purpose. > > > As for part 1, it requires the ability to find which source .ml / .mli > > correspond to a given module. I can only assume OCamlBuild offers some > > kind of API for this purpose, because I'd rather avoid folding through > > the whole tree, resolving [include] directives myself to find a .ml or > > a .mli which may be the right file. > > Yes the function is called expand_module it takes 3 arguments, the include > directories, the module name, the extensions. > >Example: let include_dirs = Pathname.include_dirs_of (Pathname.dirname > mlpack) > in build (expand_module include_dirs module_name ["mli"; > "mli.depends"]) > > Have a look to the ocamlbuild/ocaml_tools.ml file for a similar function > (import_mlypack). > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: OCamlBuild question
Merci, avec ces explications, je suis enfin arrivé à faire fonctionner [build]. Maintenant, reste un problème que je n'arrive pas à comprendre : mon fichier disparaît. Pour être plus précis, j'écris le contenu de mon .mli dans un fichier que j'ai créé pour l'occasion, à l'intérieur de _build -- mais pour des raisons qui m'échappent, ocamlbuild trouve moyen de l'effacer avant la fin de la compilation. J'ai vérifié, une fois que j'ai écrit mon fichier, il existe bien. J'ai aussi vérifié, si je place mon fichier dans /tmp au lieu de _build, ça marche. J'ai aussi vérifié, si je remplace l'extension de mon .mli par .mlpack.mli, ça ne change rien. J'ai essayé de l'ouvrir avec [open_out] et avec [with_output_file], avec la même absence de résultats. Ah, et pour compliquer les choses, ça ne marche pas quand j'appelle ocamlbuild une seule fois. Mais il arrive que, si j'invoque ocamlbuild deux fois de suite, ça se mette à marcher. C'est assez frustrant. Des idées ? Merci, David On Tue, 2008-09-30 at 12:40 +0200, Nicolas Pouillard wrote: > If you need (depend) on files that you statically know then the ~deps argument > is fine (~deps:["%.mli.depends"; "%.mli"]). If you need files that you only > know dynamically then the 'build' argument function is for that purpose. > > > As for part 1, it requires the ability to find which source .ml / .mli > > correspond to a given module. I can only assume OCamlBuild offers some > > kind of API for this purpose, because I'd rather avoid folding through > > the whole tree, resolving [include] directives myself to find a .ml or > > a .mli which may be the right file. > > Yes the function is called expand_module it takes 3 arguments, the include > directories, the module name, the extensions. > >Example: let include_dirs = Pathname.include_dirs_of (Pathname.dirname > mlpack) > in build (expand_module include_dirs module_name ["mli"; > "mli.depends"]) > > Have a look to the ocamlbuild/ocaml_tools.ml file for a similar function > (import_mlypack). > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Metaprogramming features
Gasp, lobbying on this list ? :) I strongly agree with that feature request. One reason is all the code which is currently in Camlp4 but actually deserves the MetaOCaml treatment. The other reason is that I believe that the Haskell vs. OCaml race matters. Cheers, David On Fri, 2008-10-03 at 10:34 -0400, Jacques Carette wrote: > 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 -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] - Convert Caml to C/C++, C#, PHP, etc -
Shouldn't you rather look for bindings from OCaml to these languages? Cheers, David On Thu, 2008-10-02 at 22:33 -0700, axllaruse wrote: > I would like to convert all the MTASC open source project to C/C++ or PHP. -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] 'Compiler' module (was: embedding ocaml into a windows app: need gcc?)
Have you looked at the CDK's DynEval? Other than that, it's the kind of thing we'd like to put in Batteries, so if you write/find a better solution, please make it public. Cheers, David On Fri, 2008-10-03 at 22:34 +0100, Dawid Toton wrote: > > I would like an OCaml support library that can compile and execute > > similar to JaveScript engines, but we don't have that in any practical > > form. > > > > I also need this and I'm thinking about something like this: > > module type Compiler = > sig > val parse : Context.t -> string -> (Context.t * AST.t) > val get_type : Context.t -> AST.t -> Type.t; > val eval : Context.t -> AST.t -> Context.t * (Type.t * > MarshalledValueOrSomething.t) > end > > Is it really so hard to have it in OCaml? I'm envy of Python's Compiler > module. -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Metaprogramming features
On Sat, 2008-10-04 at 03:00 +0100, Jon Harrop wrote: > 1. Obvious applications are low-level compilers for regular expressions, > parsers and bytecodes but MetaOCaml imposes the limitations of OCaml (e.g. > slow char and int handling) which makes it unsuitable for most such > applications. Oh, well, you answer some of your own question from your other post. I was thinking along the lines of ulex. And I have the impression you can get a nice "finally" with MetaOCaml, albeit perhaps with a weird syntax. Now, another obvious application is writing efficient trampoline code and other combinators, something which I believe may be very useful for concurrency. > 3. You cannot generate new pattern matches to leverage OCaml's optimizing > pattern match compiler in your run-time generated code (but you can use > static ones). You can't? Well, that's unfortunate. We'll have to keep relying on camlp4 for the moment. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Metaprogramming features
On Sat, 2008-10-04 at 03:17 +0100, Jon Harrop wrote: > If you want a race, forget Haskell and look at F# which already provides > typed > metaprogramming with quotations, unsafe high-performance metaprogramming via > CIL and the two most valuable syntax extensions (try..finally and views) as > well as most of the key benefits of OCaml plus decent libraries and a > concurrent run-time. Well, I'm not going to answer on the concurrency aspect, it's been amply discussed in various other threads. As for the decent libraries, that's our first objective with Batteries Included and Community OCaml. Valuable syntax extensions (including boilerplate) is our secondary objective. We handle that part so that the rest of the community can concentrate on the rest of the race :) > IMHO, the most productive direction for OCaml right now is towards LLVM. An > LLVM backend to OCaml would facilitate some productive improvements (e.g. > free polymorphism, easy run-time code generation and dynamic linking, easy > FFI, platform independent and performant intermediate representation, extra > optimization passes for "free"). Moreover, this path can lead to completely > independent compilers that could then be free to expose their lexers, > parsers, type checkers and metaprogramming capabilities without licensing > issues. I quite agree that a move towards LLVM would be an interesting experiment. Whether or not it proves useful remains to be seen. I'm planning to put a few graduate students on writing a Caml bytecode => LLVM compiler later this year and if things go nicely on a whole OCaml => LLVM compiler next year. I believe that a Summer of Code on the subject would be quite profitable (although I can't personally handle it next year). Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Reading external references from cmo/cmx files
You can take a look at objinfo. On Sat, 2008-10-04 at 16:20 -0400, Jason Noakes wrote: > Are there any tools or examples that would allow me to take a .cmo or .cmx > file and produce a list of the external modules that are referenced from > that file? -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Auto-generate mli from ml?
Dear list, I'm currently looking for a complete .ml -> .mli generator. That is, a generator which would essentially perform the same job as 'ocamlc -i', but which would keep whichever comments of the .ml remain meaningful in the .mli (i.e. anything that ocamldoc would keep). Now, that doesn't look like something too hard to write, with a combination of 'ocamlc -i' and camlp4, I'm just wondering if someone has already written such a tool. Thanks, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Auto-generate mli from ml?
Well, actually, I'm attempting to get ocamldoc, ocamlbuild and mlpack files to play together nicely. So unfortunately, that doesn't answer my question. Thanks for trying :) David On Mon, 2008-10-06 at 15:05 +0100, Stefano Zacchiroli wrote: > It does not answer your question directly, but if I'm guessing > correctly that your goal is obtaining both the .mli and the ocamldoc > output, you can achieve that with legacy "ocamlc -i" and ocamldoc with > merge options on the .ml alone. > > But it is likely that I'm not guessing correctly :-) > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] ANN OCaml Batteries Included alpha 1
Dear list, We're happy to inform you that the first alpha version of OCaml Batteries Included has just been released. You may find the source on the Forge [1], as well as the release notes [2], and you can browse the documentation online, including a detailed presentation of what OCaml Batteries Included is all about [3]. A GODI package has also been uploaded for OCaml 3.10 . The list of features is a tad too long for detailing it here. Let's just say that there are new or improved data structures, i/o, unicode ropes, syntax extensions, primitives for invoking some of the tools of the toolchain, etc. It's alpha-level code, so use with caution, and not all the features we have in mind have been implemented yet. On the other hand, any form of feedback is greatly appreciated. [1] http://forge.ocamlcore.org/frs/?group_id=17&release_id=44 [2] http://forge.ocamlcore.org/frs/shownotes.php?release_id=44 [3] http://forge.ocamlcore.org/docman/?group_id=17 Have fun coding, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] ANN OCaml Batteries Included alpha 1
Thanks for the feedback. In the .tgz, there's actually a directory called examples, which is supposed to serve that purpose. We should make it clearer, though. Cheers, David On Sat, 2008-10-11 at 23:27 +0200, Andrej Bauer wrote: > Very good work! I have a small suggestion: in the instructions on how to > start using the batteries, include a small complete example of a > HelloWorld project which uses batteries (and package it up in a .zip). > This will help people get started. The current instructions presuppose > that the user already has some source code, which is not necessarily the > case. > > Best regards, > > Andrej > > ___ > 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 > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] ANN OCaml Batteries Included alpha 1
Hi, It seems we forgot one dependency in the README: you need Bin-prot to get Batteries to work. I must confess that we could have removed that dependency for Alpha 1, as we don't use any feature of Bin-prot yet. Cheers, David On Sun, 2008-10-12 at 01:42 -0400, Peng Zang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I think Batteries Included is a great idea and have been looking forward to > seeing how it turns out. I've just installed it and have been playing around > with it. A quick question, how do you get batteries to work in the toplevel? > > I tried the usual: > > # #use "topfind";; > # #require "batteries";; > No such package: bin_prot.syntax - Required by `batteries.bin_prot.syntax' > > But I get an error. Attempts to "#require" batteries.bin_prot.syntax yield > similar errors. > > This is quite important to me. I don't know what the general sentiment of > the > community is, but the toplevel is one of the major reasons I use OCaml. In > fact, for every Makefile I write, I write an equivalent toplevel init file. > This ensures that any code I write in the toplevel, will compile with no > changes and vice versa. Even when making simple edits to compiled code, I > will open up a toplevel, load the library/file and open the correct name > space of where the edit will take place (automated with some elisp of > course). This allows me to test, in the toplevel, each little change I make. > > Thanks in advance, > > Peng > > > > > > On Saturday 11 October 2008 09:48:34 am David Teller wrote: > > Dear list, > > > > We're happy to inform you that the first alpha version of OCaml > > Batteries Included has just been released. You may find the source on > > the Forge [1], as well as the release notes [2], and you can browse the > > documentation online, including a detailed presentation of what OCaml > > Batteries Included is all about [3]. A GODI package has also been > > uploaded for OCaml 3.10 . > > > > The list of features is a tad too long for detailing it here. Let's just > > say that there are new or improved data structures, i/o, unicode ropes, > > syntax extensions, primitives for invoking some of the tools of the > > toolchain, etc. > > > > It's alpha-level code, so use with caution, and not all the features we > > have in mind have been implemented yet. On the other hand, any form of > > feedback is greatly appreciated. > > > > [1] http://forge.ocamlcore.org/frs/?group_id=17&release_id=44 > > [2] http://forge.ocamlcore.org/frs/shownotes.php?release_id=44 > > [3] http://forge.ocamlcore.org/docman/?group_id=17 > > > > Have fun coding, > > David > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > > iD8DBQFI8Y4/fIRcEFL/JewRAst2AKCRnKy/uB70LhSBnb/Rvny2EJTKYwCgz+j+ > 1oNcyf/KdXaQrwOe4dChrlk= > =zMpC > -END PGP SIGNATURE- > > ___ > 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 > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] ANN OCaml Batteries Included alpha 1
I can reproduce the error. If you don't mind, let's continue that discussion on the Batteries-devel mailing-list [1]. Thanks for the bug report, David [1] http://lists.forge.ocamlcore.org/cgi-bin/mailman/listinfo/batteries-devel On Sun, 2008-10-12 at 13:00 -0400, Peng Zang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Sunday 12 October 2008 09:59:13 am David Teller wrote: > > Hi, > > > > It seems we forgot one dependency in the README: you need Bin-prot to > > get Batteries to work. I must confess that we could have removed that > > dependency for Alpha 1, as we don't use any feature of Bin-prot yet. > > > > Cheers, > > David > > > Thanks for your help. Installing Bin-prot has seemed to fix that error. > Unfortunately, now I get a different one. To give some context, I am trying > to create an equivalent toplevel init.ml file that corresponds to the > ocamlbuild _tags file. > > To build a project with Batteries all you need is "<*>: use_batteries" in the > _tags file. I don't really use ocamlbuild so I am assuming the _tags file > plays a similar role to your normal Makefile. > > My equivalent init.ml file which aims to start an ocamltoplevel in an > environment where any code that compiles will run in the toplevel consists, > so far of: > > #use "topfind" > #require "batteries" > > The new error is: Reference to undefined global `Ref' > > I am not familiar with Ref. It looks like it's a module in Batteries, so I'm > not sure why it's throwing this error. I tried to open Data.Mutable to see > if perhaps things worked despite the warning, but it does not appear to be > so. > > Any ideas? I've attached the complete output below for reference. > > > Thanks in advance, > > > Peng -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Camelia progress
A notion of projects would be nice, which would give the ability to save/load multiple files. And "slight" thanks for your work, David :) On Fri, 2008-10-17 at 09:55 -0400, Kuba Ober wrote: > The upcoming version will be 2.0, and I hope to add some features > to it before it's final. I'm sure of Ocamlbuild support. > Any other features that people would like? > * - "slightly" in the log scale, so just one order of magnitude > is "not much" ;) -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Camelia progress, indenter
I'm not sure that parsing ocamlbuild file is the right thing to do. For a simple OCaml project (which would probably mean most Camelia projects), there are no OCamlBuild files at all. Mmmhhh there's .itarget (i.e. a list of files you wish generated after compilation), but that's about it. And, again, most projects don't have any. Cheers, David On Mon, 2008-10-20 at 09:01 -0400, Kuba Ober wrote: > On Friday 17 October 2008, David Teller wrote: > > A notion of projects would be nice, which would give the ability to > > save/load multiple files. > > At first, I will add "Save all" to the menu (if not already there), so > that all modified documents will be saved with a single action. > > As for real project support, there will be a parser/generator for ocamlbuild > files, although I have never played with ocamlbuild before so I have to see > first how to go about it. > > Cheers, Kuba > > ___ > 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 > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] What does Jane Street use/want for an IDE? What about you?
On Mon, 2008-10-20 at 09:45 -0600, Robert Morelli wrote: > So, my dream would be for someone to build a text editor with the same > basic philosophy as Emacs, > cloning a good bit of its core functionality, but built on a sound > architecture, and capable of dealing with > the demands of modern complex software systems, like IDEs. Roughly > speaking, Emacs built on top of > a "real" language like OCaml, and with the capabilities of modern gui > systems, networks, work flows, > etc. in mind. Just for the sake of bibliography, this reminds me of efuns [1] and Chamo [2]. [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm [2] http://home.gna.org/cameleon/ Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] What does Jane Street use/want for an IDE? What about you?
On Wed, 2008-10-22 at 08:42 -0400, Kuba Ober wrote: > > An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my > > computer). > > OK, I'm adding this to my feature list. I didn't even know ocamlbrowser > existed (never quite made it through the manual, I'm afraid). For information, we have the beginning of a ocamlbrowser replacement in Batteries. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] What does Jane Street use/want for an IDE? What about you?
Le me be more specific: we're not working on a ocamlbrowser replacement. We're just working on a on-line help system. In turn, this help system could be useful for someone wishing to write a ocamlbrowser replacement. Cheers, David On Wed, 2008-10-22 at 23:56 +0200, David Teller wrote: > For information, we have the beginning of a ocamlbrowser replacement in > Batteries. > > Cheers, > David > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Hiding a public module/type?
Dear list, In order to simplify the error messages for users of my library, I'd like to hide some type aliasing. I have the following: (*** module [Inner], defined in inner.mli ***) type t (*** module [Outer], defined in outer.mli ***) type t = Inner.t val f : t -> t Now, module [Inner] is only useful to define the library and shouldn't be visible from the outside. Unfortunately, for the moment, whenever a client makes a type error involving [f], the error message looks like # f 5;; ^ This expression has type int but is used with type Outer.t = Inner.t Is there a simple way of turning this error message into This expression has type int but is used with type Outer.t ? Thanks, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Optional arguments
What were you expecting? Your definition of [a] always passes argument [i] to [b], so the default value is never used. Cheers, David On Sun, 2008-11-09 at 22:17 +0300, malc wrote: > Objective Caml version 3.10.0 > > # let a i = let b ?(i=i mod 3) () = i in b ~i ();; > val a : int -> int = > # for i = 0 to 5 do print_int (a i); done;; > 012345- : unit = () > > Is this something to be expected? Or perhaps something which calls > for an upgrade? > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Hiding a public module/type?
Thanks, I'll try that. On Tue, 2008-11-04 at 00:38 +0100, Martin Jambon wrote: > Then you only have to install the packed.cm* files. It gives you: > > # Packed.Outer.f 5;; > This expression has type int but is here used with type Packed.Outer.t > > > > Martin -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Implementation of lazy_t
On Mon, 2008-11-10 at 17:31 +0100, Florian Lorenzen wrote: > Especially, if > lazy_t implements call-by-need in the sense that once evaluated > objects are not evaluated again (by means of sharing) or if it > implements call-by-name like one can do by inserting 0-ary lambda > abstractions in the constructor to suspend evaluation and applying > them to force evaluation? That's call-by-need indeed. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] [announce] O'Browser : OCaml on browsers
On Mon, 2008-11-17 at 22:43 -0500, Kuba Ober wrote: > > Please note that this is an early version, in particular the DOM > > interface module is neither pretty nor well typed. > > However, it can already be used to create little applets or scripts (as > > in the tutorial [2], the examples of the distribution [3] or my webpage > > [4]) and we'll be glad to receive your comments or bug reports. > > And the reason is? To me, the fact that you can write portable lightweight applets sounds like a good enough reason. That and the fact that I can see this being used by stuff like Ocsigen to make for (even) richer client-server applications. Just my two cents, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Dear list, As you know, we've been working for several months of OCaml Batteries Included. Early in the development, it appeared to us that, with the large number of modules involved, we would need a hierarchy of modules. For instance, for the moment, we have a module [System] containing among other submodules [IO] (definition of i/o operations), [File] (definition of operations on files), [Sys] (the usual OCaml [Sys] module, soon to be expanded), etc. Therefore, before one may open and manipulate files, one has to do open System.IO;; open System.File;; or, with the syntax extension we developed to alleviate this, open System, IO, File The syntax extension does a few other things which we're not going to detail here -- for one thing, it allows local opening of modules. Now, we've decided that our current hierarchy is perhaps somewhat clumsy and that it may benefit from some reworking. Before we proceed, we'd like some feedback from the community. For this purpose, I have posted a tree of the current hierarchy on my blog [1]. The documentation is available online, as usual [2] Thank you for your feedback, For the Batteries Pack, David [1] http://dutherenverseauborddelatable.wordpress.com/2008/11/18/batteries-hierarchy/ [2] http://batteries.forge.ocamlcore.org/doc.preview/batteries-alpha2/doc/batteries/html/api/index.html -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
This raises two questions:
1) how important is it to allow third-party modules to extend the
namespace?
2) how important is it to offer a uniform package structure (where
levels are always separated by '.' rather than some level by '.' and
some by '_')?
For the moment, we have considered point 1 not very important and point
2 a little more. There are several reasons to disregard point 1. Among
these, clarity of origin (as in "is this module endorsed by Batteries or
not?") and documentation issues (as in "gosh, this module pretends to be
part of [Data] but I can't find the documentation anywhere in the
documentation of Batteries, wtf?").
Do you believe that we should have chosen otherwise?
Cheers,
David
On Tue, 2008-11-18 at 10:06 +, Richard Jones wrote:
> Your biggest problem is using dot ('.') instead of underscore ('_').
> Using a dot means that the System namespace cannot be extended by
> external packages. If you use an underscore then an external package
> can extend the namespace (eg. by providing System_Newpackage)
>
> Rich.
>
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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: Wanted: your feedback on the hierarchy of OCaml Batteries Included
I thought the linker only linked in symbols which were actually used?
On Tue, 2008-11-18 at 11:21 +0100, Zheng Li wrote:
> > Your biggest problem is using dot ('.') instead of underscore ('_').
> > Using a dot means that the System namespace cannot be extended by
> > external packages. If you use an underscore then an external package
> > can extend the namespace (eg. by providing System_Newpackage)
>
> And, doesn't that forces all sub modules to be linked into the final
> executables even if we only use one of them?
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings
liquidations.
___
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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote: >Besides Hierarchies are anyway limited in their descriptive power and >one day you'll find something that will fit in two places, Rope is >already an example being both Data.Persistent and Data.Text. That's correct, there are plenty of modules which could fit in different places. For the moment, we decided that every module should appear only in one place. However, we could easily change this -- in fact, to allow this, we only need to alter our documentation generator. > Thus my proposal would be to _present_ them as a hierarchy (but even > here a mean to tag/browse the modules with/by keywords would do a > better job) but keep the actual module structure of Batteries as flat > as possible, everything just under the toplevel Batteries. When I code > I really don't want to have to think about all these open directives > that essentially bring nothing. Browsing by keywords sounds like an interesting idea. I'm adding this to our TODO list. Of course, the next step will be to actually add these keywords and that's going to be much longer if we intend to tag all values. However, we disagree on the necessity of a hierarchy. There are two good reasons why the base library of OCaml doesn't have a hierarchy (almost): it's small and there are almost no redundancies between modules. Neither is true for Batteries. For an example of this redundancy, consider threads. For the moment, we have five thread-related modules: [Threads], [Mutex], [RMutex], [Condition] and [Event]. These modules, which are essentially the same modules as those of the base library, are all submodules of [Control.Concurrency.Threads]. Now, I personally like [Control.Concurrency] but I agree that this is debatable. The reason why we group these modules into [Threads] is because sooner or later, we are going to have four or five other thread-related modules called [Threads], [Mutex], [Condition], [Event] and perhaps [RMutex]. These modules will get into [Control.Concurrency.CoThreads]. They won't replace the first batch, they will exist side-by-side. Of course, we could trim the hierarchy and remove [Control.Concurrency] -- trimming the hierarchy is the main reason for launching this thread, incidentally. But, to keep things ordered, we will still need modules [Threads.Threads], [Threads.Mutex], [Threads.RMutex]... [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a hierarchy already. coThreads is not an exceptional case, mind you. We may end up with two definitions of [Graphics], several data structures with the same name but different purposes, etc. There's also the issue of labels and other partial redefinitions of modules. The OCaml base library defines [Array]/[ArrayLabels], [List]/[ListLabels], [Map]/[MoreLabels.MapLabels] etc. In Batteries Included, we define [Array], [Array.Labels], [List], [List.Labels], which clutters less the list of modules and makes for something more consistent, especially since [FooLabel] is not the only kind of "module [Foo] with a variant": we also have [Array.ExceptionLess], for operations without exceptions, and [Array.Cap] for read-only/write-only arrays. Other variants may still appear. Do you see any better way of managing the complexity of all this? Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:34 +0100, Daniel Bünzli wrote: > Le 18 nov. 08 à 11:29, Erkki Seppala a écrit : > > > For example I prefer using the least amount of opening of modules, > > to make it easier to see where the values come from > > Same here. This is why I'm a little bit sceptical about this hierarchy. > > With the current standard library if I suddenly want to use > Int32.of_int, I know I just need to type Int32.of_int in my source. > With your proposal I need to remember that it is in Data.Numeric and > go at the beginning of my file to open it or write > Data.Numeric.Int32.of_int, to me this brings bureaucracy without any > benefit. And lack of bureaucracy is one of the reasons I like ocaml > (and dislike java for example). I forgot to answer that part. In Batteries, for the moment, we decided to keep the module names of the base library as shortcuts to our new modules. Consequently, you can still write your [Int32.of_int] in addition to our new [Int32.print], etc. The old modules are still available as submodules of [Legacy], if needed. Should you wish to flatten the complete hierarchy, assuming that it's possible and that there are no collisions on names, that's also something which you can do quite easily. We even provide some syntactic sugar for this. It's just the matter of writing a file my_batteries.ml along the lines of module Array= Data.Mutable.Array module List = Data.Persistent.List ... module PosixThreads = Control.Concurrency.Threads.Threads module PosixMutex = Control.Concurrency.Threads.Mutex module CoThreads= Control.Concurrency.CoThreads.Threads ... module ArrayExn = Data.Mutable.Array include ExceptionLess (*syntactic sugar*) module ArrayLabels= Data.Mutable.Array include Labels module ArrayCapExn= Data.Mutable.Array.Cap include ExceptionLess module ArrayCapLabels= Data.Mutable.Array.Cap include Labels ... I personally don't like name [ArrayCapLabels] but I can't think of any better name to represent this once we have removed any hierarchy. I personally prefer the hierarchy but, once again, the majority may disagree. So if you believe this is better, the next logical step would be to design a full and consistent list of modules including all the modules which already appear in the current version of Batteries, and with some space left for OCamlnet, OCamlnae, Reins, Camomile, ULex, Camlp4, CoThreads and a few others. I truly mean it, if you can provide us with something you consider more comfortable and as future-proof, we may adopt it. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:22 +, Richard Jones wrote: > > Do you believe that we should have chosen otherwise? > > Easy - look at CPAN[1]. If you want to scale a project you have to > make decisions that allow a distributed network of people to > cooperate, without needing too much central coordination. CPAN is a > great example of this loose coupling because packages make their own > decision about naming (albeit they can become "official" later - but > they won't need to rename unless there is an actual naming conflict). Interesting point. So far, the approach of Batteries has certainly been different, in large part because we don't want everything to end up part of the Batteries hierarchy (or, well, lack thereof). Of course, this is in contradiction with our sometimes imperialistic tendencies, so we may be guilty of schizophrenia. Perhaps we should organise a poll on this subject. > If the problem is documentation or provenance of packages, then add a > mechanism to solve that problem. Perl also solves this through an > existing, lightweight, distributed mechanism (a standard location to > install man-pages, and a standard man-page format and man-page > generating mechanism -- POD). I'm not sure the man-page format quite scales up to the kind of hyperlinked complexity we have in Batteries for the moment. But yes, I agree, we can certainly work something out. In fact, we could say that we've started on this track, albeit perhaps not with such grand ambitions. Thanks for the idea, David P.S.: I've pointedly ignored your perch on POD :) In my mind, that's a very different topic. For the moment, we'll stick with ocamldoc. -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Ok, that's an interesting point. Now, we just need to all agree on one standard :) On Tue, 2008-11-18 at 12:28 +, Benedikt Grundmann wrote: > > Do you see any better way of managing the complexity of all this? > Yes don't introduce it at all, make a decision to use or not use labels > and stick with it. Similarly make a decision to use or not use exceptions > as the "default", suffix / rename alternative functions as appropriate > (consistently). Consistency is a big win. Not only as it speeds you up > when you read/modify other people's code it also reduces the amount > of decisions you have to do when writing new code. > > http://ocaml.janestreet.com/?q=node/28 > > Cheers, > > Bene > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 12:32 +, Richard Jones wrote: > API changes are handled really badly in OCaml, ironically because of > the lack of a textual preprocessor. You can't just write this every > time lablgtk / calendar / latest culprit decides to change their API: > > #ifdef LABLGTK < 210 > let icon = GMisc.image () in > icon#set_stock icon_type ~size:size; > icon > #else > let icon = GMisc.image () in > icon#set_stock `DIALOG_ERROR; > icon#set_icon_size `DIALOG; > icon > #endif Side-note: That's certainly something we could add to Batteries, if needed. Camlp4 is pretty-much necessary to use Batteries anyway and Camlp4 already defines IFDEF, INCLUDE, etc. We would just need to complete that DSL perhaps to accept any valid OCaml expression and call the ocaml interpreter to evaluate these expressions. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 05:31 -0800, Dario Teixeira wrote: > Paraphrasing Einstein, I think the hierarchy should be as flat > as possible, but no flatter. For example, I see no reason to > materialise in the hierarchy the separation between persistent > and mutable data structures. The should be a documentation > issue. However, and as you noted, there are cases where some > hierarchisation may remove namespace clutter and allow for > better code reuse. Duly noted. As you may see on our candidate replacement hierarchy, we intend to merge Data.Persistent and Data.Mutable into Data.Containers. Whether we flatten further remains open to debate. Thanks, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 14:24 +0100, Daniel Bünzli wrote: > Le 18 nov. 08 à 13:15, David Teller a écrit : > > > But, to keep things ordered, we will still need modules > > [Threads.Threads], [Threads.Mutex], [Threads.RMutex]... > > [CoThreads.Threads], [CoThreads.Mutex]... and, well, that's a > > hierarchy > > already. > > If you include in batteries an external package that has its own > hierarchy and is designed to be opened I don't mind having that > hierarchy. > > In that case you can just add the new toplevel entry > CoThread. And if I want to use CoThread, I just open CoThreads, not > Control.Concurrency.CoThreads. Just try to keep it as flat as > possible, don't try to force modules in an ad-hoc hierarchical > taxonomy to try to sort out modules. I don't care if the toplevel list > of modules is three hundred pages long if there is an efficient mean > to access their documentation (like tags). I do however care a lot if > it becomes bureaucratic to be able to _use_ a module in my code. I concur that tags make a considerable difference. But let us return to threads for one second. There is a very good reason to have two distinct modules [Threads] and [CoThreads] with 4-5 submodules each: functors. Assuming [Threads] and [CoThreads] implement the same interface -- which they do -- I can write a module which takes as argument either [Threads], [CoThreads] or [WhateverThreads] and produces a pseudo-concurrent/truly concurrent/whatever implementation of an algorithm. The same thing could apply to latin-1 strings vs. Unicode strings (this is essentially what happens in Camomile). Now, there are certainly several possibilities. Here's one which doesn't involve a deep hierarchy: * [Thread], [Mutex], [Concurrent], [Event] remain top-level modules * [Threads] is also a top-level module, which contains aliases to [Thread], [Mutex], [Concurrent], [Event] * [CoThreads] is also a top-level module, which contains its own implementations of [Thread], [Mutex], [Concurrent], [Event] We could do the same for strings * [String], [Char], [Rope], [UChar] remain top-level modules * we introduce a new module [Strings] containing [String] and [Char] * we introduce another new module [UStrings] containing an alias [String] to [Rope] and an alias [Char] to [UChar] And for numbers * [Float], [Int], [SafeInt], [BigInt] and hypothetical [SafeFloat] and [BigFloat] (don't ask me what a BigFloat is supposed to be) remain top-level modules * we introduce a new module [Numeric] containing [Float] and [Int] * we introduce a new module [SafeNumeric] containing [SafeFloat] aliased as [Float], [SafeInt] aliased as [Int] * we introduce a new module [BigNumeric] containing [BigFloat] aliased as [Float], [BigInt] aliased as [Int] etc. To me, this seems like the only way to combine no hierarchy and modularity. However, I have the nasty feeling that this is going to end up messy, cluttered and otherwise both unmaintainable and unusable (despite tags). > > Le 18 nov. 08 à 13:22, Richard Jones a écrit : > > > Easy - look at CPAN[1]. If you want to scale a project you have to > > make decisions that allow a distributed network of people to > > cooperate, without needing too much central coordination. > > But (unfortunately, sorry to repeat that) Batteries is not a CPAN like > initiative. It aims at giving a library of modules/syntax extensions > selected by the library maintainers, as such it is inherently > centralized and I don't think that questions (1) or (2) are actually > pertinent for the project. No, we're not CPAN. If someone wishes to build a CPAN, please feel free to do it. That may actually be easier to do once Batteries 1.0 has landed. However, Richard's remark remains interesting. So perhaps redesigning Batteries to have an open namespace structure is a good idea. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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: Wanted: your feedback on the hierarchy of OCaml Batteries Included
Ok, good to know. Since we're packing anyway, there's nothing we can do yet. However, we've already planned to work on a dynamically linked version of Batteries. Just not for release 1.0 So back to square 1 on this argument. Thanks Alain & Zheng On Tue, 2008-11-18 at 15:10 +0100, Alain Frisch wrote: > David Teller wrote: > > I thought the linker only linked in symbols which were actually used? > > No, it is not the case. > > The only automatic mechanism for code pruning is at the level of > individual modules embedded in a library. As soon as you pack, you > obtain a monolithic module which can only be linked as a whole. > > -- Alain > > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Tue, 2008-11-18 at 23:30 +, Jon Harrop wrote: > On Tuesday 18 November 2008 09:56:18 David Teller wrote: > I only have one major concern: you say "with the large number of modules > involved, we would need a hierarchy of modules" but the number of modules > involved is tiny (a few dozen in OCaml compared to tens or even hundreds of > thousands in any industrial-strength language) because OCaml has very few > libraries. Yet your module hierarchies are already enormous and often require > a longer sequence of modules to reach simple functionality than is required > in a comparatively-huge library like .NET. Well, we're trying to be future-proof. Don't you think we should? > To me, the most striking example is printf which is just printf in F#, > Printf.printf in OCaml and is now Text.Printf.printf in OCaml+Batteries. > Surely this is a step in the wrong direction? Well, if you it's just the matter of [printf], we can add it to [Batteries.Standard] to import it in the standard namespace. The biggest question is how many things we want imported in that standard namespace. Or you could start your files with [open Text.Printf] or [module P = Text.Printf] or any similar combination. Oh, and, [Printf.printf] works, too. This is one of the modules which have a shortcut to their path in the hierarchy, to mirror the base library. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
85. Netmail 86. Pop 87. Sendmail 88. Smtp VIII.4. Generic server 89. Netplex_* VIII.5. RPC 90. Rpc_* VIII.6. Languages 91. Genlex 92. Lexing 93. CharParser 94. UCharParser 95. ParserCo A. Source 96. Parsing 97. Format 98. Printf 99. Str 100. PCRE (placeholder) 101. Scanf A. Scanning 102. SExpr = IX. System = 103. Arg 104. File 105. OptParse A. Opt a. OptParser b. StdOpt 106. Path 107. Shell 108. Unix A. Labels 109. Equeue X. Unclassified 110. Digest 111. Random A. State 112. Date (placeholder) On Tue, 2008-11-18 at 10:56 +0100, David Teller wrote: > For this purpose, I have posted a > tree of the current hierarchy on my blog [1]. > > [1] > http://dutherenverseauborddelatable.wordpress.com/2008/11/18/batteries-hierarchy/ -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
On Fri, 2008-11-21 at 00:18 +0100, Daniel Bünzli wrote: > Le 20 nov. 08 à 22:12, David Teller a écrit : > > > If anyone is willing to work on a solution for linking documentation > > from third-party libraries into one transparent source, as suggested > > by Richard Jones, please contact me. > > I'm not sure I understand what you want to acheive. If it is only a > documentation issue cannot that be done with ocamldoc's -dump and - > load ? No, it's not. You cannot ask everyone to regenerate all the documentation of every single package they have as often as they install new packages. The problem is linking already-generated documentation post-facto. > > Batteries (pack) > > 1. Standard (automatically opened) > > Is this Pervasives ? If it is I think the latter name is more > descriptive. It is the replacement for [Pervasives], indeed. And I'm pretty sure that, for beginners, [Pervasives] is more confusing than [Standard]. Since it's automatically opened anyway, most people won't need to know the name. > > 13. Threads (A module containing aliases to Condition, Event...) > >19. CoThreads (as Threads but with implementations coming from > >coThreads) > > If Threads and CoThreads are really semantically compatible I think > that your idea of only having everything in Threads and CoThread is > better and sufficient (i.e. top-level Condition, CoCondition, etc. > should be dropped). Advise the users to open Threads/Cothreads to use > the modules (or functorize their code on Concurrency). This allows to > quickly switch from one implementation to the other by changing the > toplevel open directive. With the current proposal users may be > tempted to use Condition directly, and what happens if some have used > Condition and others CoCondition in their modules and we suddenly try > to use them toghether ? Well, that was my argument for hierarchies. Stop stealing my arguments :) More seriously, sure. > > While I personally find this solution a little clumsier than the > > previous hierarchy, ymmv. > > Of course when you look it as a long list it does, but that's a > presentation issue. This proposal is much more convenient to use in > your code and that's what eventually matters (at least to me). Thanks > for the new proposal. Well, I've started working on a new generation of documentation generation should make navigation by topics feasible. I'll try and have a prototype within 1-2 weeks. > Best, > > Daniel Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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] Wanted: more feedback on the non-hierarchy candidate of Batteries
2. Ftp 84. Ftp_client VIII.3. Mail 85. Netmail 86. Pop 87. Sendmail 88. Smtp VIII.4. Generic server 89. Netplex_* VIII.5. RPC 90. Rpc_* VIII.6. Languages 91. Genlex 92. Lexing 93. CharParser 94. UCharParser 95. ParserCo A. Source 96. Parsing 97. Format 98. Printf 99. Str 100. PCRE (placeholder) 101. Scanf A. Scanning 102. SExpr = IX. System = 103. Arg 104. File 105. OptParse A. Opt a. OptParser b. StdOpt 106. Path 107. Shell 108. Unix A. Labels 109. Equeue X. Unclassified 110. Digest 111. Random A. State 112. Date (placeholder) On Tue, 2008-11-18 at 10:56 +0100, David Teller wrote: > For this purpose, I have posted a > tree of the current hierarchy on my blog [1]. > > [1] > http://dutherenverseauborddelatable.wordpress.com/2008/11/18/batteries-hierarchy/ -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Latest News of French Research: System being liquidated. Researchers angry. ___ 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?
Have you look at Deriving and its Typing module? On Wed, 2008-12-17 at 14:45 -0500, Jacques Carette wrote: > 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? -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Latest News of French Research: System being liquidated. Researchers angry. ___ 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] Wanted: your feedback on the hierarchy of OCaml Batteries Included
Hi Benedikt, You're right, we should make this kind of decision. For the moment, we are focusing on different issues (e.g. standardising I/O, enumerations, module names, etc), in an effort to obtain a base relatively fast, something which could be tested both with existing code and new applications. It is our hope that this will yield enough interest for people to comment and discuss policies regarding exceptions, labels, etc. Cheers, David On Fri, 2008-12-19 at 11:00 +, Benedikt Grundmann wrote: > Somehow I forgot reply back when you posted this reply. And I was just > reminded when I read this: > > "Batteries is meant to serve the following purposes: > [snip] > provide consistent abstractions and APIs for otherwise independent libraries. > " > > on > > http://wiki.cocan.org/events/europe/ocamlmeetinggrenoble2009 > > How can you expect to provide consistent abstractions if you are > not willing to make those decisions? > > Cheers, > > Bene -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Latest News of French Research: System being liquidated. Researchers angry. ___ 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] C++/C# inheritance is bad?
On Sat, 2009-01-17 at 22:17 +, Jon Harrop wrote: > We've wrapped part of WPF in a functional shim for our F# for Visualization > product and, even though it was originally intended for internal use only, > our customers are loving using it themselves because it is vastly simpler and > less error prone than trying to use WPF's own heavily-imperative but entirely > thread unsafe OOP-based API directly. Out of curiosity: is there a public documentation for your functional API? > Incidentally, Cilk looks like the ideal tool to write a parallel GC... Mmmmhhh... Care to argument this? While I'd be glad to implement, say, graph search or min-max/alpha-beta with Cilk, I don't quite see how a concurrent GC would fit into the Cilk model. Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Latest News of French Research: System being liquidated. Researchers angry. ___ 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] Making a polymorphic type non-polymorphic to comply with original signature
It's probably feasible without copy & paste by building a functor on top of the defunctorized hashtable in Batteries. Or by just using the defunctorized hashtable of Batteries directly, although it's not as safe as the functorized version, due to the absence of existential types. Cheers, David On Tue, 2009-01-20 at 12:24 +0100, Daniel Bünzli wrote: > Le 20 janv. 09 à 11:59, Hugo Ferreira a écrit : > > > Is it possible to make H comply with Hashtbl.HashedType i.e: make > > J.Key = 'a H.node ? > > This issue is well known (e.g. see here [1]). Your are running into > limitations of the standard library. The only unsatisfying answer is > to copy the code from the standard library and add the parameter > yourself. > > Best, > > Daniel > > [1] > http://groups.google.com/group/fa.caml/browse_thread/thread/f2acb593da91553c?hl=fr&ie=UTF-8&q=type+var+in+functor+fa.caml > > ugs > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Latest News of French Research: System being liquidated. Researchers angry. ___ 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
I'd like that, too. I may be wrong but I have the impression that most of this can already be done with the current type system of OCaml. Unless I'm mistaken, for first-class modules, you essentially need * extendable records (aka objects, good thing we already have them) * existential types (which may be encoded with universal types, and since we have universal types in classes, there may be a way to to this already) * namespace (which I'm sure could be encoded somehow). Now, the syntax would certainly be awful, but if I'm right it wouldn't take too much to get these modules into the compiler. Cheers, David On Tue, 2009-01-27 at 09:47 -0500, Jacques Carette wrote: > 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
Re: [Caml-list] Defining a family of functors
On Wed, 2009-01-28 at 01:32 +0100, Nicolas Pouillard wrote: > The encoding of modules using existential types in non modular, this > basically means that you have to heavily transform the source. > > What one need to encode modules is "open" existential types, this well > and clearly explained in this POPL'09 paper: > > «Modeling Abstract Types in Modules with Open Existential Types», > by Benoît Montagu and Didier Rémy Yes, I was just reading that paper. However, it is my impression that we could get away without open existential types, at the cost of reduced features. On the other hand, it was pointed to me that Alain already wrote a compiler patch implementing first-class modules. Cheers, David ___ 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 PLEAC reaches 100%
Next step: the OCaml Batteries PLEAC :) Cheers, David (and thanks to Dave and all the contributors for their work) On Fri, 2009-01-30 at 13:40 -0500, Alexy Khrabrov wrote: > I believe we all owe a great debt of gratitude to Dave who toiled with > amazing perseverance and ingenuity for years to make it happen. I'm > going to teach my children to be as persistent as Dave! This is > nothing short of a miracle and a heroic achievement, IMHO, and a fun > to read, too, as the examples are short and you always learn something > new. Kudos to Dave! > > Cheers, > Alexy -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller La Recherche publique est liquidée. Les chercheurs sont en colère. Latest News of French Research: System being liquidated. Researchers angry. ___ 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: [ANN] OCaml Batteries Included, alpha 3
That would be great. On the Batteries side, we now have (on the git) a drop-in replacement for ocamlbuild which doesn't require any myocamlbuild.ml or _tags to use Batteries. (it's actually a one-liner shell script, which invokes ocamlbuild). Cheers, David On Mon, 2009-02-09 at 10:36 +0100, Romain Bardou wrote: > All these should greatly improve the integration of findlib into > Ocamlbuild. My goal is that the findlib plugin on the wiki becomes obsolete. > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller « Ce matin Un crétin A tué un chercheur. » (air connu) Latest News of French Research: System being liquidated. Researchers angry. ___ 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: ocamlbuild documentation (was Re: [Caml-list] Re: [ANN] OCaml Batteries Included, alpha 3)
(Here's hoping that this thread doesn't degenerate into a slugfest) I have used OCamlBuild a lot. I can confirm that this is great software. Unfortunately, I can also confirm that, to do anything besides compiling trivial projects, the Wiki proved extremely elusive at best. My best source of information (besides bugging ertai on IRC :)) was to dig in the mostly uncommented source code of OCamlBuild, without being certain of what was supposed to be public, what was supposed to be known by users, etc. Now, what needs to be written? That's hard to summarize in one sentence, and that's probably why people tend not to contribute to the Wiki once they have found what they need. My personal take would be the following: * take the current official OCamlBuild manual and turn it into chapter 1 of "the OCamlBuild handbook" * write a complete and detailed step-by-step tutorial on writing a _tags file for a simple project, with an appendix detailing all the existing available tags (including the commonly used tags which I believe are automatically generated, such as [pack(...)] ) -- and please write that tutorial for a newbie, not for me * progressively complete that tutorial to add all sorts of not-that-trivial cases such as using OCamlFind, then building a library which is going to be used by the rest of the build process, then building a syntax extension which is going to be used by the rest of the build process, ... (all sorts of things which are already on the Wiki, just with more structure and more details) * progressively complete further that tutorial to add quite complex cases such as integrating things which are not OCaml at all, including C code, LaTeX documentation compiled to both pdf and html, generation of .ml/.mli files during compilation (we have an example of this kind of thing in Batteries, where we have to generate .mli from .mlpack to allow ocamldoc to work on .mlpack files), etc. (some of this is on the Wiki already, but needs more structure and more details) * write a complete and detailed step-by-step tutorial on converting an existing project based on a relatively complex Makefile to _tags and myocamlbuild.ml * add at least the first chapter (preferably everything) to the OCaml manual * ask a user who has used OCamlBuild for trivial projects (preferably one who sits in an office close to that of either Romain Bardou or Nicolas Pouillard) to comment the source code (first the .mli and the .ml) * be available to answer the questions of that user :) Just my two cents. Cheers, David P.S.: And if there's no room for this kind of tutorial in the OCaml documentation, we'll be glad to have it into OCaml Batteries Included :) On Mon, 2009-02-09 at 14:22 +0100, Romain Bardou wrote: > Well I would disagree and say that the bare minimum is here. This is why > I stopped contributing to the wiki: I had nothing else interesting to > add. So now I ask: what exactly is missing from this bare minimum? In my > opinion, questions such as "can I use the flag function inside the rule > function" are definitely not part of the bare minimum. > > (btw, the answer is: the use of the flag function inside the rule > function is not specified, thus not documented) > -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller « Ce matin Un crétin A tué un chercheur. » (air connu) Latest News of French Research: System being liquidated. Researchers angry. ___ 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] How to achieve this camlp4 syntax extension
Hi, I'm not going to quite answer your question yet -- I'd need to check the source of Camlp4 for this. However, I can point out that what you're trying to do looks very much like pa_open, by Alain Frisch. let _ = open M1.M2 in e will execute [e] using module [M1.M2]. Cheers, David On Thu, 2009-04-02 at 12:42 +0100, Conglun Yao wrote: > Dear all, > > I tried to achieve the following syntax extension, but failed. > > Add expression .[ ] after a module name, inside .[ ] I want to refer > to the specified module, like > > let _ = M1.M2.[ here is my syntax, using M1.M2 module ] > > Here is my attempt (failed) > > EXTEND Gram > > GLOBAL: expr; > > expr: LEVEL "top"[ > [ e1 = module_longident; "."; "["; (*t = test_syntax;*) "]" -> > <:expr< $id:e1$ test >> > ]]; > > END > > Different kinds of error happened, when trying to use it. > > Even the ordinary expression: List.length [1; 2;3 ], failed. 'List' > is parsed as module_longident, try to match the rule I defined. > > Thanks for any help. > > Conglun > > ___ > 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] Re: LLC book [was: Questions]
You could start with this: http://fr.wikibooks.org/wiki/Objective_Caml . I have only had the time to write about 3 chapters (in French) but it could serve as a base. Oh, and the license and source control are mostly solved by the use of Wikibooks. Cheers, David ___ 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] Strings
The bad thing is that, whenever you have to return text in an otherwise functional program, you need to enter "mutable array of bytes" land. You can't just assume that the user isn't going to modify that string, because, they can, possibly by accident, and any invariant relying on the fact that your strings can't change are going to be broken. In particular, any StringSet, any StringMap, etc. Cheers, David On Sat, 2009-04-04 at 11:11 +0100, Jon Harrop wrote: > Why? This data structure is a mutable array of bytes and should be treated as > such. > ___ 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
