Re: [Caml-list] define incompatible type
On Fri, 12 Feb 2010 13:13:33 +0530 Grégoire Seux kamaradclim...@gmail.com wrote: too bad it does not exist ! From ocaml language definition: The optional type equation = typexpr makes the defined type equivalent to the type expression typexpr on the right of the = sign: one can be substituted for the other during typing. When type foo = int then foo is just a type alias for int and therefor it can/will be substituted by int. _ HTWK Leipzig FbIMN Webmail, https://webmail.imn.htwk-leipzig.de ___ 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] deriving show
IIRC, there is an OCaml macro that will autogenerate the code to print values of a variant type from the type definition. Does it handle polymorphic variants? -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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] deriving show
On Fri, 12 Feb 2010 19:54:50 + Jon Harrop j...@ffconsultancy.com wrote: IIRC, there is an OCaml macro that will autogenerate the code to print values of a variant type from the type definition. Does it handle polymorphic variants? Yes, but one needs to write out the type (as in the case with the closed variants) : type t = [ `A of t | `B ] deriving (Show) print_endline (Show.showt(`A `B)) -- ygrek http://ygrek.org.ua ___ 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: Ocaml, Objective-c, and XCode
Andrew Webb andrew.w...@gmail.com writes: I have a few questions relating to using Ocaml with objective-c for anyone who programs on a Mac. We've been working with OCaml/ObjC/Cocoa on the iPhone for a while. We also have a small subset working on the Mac and have built Mac apps with it. I am aware that there aren't any real bindings between ocaml and objective-c/cocoa, so I am investigating rolling my own. This is what we did. There was some work on an OCaml/Cocoa bridge, but it doesn't appear to be finished, and doesn't look like an active project. The home page is here: http://code.google.com/p/objective-c-caml-bridge 1) Does anyone have experience in interfacing ocaml and objc? Is it difficult? The things that make it easier than it could be are: (a) There is good documentation on interfacing OCaml and C, and ObjC is a clean superset of C. So the language tools all work together quite well. (b) The OO subsystem of OCaml is a pretty good match for the Cocoa design. With some work, you can use OCaml objects to represent Cocoa objects, and vice versa. The hard parts are: (a) Cocoa is a very large system, too large for a small number of people to build an interface by hand. A mechanical interface generator would be best, but is also a big project. (b) There's a mismatch between the ObjC reference counting and OCaml GC. For our work, we just add bits to our interface as we need them. Memory management issues are tricky but only need to be solved once in the lowest layer. We don't have any experience with the ObjC GC; this might make things a little trickier. One thing to note is that we like OCaml because it's very flexible and expressive. If you mechanically translate all Cocoa objects and structs into their obvious OCaml corollaries, you lose a lot of the advantage of using OCaml. For example, we map Cocoa NSPoint values into OCaml 2-tuples, not into OCaml records. And we often use OCaml lists (with the correct base type) to represent NSArray objects. Because of this, we don't think a direct mechanical translation of Cocoa into OCaml is going to work. But a mechanical translation with sufficient overrides probably would. 2) Does anyone have a small example project that does mix these two languages? I have looked at unison, but it is too big for me to get my head around. I am thinking more on the scale of the ubiquitous Currency Converter... I don't know of anything. 3) Does anyone who is mixing these languages use Xcode to do so? If so, what steps do you need to go through to set that up? To be honest, we don't currently use Xcode in any non-trivial way. We just use its built-in knowledge about packaging up applications. There was a project to integrate OCaml into Xcode, but again it doesn't look like an active project. The home page is here: http://maxao.free.fr/xcode-ocaml-plugin Jeff Scofield Seattle ___ 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-R binding for the R language.
This post is to announce the 0.2 release of OCaml-R. OCaml-R is a binding embedding the R interpreter into Objective Caml code. Home page: http://home.gna.org/ocaml-r/ Download page: http://download.gna.org/ocaml-r/ Deb packages: http://yziquel.homelinux.org/debian/pool/main/o/ocaml-r/ Tutorial: http://home.gna.org/ocaml-r/gettingstarted.en.html OCamlDoc API: http://yziquel.homelinux.org/topos/api/ocaml-r/index.html http://home.gna.org/ocaml-r/refdoc/index.html The goal of OCaml-R is to provide adequate integration of the R interpreter into Objective Caml, and a framework suitable to bind R library into OCaml code. Version 0.2 is a near-complete rewrite of the 0.1 version by Maxence Guesdon, with an incompatible API. Main features are: - Safe handling of R default environment variables at compile time, following what is done in littler. - R Signal handlers do not conflict with OCaml code. - Integration with findlib, enabling the #require R.interpreter to initialise statically the R interpreter. Compiling with 'ocamlfind ocamlopt -package R.interpreter' also initialises the R interpreter at compile-time, so to speak. - Some (most?) functionalities of the R standalone library are wrapped. - Low-level binding, in the sense that you construct low-level R calls to execute them. You can also parse R code to execute it, if you wish. - R exceptions are chained back to Objective Caml. - R's garbage collector is chained with OCaml's garbage collector. This is done rather inefficiently for the moment (freeing n R values in O(n^2) time complexity), and we expect to bring this down to O(n) with a thin garbage collecting layer in the future. - We provide a double typing scheme, with some subtyping features. A first typing mimics the dynamic typing of the R language, while a second typing, for the end-user, aims at providing a static typing of R values and functions. (This can be bettered). - S3 classes are supported (static typing is however still unsatisfying). S4 classes are not yet supported. Help welcome. - Some basic R datatypes, such as dataframes, are wrapped, and a framework to wrap the standard library has been put in place. - Basic data structures can be converted back and forth between OCaml and the R interpreter. - Ability to inspect (read-only) the inner structure of R values, which is quite convenient: you get to know rather quickly what a given piece of R code returns, which you need to know to type R code statically in order to bind it to OCaml. - Not thread-safe at all. At least, not more than R is... Lwt-style multithreading of R code could be possible, modulo some simple and deep (i.e. below R API) changes in the R evaluation functions. POSIX threading a single R thread with multiple OCaml threads is not yet possible, but is within reach. - Doesn't interact well the R Defaults package. While most of the code sticks or could stick to the R API, or at least to the public part of the R headers, there are some functionalities which are outright out of the scope of the R API. Some of these functionalities are for convenience only (i.e. inspecting internals of R values), while others are crucial to the binding (chaining R exceptions to OCaml). Hopefully, this lays down a foundation on which one could import R functionalities, libraries and packages to OCaml. -- Guillaume Yziquel http://yziquel.homelinux.org/ ___ 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
