[Caml-list] why is the forward pipe operator (>|) so little used?
hi Reading a few introduction F# articles and presentations I made the observation that the forward pipe operator is widely popular. Its also a language feature that, when it comes up on blogposts or on stackoverflow, its presented as a special F# feature. In the Ocaml world the pipe doesn't have a special place. I doesn't come up in any of the Ocaml Books (print or pdf) and hardly any internet articles or blog posts. For example Jon Harrop mentions the pipe in one of his F# books but not in the Ocaml for Scientists book. Looking at the mentioned F# code, I think the usage of the pipe has an ( imho positive) impact on the style and the readability of the code. But obviously the proficient Ocaml folks don't use it - could someone may explain the reason(s)? thanks ben ___ 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] from if...else to pattern matching
> > # let t x = match x with > a when x<=4 -> true > | _ -> false;; > ok, I had a similar attempt with let tt x = function a when x<=4 -> true | _ -> false;; but that gave me the following (scary -> 'a -> ) signature val tt : int -> 'a -> bool = so I stopped thanks anyway ___ 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] from if...else to pattern matching
hi I try to transform an if-else clause into pattern matching, I think I've tried a lot of approaches, but apperently I'm doing something fundemently wrong. ~ (** Define behaviors against a constang 'x =< c' with if...else and pattern matching. I want to see how to match a value against funtion **) (* defining a '=<' operator *) let (=<) a b = if a < b then true else if a == b then true else false;; let if_test c = if ( 4 =< c )then true else false ;; (* and now use the operator in pattern matching * ) let match_test c = match ( _ =< c ) (* pseudocode *) | 4 -> true | _ -> false ;; ~~~ thanks in advance ben ___ 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] pfff_visual, a fancy code visualizer/navigator for OCaml, and more
> You can try: git clone git://github.com/facebook/pfff.git ok did that, but new error: ./configure && make depend make ~ make[3]: Entering directory `/code/lab/pfff/latest/pfff/commons' ocamlc -g -dtypes -thread -I ocamlextra -I ocollection -I lib-sexp -I lib-json -I lib-xml -I ../external/ocamlgraph -c graph.ml File "graph.ml", line 1, characters 0-1: Error: ../external/ocamlgraph/ocamlgraph.cmi is not a compiled interface make[3]: *** [graph.cmo] Error 2 ~~ On Fri, Sep 24, 2010 at 4:09 PM, Yoann Padioleau wrote: > > On Sep 24, 2010, at 5:42 AM, ben kuin wrote: > >> another error: >> >> >> lang_php/analyze/checker' >> make[1]: Leaving directory `/code/lab/pfff/aryx-pfff-22ece30' >> make pfff pfff_tags sgrep spatch ppp >> make[1]: Entering directory `/code/lab/pfff/aryx-pfff-22ece30' > > This is because you didn't download the latest version. > You can try: git clone git://github.com/facebook/pfff.git > > You can also download pfff tarballs from this page: > http://github.com/facebook/pfff/archives/master > >> make[1]: *** No rule to make target `lang_ml/analyze/lib.cma', needed >> by `pfff'. Stop. >> make[1]: Leaving directory `/code/lab/pfff/aryx-pfff-22ece30' >> make: *** [all] Error 2 >> ~ >> >> >> >> On Fri, Sep 24, 2010 at 8:23 AM, Yoann Padioleau wrote: >>> Hi list, >>> >>> It is my pleasure to announce pfff_visual, a code visualizer/navigator >>> for OCaml. Note that this is not a replacement for Emacs or vi, but more a >>> companion that works with Emacs/Vi. >>> >>> A demo is available here: >>> part1: http://www.youtube.com/watch?v=HRZjBGD3osw >>> part2: http://www.youtube.com/watch?v=993pmNLY_VU >>> >>> pfff_visual is using pfff, which is mainly an OCaml API to write >>> static analysis, dynamic analysis, code visualizations, code >>> navigations, or style-preserving source-to-source transformations such >>> as refactorings on source code. For now the effort is focused on PHP >>> but there is preliminary support for Javascript, and C++ code. >>> There is also preliminary support for OCaml code so that the infrastructure >>> can be used on the code of pfff itself. >>> >>> You can get the source of pfff and pfff_visual here: >>> http://github.com/facebook/pfff >>> >>> Here is how to install it: >>> $ git clone g...@github.com:facebook/pfff.git >>> $ ./configure >>> $ make depend; make; make opt >>> $ ./pfff_visual /path/to/project/using/supported/languages >>> >>> pfff has been tested on MacOS and Linux and is licensed under the LGPL. >>> >>> Thanks to >>> - Lex Stein for ocamlbdb >>> - Olivier Andrieu for ocamlcairo >>> - Jacques Garrigue for ocamlgtk >>> - Martin Jambon, Mika Illouz and Gert Stolpmann for lib-json >>> - Nicolas Canasse for lib-xml >>> - Jane Street for lib-sexp >>> - Thomas Gazagnaire for dynType >>> - Maas-Maarten Zeeman for OUnit.ml >>> - Thorsten Ohl for xHTML.ml >>> - Sylvain Conchon, Jean-Christophe Filliâtre and Julien Signoles for >>> ocamlgraph >>> - Xavier Leroy for ocamlmpi >>> - Markus Mottl for ocamlpcre >>> - Iain Proctor for ocamlthrift >>> - Guillaume Cottenceau for pleac >>> >>> >>> Enjoy. >>> >>> ___ >>> 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] [ANN] pfff_visual, a fancy code visualizer/navigator for OCaml, and more
another error: lang_php/analyze/checker' make[1]: Leaving directory `/code/lab/pfff/aryx-pfff-22ece30' make pfff pfff_tags sgrep spatch ppp make[1]: Entering directory `/code/lab/pfff/aryx-pfff-22ece30' make[1]: *** No rule to make target `lang_ml/analyze/lib.cma', needed by `pfff'. Stop. make[1]: Leaving directory `/code/lab/pfff/aryx-pfff-22ece30' make: *** [all] Error 2 ~ On Fri, Sep 24, 2010 at 8:23 AM, Yoann Padioleau wrote: > Hi list, > > It is my pleasure to announce pfff_visual, a code visualizer/navigator > for OCaml. Note that this is not a replacement for Emacs or vi, but more a > companion that works with Emacs/Vi. > > A demo is available here: > part1: http://www.youtube.com/watch?v=HRZjBGD3osw > part2: http://www.youtube.com/watch?v=993pmNLY_VU > > pfff_visual is using pfff, which is mainly an OCaml API to write > static analysis, dynamic analysis, code visualizations, code > navigations, or style-preserving source-to-source transformations such > as refactorings on source code. For now the effort is focused on PHP > but there is preliminary support for Javascript, and C++ code. > There is also preliminary support for OCaml code so that the infrastructure > can be used on the code of pfff itself. > > You can get the source of pfff and pfff_visual here: > http://github.com/facebook/pfff > > Here is how to install it: > $ git clone g...@github.com:facebook/pfff.git > $ ./configure > $ make depend; make; make opt > $ ./pfff_visual /path/to/project/using/supported/languages > > pfff has been tested on MacOS and Linux and is licensed under the LGPL. > > Thanks to > - Lex Stein for ocamlbdb > - Olivier Andrieu for ocamlcairo > - Jacques Garrigue for ocamlgtk > - Martin Jambon, Mika Illouz and Gert Stolpmann for lib-json > - Nicolas Canasse for lib-xml > - Jane Street for lib-sexp > - Thomas Gazagnaire for dynType > - Maas-Maarten Zeeman for OUnit.ml > - Thorsten Ohl for xHTML.ml > - Sylvain Conchon, Jean-Christophe Filliâtre and Julien Signoles for > ocamlgraph > - Xavier Leroy for ocamlmpi > - Markus Mottl for ocamlpcre > - Iain Proctor for ocamlthrift > - Guillaume Cottenceau for pleac > > > Enjoy. > > ___ > 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] [ANN] pfff_visual, a fancy code visualizer/navigator for OCaml, and more
I might have found a small error in a Makefile in h_visualizations, where a '-I' is missing ~~~ diff h_visualization/Makefile.orig h_visualization/Makefile 22c22 < INCLUDES= -I $(TOP)/commons $(TOP)/commons/lib-json --- > INCLUDES= -I $(TOP)/commons -I $(TOP)/commons/lib-json ~ because something like: ocamlc -g -dtypes -thread -I ../commons ../commons/lib-json/ -c figures.mli (without repetition of '-I') won't compile on my machine. On Fri, Sep 24, 2010 at 8:23 AM, Yoann Padioleau wrote: > Hi list, > > It is my pleasure to announce pfff_visual, a code visualizer/navigator > for OCaml. Note that this is not a replacement for Emacs or vi, but more a > companion that works with Emacs/Vi. > > A demo is available here: > part1: http://www.youtube.com/watch?v=HRZjBGD3osw > part2: http://www.youtube.com/watch?v=993pmNLY_VU > > pfff_visual is using pfff, which is mainly an OCaml API to write > static analysis, dynamic analysis, code visualizations, code > navigations, or style-preserving source-to-source transformations such > as refactorings on source code. For now the effort is focused on PHP > but there is preliminary support for Javascript, and C++ code. > There is also preliminary support for OCaml code so that the infrastructure > can be used on the code of pfff itself. > > You can get the source of pfff and pfff_visual here: > http://github.com/facebook/pfff > > Here is how to install it: > $ git clone g...@github.com:facebook/pfff.git > $ ./configure > $ make depend; make; make opt > $ ./pfff_visual /path/to/project/using/supported/languages > > pfff has been tested on MacOS and Linux and is licensed under the LGPL. > > Thanks to > - Lex Stein for ocamlbdb > - Olivier Andrieu for ocamlcairo > - Jacques Garrigue for ocamlgtk > - Martin Jambon, Mika Illouz and Gert Stolpmann for lib-json > - Nicolas Canasse for lib-xml > - Jane Street for lib-sexp > - Thomas Gazagnaire for dynType > - Maas-Maarten Zeeman for OUnit.ml > - Thorsten Ohl for xHTML.ml > - Sylvain Conchon, Jean-Christophe Filliâtre and Julien Signoles for > ocamlgraph > - Xavier Leroy for ocamlmpi > - Markus Mottl for ocamlpcre > - Iain Proctor for ocamlthrift > - Guillaume Cottenceau for pleac > > > Enjoy. > > ___ > 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] what do I need to know to understand camlp4
> If you are new to OCaml, I'm not actually new to OCaml, but although I've read every notable book about OCaml and a lot of good code of other OCaml programs, OCaml is still very foreign and counter-intuitive too me. I know what you're might thinking now: why the hell does he still bother? The 'problem' is that every time I read something in Python or worse in Java/C++ I instantly miss the lightweight types/pattern matching facility the ability to easily pass functions around. Then I read functional Ruby or Scala code, and I begin to hate fp because in these context it only makes the code harder to read. So why does the whole world tries to hammer some functional features into his imperative language? Why not maximize the imperative features of a functional language? I know only one big project where the explicitely use an imperative style in ocaml? But this code looks (syntax wise) still too much functional for my taste. > with its syntax (somewhat quirky[1], I admit). For me it's worse, the syntax doesn't look quirky, but rather random too me. It's not like cpp where the syntax is utterly pragmatic, without any aesthetic claim. In OCaml it feels like someone deliberately neglected the syntax. > [1] Compared to other programming languages. I know the syntax is > the way > it is for precise reasons (currying, closer to mathematical > notation, ...). Would you mind to list a few mathematical subjects that help me to understand OCamls syntax? thanks a lot ben ___ 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 do I need to know to understand camlp4
thanks Jake, after browsing through those articles I came to the conclusion that for understanding and using camlp4 the notion of quotations and antiquotations is fundamental. My absolute lack of knowledge in this area might be a reason why I can't figure out how camlp4 works. On Thu, Sep 23, 2010 at 6:23 PM, Jake Donham wrote: > On Thu, Sep 23, 2010 at 8:25 AM, bluestorm wrote: >> For an accessible introduction to modern (>= 3.10) Camlp4, you may be >> interested in Jake Donham's blog post series "Reading Camlp4" : >> http://ambassadortothecomputers.blogspot.com/search/label/camlp4 > > You can also see the articles in sequence at > > http://ambassadortothecomputers.blogspot.com/p/reading-camlp4.html > > which I recommend since later articles depend on earlier material. > > Jake > > ___ > 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] what do I need to know to understand camlp4
thanks a lot for this information and the links, this is very helpful On Thu, Sep 23, 2010 at 6:26 PM, Michael Ekstrand wrote: > On Thu, 2010-09-23 at 16:56 +0200, ben kuin wrote: >> Could someone give any idea how I can begin to understand how to write >> simple camlp4 extensions? > > Shameless self-plug, but I wrote a blog post this summer about my > experience figuring out how to do it. I provide a walk-through and > explanation of a minimal syntax extension which adds lazy list pattern > matching support based on Batteries. The URL: > > http://www.elehack.net/michael/blog/2010/06/ocaml-syntax-extension > > I do assume a basic knowledge of parsing context-free grammars, but a > generic tutorial on parsing with a tool such as Yacc can fill in that > gap. The Wikipedia article[1] may also be helpful. > > Once you've lept the hurdle of figuring out what pieces you need to > write and build a syntax extension, the remaining tricky part is to > figure out what pieces of the grammar you need to extend to accomplish > your objective. For that, I consult the definition of the OCaml parser > in Camlp4OCamlParser.ml in the OCaml source tree. > > - Michael > > 1. http://en.wikipedia.org/wiki/Context-free_grammar > > -- > Web/blog: http://elehack.net/michael > Jabber/Google Talk: this e-mail address > Twitter: http://twitter.com/elehack > mouse, n: a device for pointing at the xterm in which you want to type > > ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] what do I need to know to understand camlp4
hi I'm a Ocaml n00b (without any degree). Therefore I have a faible for everything that makes Ocamls syntax more algol/imperative like [1]. An example would be an extension like 'newref' (http://bitbucket.org/johannes/newref/wiki/Home), which turns: print_int !i into print_int $i(* newref *) so I fiercely try to also perlify the declaration that turns let i = ref 3 intolet $i = 3 (* my idea ... *) but camlp4 makes my head spin. The syntax is very difficult and in a lot of camlp4 documentation there is AST modification involved, which is a subject I don't get although I made several attempts. And simple program transformation with camlp4 (using concrete syntax) is nowhere documented. Could someone give any idea how I can begin to understand how to write simple camlp4 extensions? thanks ben [1] please don't kill me ___ 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] web server interface for Ocaml ( like rack, wsgi, ...)?
> what's wrong with simply proxying the HTTP connections through your favorite
> webserver to the backend ocsigen/ocamlnet server?
Nothing per se. I've tried so set something up with ocsigen, but I had
to give up. There seems to be a certain philosophy behind it how you
should writing web apps.
But I just wanted to do something:
- small ( one page app )
- quick and dirty ( no big setup upfront, no compilation)
- deployment, by dropping a (ocaml script) into a webroot, not matter
what webserver is running
- permissive license ( mit, ...)
from wikipedia
require 'rack'
app = Rack::Builder.app do
lambda do |env|
body = "Hello, World!"
[200, {"Content-Type" => "text/plain", "Content-Length" =>
body.length.to_s}, [body]]
end
end
On Sun, Sep 19, 2010 at 12:32 PM, Richard Jones wrote:
> On Thu, Sep 16, 2010 at 10:29:23AM -0700, Jake Donham wrote:
>> On Thu, Sep 16, 2010 at 4:05 AM, ben kuin wrote:
>> > Is there a web server interface / adapter for ocaml that abstracts
>> > your application from the various web server implementations?
>>
>> There is no OCaml equivalent to rack / wsgi. It would be nice to have
>> something like this; the existing web frameworks (e.g. Ocamlnet and
>> Ocsigen as another poster mentioned) implement the whole stack, but it
>> would be nice to be able to mix and match (e.g. run Ocsigen's Eliom
>> applications in Ocamlnet's Netplex server). Part of the difficulty is
>> that there are different approaches to concurrency/asynchrony (Lwt for
>> Ocsigen, Equeue for netplex). My impression is that rack / wsgi punt
>> on this issue, and assume threading. But an OCaml equivalent could
>> possibly offer both a concurrent/asynchronous and a direct-style
>> interface.
>
> Maybe I'm missing the point, but what's wrong with simply proxying the
> HTTP connections through your favorite webserver to the backend
> ocsigen/ocamlnet server?
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>
___
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] web server interface for Ocaml ( like rack, wsgi, ...)?
hi Is there a web server interface / adapter for ocaml that abstracts your application from the various web server implementations? What is your prefered way to write a small web app for example a to-do list? thanks ben ___ 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] about OcamIL
Erik wrote: >>> Jon Harrop wrote: >>> > Not really. Windows supports a far wider variety of hardware than >>> > Linux and > > Well, this does sound a little funny considering that Linux is free > software and has been ported to almost every odd hardware platform, > and how many platforms does Windows run on? I think he meant hardware support as support for devices/drivers. > In my opinion, the existence and market-domination of Windows is a > little like the case with fossil fuel and internal combustion engines > vs. whatever higher technology is being suppressed. > However, I can confidently say that Windows would never be a decent > operating system if there were not rivalry from free software (Linux > and BSD kernels of course!) I look foreward to the day when somebody explain me why even well educated people loose the ability to differentiate when it comes to Microsoft, while the fall into a state of extasy everytime Google drops a little comfort toy while they carry on with their business venture of 'monetizing' the worlds information. The frightening success of Googles IT Services (Postini, Google Apps) is unfortunately not only Microsofts fault, it also the consequence of the fact that it is impossible with linux to significantly lowering maintaining costs of a bigger it infrastructure. In other words: It's still too difficult to manage. That in turn is what I believe a consequence of the lack of modern language infrastructure. As a proof of concept, try to lower your it costs with a true open source alternative to Exchange. See? And this is the niche Google fills with completely aggressive pricing. ___ 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] about OcamIL
> Microsoft was your saviour because Microsoft caused all your problems > in the first place. Ok, the topic here is personal and office computing. I mean cubical drones who are not allowed to used right mouse button? Consultants and their 20 MB powerpoints? Middle management assholes with the portable devices, always busy with syncing stuff from some weird Exchange source to another place. Grandpa who is trying to install his new scanner which also a tv receiver, because the isp told him he also watch tv over internet? It's one ugly amorphous quickly fluctuating mess that happens if you endow the average end user with a PC and throw them into a hit-and-run market environment. So far linux was spared by the end user and 'personal computing'. Would linux be really capable to enhance the personal computing experience not only for the enduser but also for the developer? I see two stumbling blocks: - X/X11/X org: I support a few members in my family and friends with linux installations and problems. X is a source for a lot of grieve. The complexity of X punches the end user to often. I dont see alternatives though. - Applications: I mean the way enduser application are developed deployed and installed. The best way would be mono, unfortunately a forbidden fruit because microsoft was too stupid to really set it free. ___ 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] about OcamIL
> If yes it seems this has not been a big showstopper to Windows apps err what?? On what planet do you live? It must be a nice place :-) COM components ( to encapsulate the abi ) DLL hell ( never heard of that? com registration) STL ( taming the abi) CORBA ( to talk between incompatible libraries) VC6++, VC7++ incompatibilities If you really want to torture a developer, these is the best toolset you get. If you want to punish the user with crashing apps and beautiful error messages ( stuff like: "Error msxml.dll not registered by regsvr32" then go ahead. .NET was already a success before the dotnet-sdk was downloadable. ___ 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] about OcamIL
hi erik, I highly appreciate your blog, so it hurts me a little but - I disagree: > The only evidence to support this is the widespead usage of > Java and C#, but I think that is a language choice rather than > a conscious decision to use a language that runs on a VM. > > People chose Java and C# because they are preferable to > fundamentally unsafe langauges like C and C++. English is not my first language, maybe I misunderstand, but what you're are saying here sound like a complete contradiction to me: Like you say C and C++ are considered as 'unsafe' languages. But thats because they offer features, that are not available when programming for a vm. This has nothing to do with languages, it's a conscious platform decision. >> What if ocamlopt would be dropped for a faster ocaml vm? > > Why? Even if the Ocaml was able to target a faster VM, there > are still many people who would chose to generate native > binaries. I'd call that a questionable decision. As far as I know, using native binaries means to open a whole range of potentially uncorrectionable problems with abi incomptabilities between libraries or with changes of the underlying os. As far as I know when you go native you always have to take abi incompatibility and therefore recompilation into account. For business apps, that's a showstopper. > Erik (who uses Ocaml compiled to native binaries for mission > critical code) Would you mind to share some infos about your experiences, maybe on your blog? ___ 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] about OcamIL
> Please. You're not talking about the same thing. Ben talks about the > benefits such a vm would have once it would be done, you talk about how hard > it would be to do it. Exactly, thanks. I assume it's save to say that most today (business) critical applications have to be written in a vm supported language. What is with Ocamls vm then? I have the impression that only little development is going into Ocamls vm. Or is that wrong? If no - what is the reason for this? What if ocamlopt would be dropped for a faster ocaml vm? Would that be an option? ___ 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: about OcamIL
sylvain, between the lines I think you're say I'm overreacting. I would put it the other way around and say it's sad when people aren't aware of such "details". Once I've tried my luck with the D language, just to give another tragic example. I think if its inventor walter bright settled all those subtle licensing issues earlier, the language had a much bigger following today. Now it's too late. In case of mono I think they should have rigorously abandon *all* the non-ecma parts (ado.net, windows.forms, asp.net,...) from the start. And the special agreement "non-lawsuit" whatever agreement between novell and microsoft was the nail in the coffin for mono as the standard vm on linux. The ship has sailed. It's really sad if see when great achievements can't unfold its potential because of such minor issues. Programming environments on linux are particulary delicate in this regard especially because there are so many community-focused languages today such as Python. I don't think something closed like the JVM had the slightest chance today to take off. The alternatives aren't bad enough anymore. Maybe I care for hlvm too much :-) On Fri, May 14, 2010 at 11:28 PM, Sylvain Le Gall wrote: > On 14-05-2010, ben kuin wrote: >>> Isn't this precisely the aim of Jon's hlvm >>> (www.ffconsultancy.com/ocaml/hlvm/)? >> >> >> licensing: >> Hlvm is driven by a company and its landing page is on a companies >> website and one of its protagonists is smart *and* business savvy. >> What if hlvm would really take off, could they set it free and move >> the homepage to sourceforge ? > > Last time, I checked hlvm homepage was here: > http://hlvm.forge.ocamlcore.org > > What difference will it make to set it on sourceforge? > > The reasoning you apply to a possible change of license can be applied > to a lot of thing in Open Source World... > > Regards, > Sylvain Le Gall > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ 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] about OcamIL
> Isn't this precisely the aim of Jon's hlvm > (www.ffconsultancy.com/ocaml/hlvm/)? that's an interesting question, Here are a few thoughts: technical: - in .NET everything is easy (from the surface): you have your source file (hello.cs) you take your compiler (cs.exe) and compile it to a msil bytecode file (hello.dll). You can run reflection tools to hello.dll or link it to a exe or generate back to source. This bytecodefile is your friend. You can run it on a bunch of runtimes like .net clr, or on mono, or rotor, or dotgnu. You can register libraries in a container to prevent versioning problems with future releases. I couldn't figure out those equivalents int hlvm or llvm. - with HLVM things are complex (for me): What is the role of the big underlying llvm infrastructure. Why do even need hlvm if we have llvm plus ocaml bindings. Does hlvm has its own bytecode? If yes where is it specified? Is hlvm a ocaml library or is it a free standing vm? etc. Maybe for you these a trivial questions, but I still dont get it, while with .net I never had problem to get the idea. licensing: Hlvm is driven by a company and its landing page is on a companies website and one of its protagonists is smart *and* business savvy. What if hlvm would really take off, could they set it free and move the homepage to sourceforge ? Right now it's bsd licensed, maybe tomorow it's dual licenced like Qi? Or maybe the license some (future) killer features under a closed license? This is just guessing - I don't want to spread fud. But as a former .net developer I followed mono from the beginning and I'm very disappointed that mono is still not considered as a friendly linux citicen. All because of some half-clear license issues. But sure hlvm is impressive and could be the solution. ___ 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] about OcamIL
but that would be the big benefit of a clr like vm: It doesn't matter how messed up, chaotic or just heterogen the environment is as long as you can count on a regular execution of your portable bytecode. On Fri, May 14, 2010 at 8:11 PM, Raoul Duke wrote: > On Fri, May 14, 2010 at 9:26 AM, ben kuin wrote: >> realworld. I think it's interesting that on the ms-windows platform >> .net is used for everything with great success: >> Compared to that I think the jvm is only succesful when it comes to >> 'backend services', which often play an important role in big and >> often technically conservative companies. >> I think it's safe to say that on the linux platform we have NOTHING >> COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't >> java doesn't fill this gap? > > ms windows is a more closed and constrained and well-defined ecosystem > than linux is. i think that has impact on the situation. > > sincerely. > > ___ > 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] about OcamIL
> So your argument as such says nothing about JVM jon-bot: yes it does, look at those numbers here: ... goswin-bot: no it doesn't because: ... startup time ... hotspot ... server ... jon-bot: moron goswin-bot: liar So far the typical java-shootout pattern. Maybe another approach would be to compare the JVM and the CLR in the realworld. I think it's interesting that on the ms-windows platform .net is used for everything with great success: - desktop apps (mostly .net: windows forms, wpf / c++ is dying) - web apps (mostly .net: asp.net / asp and com are dead) - backend services (c++ and .net apis: sharepoint, ... / dcom is dying) Compared to that I think the jvm is only succesful when it comes to 'backend services', which often play an important role in big and often technically conservative companies. There are (great) desktop and web apps in java but they require much more expertise then the clr equivalent, they are fewer and often more expensive. That means on the linux platform we have the following situation: - desktop apps (highly fragmented/diversified) - web apps (highly fragmented/diversified) - backend services (c++ and jvm) I think it's safe to say that on the linux platform we have NOTHING COMPARABLE to .NET when it comes to DESKTOP and WEB apps. Why can't java doesn't fill this gap? My guess is that: For desktop and also web apps startup time, memory usage and ease of deployment are too important that most developers are happy with the compromises that the jvm offers. So they do : - use php, ruby, perl, python even for huge applications (without typechecking at compiletime) - write all sorts of extensions in c to speed up: XS, cython, ... (yuck) - write all sorts of bindings to c libraries: PyGtk, ... (yuck) With the result of fragile desktop apps and bad scaling web apps and the consequence that we use a lot of time of hack around those problems. I think something like the clr would be a huge progress first and foremost for the linux programmers. Maybe Ocaml could play an important role of providing a slick api, because of its strength when it comes to language implementation (compilers), so we would have: gil ( gnu intermediate language, a bytecode ) gilrt ( gnu intermediate language runtime, a jit based vm) - the gilrt written in c or c++ - an Ocaml binding to the gilrt - different language implementations gPython, gRuby, gC, gJava (Language to gil compilers written in Ocaml) Or maybe that's just crazy talk ... ben - On Fri, May 14, 2010 at 5:17 PM, Goswin von Brederlow wrote: > Jon Harrop writes: > >> Xavier Clerc wrote: >>> Limiting myself to the JVM... >>> Moreover, at least Scala and Bigloo deliver excellent performances. >> >> I have benchmarks where the JVM is well over 10x slower than .NET. So I do >> not regard any JVM-based language as "high performance". >> >> Cheers, >> Jon. > > You can pretty much write a benchmark for any 2 languages that > specifically targets the weekness of one and the strength of the other > showing that one is better than the other by a wide margin. You can > usualy reverse the argument with a different benchmark. > > So your argument as such says nothing about JVM, just something about > your benchmarks. > > MfG > Goswin > > ___ > 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] about OcamIL
> OCaml doesn't have a vm like the jvm. ocamlc compiles to bytecode ocamlrun interprets the bytecode bytecode interpreter == vm hence ocaml has a vm On Tue, May 11, 2010 at 6:39 PM, Peng Zang wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > On Tuesday 11 May 2010 07:22:56 am ben kuin wrote: >> I think this 3 point are REASONABLE but the combination of those 3 >> items is INEXISTENT. >> >> Ocaml: the vm is not very fast (no jit AFAIK) >> >> >> So I guess the best thing would be to use good ol Ocaml in native mode...? >> > > What do you mean by vm? OCaml doesn't have a vm like the jvm. Although > there's been some great work on compiling OCaml for the jvm. OCaml does have > a toplevel interpreter. It even has a native mode toplevel now that's > suppose to be fast (anyone have any experience with this?). So that's good. > And of course as you pointed out you can always compile OCaml code to native > machine code which has always had good performance. > > Peng > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.7 (GNU/Linux) > > iD4DBQFL6YhCfIRcEFL/JewRAuB7AJ9tDRHgDJGt3+VqmX4u/IxU+vRXyQCWL3NX > SkKhph4GC7xGA85ilSspTw== > =IxIG > -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
Re: [Caml-list] about OcamIL
> A little off topic, but how is Mono/Unix these days? >> Still leaks memory, you refer to your examinations? (http://flyingfrogblog.blogspot.com/2009/01/mono-22-still-leaks-memory.html?showComment=1233522107493#c7872630239059031867) where you say yes and the mono devs are say no to memory leaking? >> has broken TCO Again, I think other people do not have the same opion on this ( http://flyingfrogblog.blogspot.com/2009/01/mono-does-not-support-tail-calls.html) >> and runs like a dog I think this on the other hand is indeed a problem and has been documented seriously (also by you: http://flyingfrogblog.blogspot.com/2009/01/mono-22.html) I've introduced the post with some license related concerns, maybe I should take a step back and think about what I want: 1. - programming in a ML like language ( especially the caml family since I really like those lightweigt type definitions and the pattern matching that can be applied on those) 2. - high performance runtime, preferably a jit based vm, no problems with TCO 3. - a true open source license (approved by Open Source Initiative or by Free Software Foundation) I think this 3 point are REASONABLE but the combination of those 3 items is INEXISTENT. Ocaml: the vm is not very fast (no jit AFAIK) F#: No open source license so far. Bad runtime performance on mono. Ocaml on HLVM: I would appreciate if Jon could make a clear statement if this is something serious or just a little toy. Scala: Not really a ML language: I think it's kind of fun to try to emulate ocaml features or try to port ocaml apps to scala. The problem is the actual work is never going to be finished. I have some concerns the the runtime performance is unpredictable (no TCO, a lot of hacks into the JVM) Yeti: I like the language, but it is in a experimental stage Nekoml: Supercool project, but the vm is not the fastest and jit runs only on x86 platforms So I guess the best thing would be to use good ol Ocaml in native mode...? A last idea: What do you think about libjit? They claim that a jvm/clr like runtime could be built in weeks. Wouldn't it be nice to have a fast vm for Ocaml (ocamljit) ? Does someone has experience with this, I think writing a fast vm is hard, but a fast vm for a functional language is nearly impossible? Maybe OcamIL could then be used as a model for a jit backend, since its MSIL output already runs on libjit (DotGnu, alias pnet) On Mon, May 10, 2010 at 11:53 PM, Jon Harrop wrote: >> A little off topic, but how is Mono/Unix these days? Last I checked >> (>2 years ago) it implemented the basic libraries and runtimes but had > terrible >> performance. Is it now on par with Windows? > > Still leaks memory, has broken TCO and runs like a dog. Mono has also fallen > even farther behind now that .NET 4 is out. However, they have at least > stated that they intend to start trying to support F# on Mono. Then again, > they stated about 6 years ago they were going to replace their crappy > conservative GC with one that might actually work but they never managed to > do that either... > > Cheers, > Jon. > > > ___ > 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] about OcamIL
> 1. [...] it would still require some time to rewrite a few parts. Release early, release often. Maybe you put it under your name on sourceforge, if you are afraid to put potentially non-buildable code under the flags of lexifi. > 2. Similarly, we rely on our "extended standard library" (a collection of > general purpose modules). That sounds interesting! > Again, it would take some time to extract the few > needed function to make a standalone distribution. Release early, release o... > 3. [...] At some point, we planned to sell a version of CSML as > an extra module to this platform If this is about biz vs. oss, then it could be a solution to go the path of PyQT: - offer of a GPL version - sell a version that can be used commercially On Thu, May 6, 2010 at 4:40 AM, Alain Frisch wrote: > On 05/05/2010 11:46 PM, ben kuin wrote: >> >> thats interesting indeed, is there a particular reason you wont >> release the csml compiler sources and provide only the binaries? > > Yes, there are several reasons: > > 1. The code uses some local extensions to the OCaml compiler that are not > available in the INRIA version; this is less true today because some of our > extensions have been integrated upstream, but it would still require some > time to rewrite a few parts. > > 2. Similarly, we rely on our "extended standard library" (a collection of > general purpose modules). Again, it would take some time to extract the few > needed function to make a standalone distribution. > > 3. We sell a development platform for financial applications, which includes > our modified version of OCaml and advanced libraries for the manipulation of > financial concepts. At some point, we planned to sell a version of CSML as > an extra module to this platform (the public version of CSML does not > support some extra features). It hasn't been formally decided yet, but we > might change our plans regarding this issue. > > > We did not get any feedback from the community regarding this tool, so we > haven't felt any motivation to address point 1 and 2 above, or to reconsider > our position in point 3. If you plan to use CSML, let us know about your > projects, and we might find some arrangement (either a custom license with > source code at no charge for you, or a real open-source license). > > Regards, > > Alain Frisch > > > ___ 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] about OcamIL
> for instance abstracting over > x11/win32(horrors!) windowing systems first you're an optimist :-) On Wed, May 5, 2010 at 7:13 PM, Eray Ozkural wrote: > On Thu, May 6, 2010 at 1:36 AM, ben kuin wrote: >> I think the main problem is the lack of cross platform gui that looks >> good on windows. >> >> LablTk: ok only for simple gui >> LablGtk: fragile on linux, bad on windows >> qt: I once tried to create bindings for a newer qt release ( > >> 4.2), I didn't finished it, but I think it would be doable. The big >> problem though is the huge qt dependency with this blackboxy C++/moc >> thing . > > yeah i tried my hand once too :/ i've been thinking about this. > perhaps the best bet is to write a proper gui toolkit in ocaml. after > all this is the most productive programming language, right? :D i > remember a lot of interesting gui frameworks and approaches for > functional languages. i bet we could create a much better api than any > of those once we get rid of the low-level low-tech approach to gui > programming. why don't we write a google summer of code proposal for > that? perhaps some enthusiastic students would take up the challenge. > it could be divided into some stages, for instance abstracting over > x11/win32(horrors!) windowing systems first > > cheers, > > -- > Eray Ozkural, PhD candidate. Comp. Sci. Dept., Bilkent University, Ankara > http://groups.yahoo.com/group/ai-philosophy > http://myspace.com/arizanesil http://myspace.com/malfunct > ___ 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] about OcamIL
I think the main problem is the lack of cross platform gui that looks good on windows. LablTk: ok only for simple gui LablGtk:fragile on linux, bad on windows qt: I once tried to create bindings for a newer qt release ( > 4.2), I didn't finished it, but I think it would be doable. The big problem though is the huge qt dependency with this blackboxy C++/moc thing . On Wed, May 5, 2010 at 6:13 PM, Vincent Aravantinos wrote: > > Le 5 mai 10 à 21:16, Ed Keith a écrit : > >> --- On Wed, 5/5/10, Eray Ozkural wrote: >> >>> Or use the real ocaml on a real OS >>> (^_^) >>> >> >> I do not understand UNIX bigotry. >> >> Yes, Unix is technically superior to Windows. But Plan 9 is technically >> superior to Unix. But I doubt Eray is running Plan 9. >> >> More computers run Windows than all other OS's combined. If you want a >> large user base you need to support Windows. If you do not care about the >> size of your user base, write for Plan 9. >> >> Personalty I try to support as many systems as practical. >> >> It bothers me that the Ocaml community seems to consider Windows >> developers as second class citizens. Until this changes Ocaml will never be >> a main stream language. F# may eat it's lunch. But F# is tied to Windows, >> Ocaml has the potential to be multi-platform. I just wish it would live up >> to this potential. > > I guess you shouldn't take some stup** trollism as representing the whole > community thinking though. > I am not a Windows user but this kind of "Windows sucks" remark pisses me > off. > > Still, it's a fact that it's hard to use ocaml on Windows but there are > frequently some posts on this list showing that many ocamlers do care about > Windows. > The Ocaml Team explicitly requests some help of windows users to test the > releases because they know it's a downside of ocaml. > I think this shows that they really seem to care about it and try to > improve. > > V. > ___ > 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] about OcamIL
keith, a few thoughts, ... before I've worked with linux I was a windows guy. I remember the day (forgot the context though) when I installed the ocaml package on my dell/windows-xp/laptop (yuk) . Since the workflow on windows is very gui centric, you can't help to get very sensible how a particular app looks and feels. I can tell you those "weird" guis (tcl/tk?) scared the hell out of me and I hoped I could get rid of the stuff without breaking the registry :-). Anyway, I think in order to provide something that the next windows user would like to work with, all the ocaml gui apps should be feel very much more native. Maybe the time would be better invested by an effort to port Ocaml-Batteries to F#. I mean why not? On Wed, May 5, 2010 at 3:16 PM, Ed Keith wrote: > --- On Wed, 5/5/10, Eray Ozkural wrote: > >> Or use the real ocaml on a real OS >> (^_^) >> > > I do not understand UNIX bigotry. > > Yes, Unix is technically superior to Windows. But Plan 9 is technically > superior to Unix. But I doubt Eray is running Plan 9. > > More computers run Windows than all other OS's combined. If you want a large > user base you need to support Windows. If you do not care about the size of > your user base, write for Plan 9. > > Personalty I try to support as many systems as practical. > > It bothers me that the Ocaml community seems to consider Windows developers > as second class citizens. Until this changes Ocaml will never be a main > stream language. F# may eat it's lunch. But F# is tied to Windows, Ocaml has > the potential to be multi-platform. I just wish it would live up to this > potential. > > -EdK > > Ed Keith > e_...@yahoo.com > > Blog: edkeith.blogspot.com > > > > > > ___ 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] about OcamIL
> Or use the real ocaml on a real OS (^_^) my vision is a unix centric clr based vm: - no non-ecma parts - maybe a complete different base class library (like OcamIL) - the target is not to enable windows apps on unix, but the other way around - the vm is crossplattform, the bytecode is compatible to mono and ms-.net but the library is incopatible to the standard .net stack ___ 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] about OcamIL
hi I'm waiting for the day that microsoft release f# under a "official" open source license. It has been promised several times, but its still only available under the "Microsoft Research Shared Source license agreement" and meanwhile I'm not sure if it ever really happens. So I've stumbled over OcamlL (*) who claims to target the clr vm. The project seems a littled stalled and the build environment is configured for cygwin. Besides the website there is very little info to find on the internet. Before I waste too much time on this, does somebody has experience with OcamIL? Is it something that could be refined or are there some fundamental problems? Do you think it is interesting, or completely obsolete now with f#? thanks in advance ben * http://www.pps.jussieu.fr/~montela/ocamil ___ 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
