Hello, Here is the latest OCaml Weekly News, for the week of April 29 to May 06, 2014.
1) LibreS3 v0.1: Amazon S3 compatible server 2) Submit to the Workshop on Functional Art, Music, Modelling and Design! (Deadline May 7) 3) Trying to define a functor combining polymorphic variants 4) ppx_protobuf 5) React 1.1.0 6) Obj.magic for polymorphic identifiers 7) Other OCaml News ======================================================================== 1) LibreS3 v0.1: Amazon S3 compatible server Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-04/msg00193.html> ------------------------------------------------------------------------ ** Török Edwin announced: LibreS3 is a robust Open Source replacement for the Amazon S3 service, implementing (a subset of) the S3 REST API. It is written in a monadic style, currently using Lwt and Ocsigenserver[*] as implementations. Standard S3 client libraries and tools (for example s3cmd, python-boto, etc.) can be used to access it. It uses Skylable SX as the storage backend, which automatically provides data deduplication and replication. Source Download: <http://cdn.skylable.com/source/libres3-0.1.tar.gz> Binary packages(RedHat/CentOS6/Debian Wheezy): <http://www.skylable.com/download/#LibreS3> The package is also available on opam: $ opam install libres3 To configure: $ `opam config var sbin`/libres3_setup To start the daemon: $ `opam config var sbin`/libres3 start To test it: $ s3cmd -c `opam config var etc`/libres3/libres3.sample.s3cfg mb s3://foo Homepage: <http://www.skylable.com/products/libres3> License: GPL-2.0 with OpenSSL exception Status: Beta Author: "Török Edwin" <ed...@skylable.com> Bug-reports: <https://bugzilla.skylable.com> Mailing list: <http://lists.skylable.com/> Documentation: <http://www.skylable.com/products/libres3/quickstart> [*]: the server itself is abstracted from the monad implementation, so it should possible to port it to Cohttp/Lwt or Async. ======================================================================== 2) Submit to the Workshop on Functional Art, Music, Modelling and Design! (Deadline May 7) Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-05/msg00007.html> ------------------------------------------------------------------------ ** Michael Sperber announced: If you are using OCaml or another mostly functional language in any kind of musical, artistic, or design endeavour, please consider contributing to FARM 2014, the 2nd ACM SIGPLAN International Workshop of Functional Art, Music, Modelling and Design, co-located with ICFP 2014. Find attached the Call for Papers and Demo Proposals. Regards, Mike -------------------------------------------------------------- FARM 2014 2nd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Gothenburg, Sweden; 6 September, 2014 <http://functional-art.org> The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional ("mostly functional" is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2014 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: workshop2...@functional-art.org KEY DATES: Abstract (for Full Papers) submission deadline: 7 May Full Paper and Demo Abstract submission Deadline: 11 May Author Notification: 30 May Camera Ready: 18 June Workshop: 6 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair. See the FARM website for further details: <http://functional-art.org> PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see <http://authors.acm.org/main.cfm> for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Alex McLean, University of Leeds Program Chair: Henrik Nilsson, University of Nottingham Publicity Chair: Michael Sperber, Active Group GmbH Program Committee: Sam Aaron, Cambridge University David Duke, University of Leeds Kathleen Fisher, Tufts University Julie Greensmith, University of Nottingham Bas de Haas, Universiteit Utrecht Paul Hudak, Yale University David Janin, Université de Bordeaux Richard Lewis, Goldsmiths, University of London Louis Mandel, Collège de France Alex McLean, University of Leeds Carin Meier, Neo Innovation Inc Rob Myers, Furtherfield Henrik Nilsson, University of Nottingham (chair) Dan Piponi, Google Inc Andrew Sorensen, Queensland University of Technology Michael Sperber, Active Group GmbH For further details, see the FARM website: <http://functional-art.org> ======================================================================== 3) Trying to define a functor combining polymorphic variants Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-05/msg00003.html> ------------------------------------------------------------------------ ** Berke Durak asked and Jacques Garrigue replied: > I have been using the following kind of construct: > > module A = struct > type message = [`Alpha] > let string_of_message = function `Alpha -> "alpha" > end > > module B = struct > type message = [`Beta] > let string_of_message = function `Beta -> "beta" > end > > module AB = struct > type message = [ A.message | B.message ] > let string_of_message = function > | #A.message as msg -> A.string_of_message msg > | #B.message as msg -> B.string_of_message msg > end > > So I naturally wanted to write a functor that does what the module AB does: > > module type S = sig > type message > val string_of_message : message -> string > end > > module PROD(A : S)(B : S) = struct > type message = [ A.message | B.message ] > let string_of_message = function > | #A.t as msg -> A.string_of_message msg > | #B.t as msg -> B.string_of_message msg > end > > But we (me + people on #ocaml: mrvn, drup, ggole, whitequark...) couldn't > find a > way to specify, in the signature S, that message is a polymorphic variant so > that [ A.message | B.message ] is legal. There is a branch of the compiler which allows you to do that. <http://caml.inria.fr/cgi-bin/viewvc.cgi/ocaml/branches/varunion/> Note that it contains only part of the directories. You can get the others from a pristine 3.10. Using that version, you would write: module type S = sig type message = private [> ] ? end module PROD (A : S) (B : S with type message = private [> ] ~ A.message) = ? where the ~ is a compatibility annotation. This was never merged because I couldn?t find a clean way to fix some gap between theory and practice, but I may give it another try. Keigo Imai used it in his async_session code. <https://github.com/keigoi/async_session/blob/master/varunion_session.ml> ** Berke Durak then asked and Jacques Garrigue replied: > Jacques, if the PROD functor has to have a compatibility tag, doesn't > it mean that you can't reuse it to generate large products? i.e. how > would one write: A*B*C*D = PROD(A)(PROD(B)(PROD(C)(D))))? The compatibility annotation is on the functor. If the variant types in the modules you pass to the functor are concrete, they don?t need annotations. If you want to define a 4-ary functor that calls PROD, then its arguments will need annotations too, of course. For the details, you can see the internship report by Romain Bardou (in French): Unions de variants polymorphes abstraits <http://www.math.nagoya-u.ac.jp/~garrigue/papers/index.html> ======================================================================== 4) ppx_protobuf Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-05/msg00009.html> ------------------------------------------------------------------------ ** Peter Zotov announced: I have just released the first version of ppx_protobuf, a complete Protocol Buffers implementation. Unlike Google's implementation, ppx_protobuf derives the message structure directly from OCaml type definitions, which allows a much more seamless integration with OCaml's types. In particular, ppx_protobuf natively supports sum types, while maintaining full backwards compatibility with protoc. ppx_protobuf uses the extension points API, and thus requires a recent (>= 2014-04-29) 4.02 (trunk) compiler. It also requires an unreleased version of ppx_tools. It is probably easiest to install both from the source repositories[1][2]. The API is extensively documented at [3]. [1]: <https://github.com/whitequark/ocaml-ppx_protobuf.git> [2]: <https://github.com/alainfrisch/ppx_tools.git> [3]: <https://github.com/whitequark/ocaml-ppx_protobuf/blob/master/README.md> ** Alain Frisch then asked and Peter Zotov replied: > This is a very cool project, and a good first public use of > extension points! Thanks! > > An aspect of attributes that is not fully settled is how to use > namespacing in order to ensure that multiple tools interact nicely. > This topic will hopefully be explored by the community to reach a good > consensus. > > (a suggestion to recognize both [@x] and [@protobuf.x]) I have designed ppx_protobuf's usage of attributes with exactly this in mind; [@default] especially would be useful for a wide range of type-driven code generators. I actually intended to release it with the support for namespaced attribute variants ([@protobuf.key]), it has simply been forgotten. I'll include it in the next release. > > Another point: for record fields, you interpret attributes at the > toplevel of their type. I did not look precisely at the semantics of > ppx_protobuf, but it seems that it might be more logical to attach > them to the field directly (do you confirm?): > > type defaults = { > results [@key 1] [@default 10]: int; > } [@@protobuf] > > I understand that this form is syntactically "more intrusive" in the > non-decorated type definition. Is it the reason to use: > > type defaults = { > results : int [@key 1] [@default 10]; > } [@@protobuf] > > ? > > I don't see anything wrong with doing so, although it might be worth > supporting both forms. The issue here is that I want to support "immediate tuples" (i.e. "field : int * int", or, more importantly, "A of int * int", which are semantically equivalent to and represented as a Protobuf message. As such, I felt it would be only consistent to have the same syntax for specifying options on an immediate tuple of several elements: results : int [@encoding zigzag] * int [@encoding bits32] and for specifying options on a "tuple of one element": results : int [@encoding zigzag] I'm not entirely happy with this scheme; the way it gives rise to the message structure is at best confusing, as adding or removing a tuple element can add or remove nesting and thus break protocol compatibility. In addition, the [@key] attribute on, for example, a field itself would currently be ignored. While this behavior can be fixed for the most common misplacements, I feel like it's a drawback intrinsic to the extension points mechanism: misplaced or misnamed attributes are going to be silently ignored. Do you have any ideas for a solution? I have toyed with an idea of a "verifier extension" which would ascertain the lack of attributes after all the rewriter passes have presumably removed the attributes known to them, but it wouldn't work with generic attributes like [@default] that must be shared between extensions. ** Alain Frisch then replied: I'm not convinced by the idea of checking the absence of attributes after -ppx rewriters are applied. You mention one reason (generic attributes, which shouldn't be discarded by any specific -ppx), but there are others: - Even non-generic attributes might be better left in the Parsetree sent to OCaml, so that they appear in particular in the dumped typedtree (.cmt/.cmti), which could be useful for further processing (e.g. a version of ocamldoc based on .cmti files). - Attributes are not only designed to support -ppx rewriters. They can also be used by tools which inspect compiled .cmt/.cmti/.cmi files, or stand-alone tools which work on source files but are not used as preprocessors. - There is also the case of "optional" -ppx rewriters (e.g. a code instrumentation tool which could be applied or not). An "attribute checker" (either integrated in a generic style-checking tool such as Mascot or as a stand-alone tool, or maybe even as an "identity" -ppx so that it is always included in the compilation chain) would need some way to know which attributes are allowed and in which context (it's fair to let each tool check the advanced conditions on the payload and constraints such as nesting conditions). For instance, each tool could come with a small text file describing the attributes it recognizes (and in which contexts), maybe also with a rough description of admissible payloads and -- why not -- some succinct documentation about the attribute. This information could be useful not only for the attribute checker, but potentially by other tools as well (e.g. an IDE). ======================================================================== 5) React 1.1.0 Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-05/msg00032.html> ------------------------------------------------------------------------ ** Daniel Bünzli announced: This new implementation of S.switch is becoming embarrassing. Uncovered a new bug here [1]. It's fixed. New release coming in a few days, I want to wait a little bit to see if I uncover other things. Sorry for the inconvenience, Daniel [1] <https://github.com/dbuenzli/react/issues/7> ======================================================================== 6) Obj.magic for polymorphic identifiers Archive: <https://sympa.inria.fr/sympa/arc/caml-list/2014-05/msg00033.html> ------------------------------------------------------------------------ ** Continuing an old thread, Goswin von Brederlow asked and Leo White replied: (Please see <http://alan.petitepomme.net/cwn/2014.04.22.html#7> for context.) > Now that is a good reason to have open types. I've tried (and failed) > to do something like this without resorting to magic and the only way > I found was to declare a big GADT that has a constructor for every > possible type and match all possible equal pairs. That realy doesn't > scale well. > > > Would it be possible for someone familiar with the patch to create a > pull request for it on git? Maybe that way it could be merged in > faster. > > MfG > Goswin As it happens they have just been merged: <https://github.com/ocaml/ocaml/commit/b56dc4b3df8d022b54f40682a9d5d4168c690413> ======================================================================== 7) Other OCaml News ------------------------------------------------------------------------ ** From the ocamlcore planet blog: Thanks to Alp Mestan, we now include in the OCaml Weekly News the links to the recent posts from the ocamlcore planet blog at <http://planet.ocaml.org/>. Brazilian type checking: <http://math.andrej.com/2014/05/06/brazilian-type-checking/> ======================================================================== Old cwn ------------------------------------------------------------------------ If you happen to miss a CWN, you can send me a message (alan.schm...@polytechnique.org) and I'll mail it to you, or go take a look at the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish to receive it every week by mail, you may subscribe online at <http://lists.idyll.org/listinfo/caml-news-weekly/> . ======================================================================== _______________________________________________ caml-news-weekly mailing list caml-news-weekly@lists.idyll.org http://lists.idyll.org/listinfo/caml-news-weekly