Hello
Here is the latest OCaml Weekly News, for the week of April 29 to May 06, 2014.
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" <edwin@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.
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:
workshop2014@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
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
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).
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
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
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/
If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.
If you also wish to receive it every week by mail, you may subscribe online.