Hello

Here is the latest OCaml Weekly News, for the week of November 17 to 24, 2015.

1. GADT and weak polymorphism
2. Call For Presentations: Compose 2016, New York, Feb 4-5
3. OCaml t-shirts
4. Uucp 1.1.0
5. Tsdl 0.8.2
6. Notation for currying
7. Ocaml Github Pull Requests
8. Other OCaml News

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00118.html

> Consider the following module:
> 
> module HList = struct
> 
> type (_, _) hlist =
> | Empty : ('a, 'a) hlist
> | Cons : 'c * ('a, 'b) hlist -> ('c -> 'a, 'b) hlist
> 
> let cons : type a b c. c -> (a, b) hlist -> (c -> a, b) hlist =
> fun h tl -> Cons (h, tl)
> 
> let empty = Empty
> 
> let ( **> ) = cons
> 
> let l = '2' **> "str" **> empty
> 
> end
> 
> The type of ``l`` is ``(char -> string -> ‘_a, ‘_a) hlist``. I would like
> to know the reason that weak polymorphism shows up here.

There is an interaction between two advanced aspects of the OCaml language:

1. The relation between (non)-covariance and (non)-generalization of type
variables due to the "relaxed value restriction"
https://www.reddit.com/r/ocaml/comments/t8g2e/pdf_relaxing_the_value_restriction_by_jacques/
http://caml.inria.fr/pub/papers/garrigue-value_restriction-fiwflp04.pdf
2. The difficult analysis of variance of GADT parameters
https://sympa.inria.fr/sympa/arc/caml-list/2012-02/msg00059.html
https://hal.inria.fr/hal-00772993

There is no simple way to solve any of these questions, so I don't expect the
OCaml language to improve on your example on the short/medium term. After
thinking of these issues a bit more, I would personally support adding a
notion of "pure arrow" ('a => 'b), giving your interface the type
( **> ) : 'c => ('a, 'b) hlist => ('c -> 'a, 'b) hlist
which would make any term built solely of ( **> ) and empty (and Empty and
Cons) generalizable. However, this feature would be very limited in scope (due
to the inherent difficulty of tracking effect) and suitable generalization
require advanced type system features (effect systems, for example as found in
Koka or F*). I think a minimal, advanced-uses-only feature (just a separation
of pure and impure arrow) would already be a nice feature to have (also for
functors), but there is no clear consensus on the question.
      

I was asked the same question and found the following stackoverflow
discussion in which two possible remedies are suggested:
http://stackoverflow.com/questions/25025091/ocaml-formatters-and-value-restriction.

Jeffrey Scofield suggests changing your ``l`` to

    let l () = '2' **> "str" **> empty

Leo White suggests writing ``l`` so that it's a value rather than an
expression. In your case, you'd write:

    module HList = struct
      type (_, _) hlist =
        | Empty : ('a, 'a) hlist
        | ::  : 'c * ('a, 'b) hlist -> ('c -> 'a, 'b) hlist

      let empty = Empty

      let l = '2' :: "str" :: empty
    end

I believe that ``::`` is the only infix constructor name in OCaml, so
you have to shadow standard list cons in the module of hlist to make
this work.

In the new ocaml-amqp library, we chose the latter remedy. See the
full result here:
https://github.com/andersfugmann/ocaml-amqp/blob/790486dad/src/amqp_protocol.ml#L197
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00117.html

I'm forwarding this announcement on behalf of Gershom Bazerman. The Compose
conference had a great set of talks last year, and I recommend it to anyone
who can make it out to New York City in February.

--
Compose is a conference for typed functional programmers, focused
specifically on Haskell, OCaml, F#, and related technologies. It will
be held in New York on Thursday and Friday, Feb 4-5, 2016.
Registration will be open shortly.

http://www.composeconference.org/

To get a sense of Compose, you can check out the great talks from the
2015 conference: http://www.composeconference.org/2015/summary/

Below is our call for presentations. We recognize the deadline is
tight, so feel free to submit proposals and ideas on the less-polished
side.

http://www.composeconference.org/2016/cfp/

* * *

The audience for Compose is Haskell, OCaml, F#, or SML developers who
are looking to increase their skills or learn new technologies and
libraries. Presentations should be aimed at teaching or introducing
new ideas or tools. We are also interested in presentations aiming at
taking complex concepts, such as program derivation, and putting them
into productive use. However proposals on anything that you suspect
our audience may find interesting are welcome. The following are some
of the types of talks we would welcome:

Library/Tool Talks — Exploring the uses of a powerful toolkit or
library, be it for parsing, testing, data access and analysis, or
anything else.

Production Systems — Experience reports on deploying functional
techniques in real systems; insights revealed, mistakes made, lessons
learned.

Theory made Practical — Just because it’s locked away in papers
doesn’t mean it’s hard! Accessible lectures on classic results and why
they matter to us today. Such talks can include simply introducing the
principles of a field of research so as to help the audience read up
on it in the future; from abstract machines to program derivation to
branch-and-bound algorithms, the sky’s the limit.

We also welcome proposals for more formal tutorials. Tutorials should
be aimed at a smaller audience of beginner-to-novice understanding,
and ideally include hands-on exercises.

The due date for submissions is December 14, 2015. We will send out
notice of acceptance by December 24th. We prefer that submissions be
via the EasyChair website
(https://easychair.org/conferences/?conf=compose2016). Please suggest
a title, and describe the topic you intend to speak on. Talks can be
either 30 or 45 minutes, please indicate how much time you would
prefer to take.

Additional information may be included on both your expertise and the
interesting elements of your topic, going on what might be included in
a public abstract. Furthermore, if your abstract doesn't feel
"final"—don't worry! We'll work with you to polish it up. If you want
to discuss your proposal(s) before submitting, or to further nail down
what you intend to speak on, please feel free to contact us at
info@composeconference.org. We're happy to work with you, even if you
are a new or inexperienced speaker, to help your talk be great.

* * *

Diversity

We would like to put an emphasis on soliciting a diverse set of
speakers - anything you can do to distribute information about this
CFP and encourage submissions from under-represented groups would be
greatly appreciated. We welcome your contributions and encourage you
to apply!
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00126.html

The OCaml logo is public domain, but there are no OCaml shirts like
there are for other languages! So I decided to print some (sold at cost,
any accidental profits donated to EFF).

Reserve a shirt here:
https://teespring.com/ocaml

Why should you buy an OCaml shirt? Here are the top five reasons:

1. People will automatically assume you are a good programmer.
2. Wearing the shirt helps you find other OCaml programmers, so we can
keep each other safe in this harsh, mutable world.
3. You can use it to impress people of the relevant gender(s).
4. You ran out of clean clothes and don’t feel like doing laundry.
5. Gluten free!
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00127.html

It's my pleasure to announce the release of Uucp 1.1.0.

This release adds support for the East Asian width [1] character property
which can be useful as an heuristic to perform layout of East-Asian text on
devices with fixed-width character advances like terminals.

To that effect a *non-standard*, heuristic function Uucp.Break.tty_width_hint
was contributed by David Kaloper. This function sums up all the practical
knowledge he gathered about Unicode rendering in various terminals while
developing his notty library [2].

Folding Uucp.Break.tty_width_hint [3] over the scalar values of a (preferably
NFC) Unicode string can be used as an estimate of the number of columns it
will occupy in a terminal. Given the non-homogenous state of tty Unicode
rendering the function is not totally foolproof; it will at least work well
with alphabetic scripts and some of the East Asian scripts, but your CHEESE
WEDGE may vary. See the detailed documentation David wrote in [3] for more
information on that unsolvable problem.

Release notes: https://github.com/dbuenzli/uucp/blob/v1.1.0/CHANGES.md

Uucp provides efficient access to a selection of character properties of the Unicode character database.
Homepage: http://erratique.ch/software/uucp

Best,

Daniel

[1] http://www.unicode.org/reports/tr11/tr11-29.html
[2] https://github.com/pqwy/notty
[3] http://erratique.ch/software/uucp/doc/Uucp.Break.html#VALtty_width_hint
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00128.html

tsdl just got a long due maintenance release. The details are in the release notes: 

  https://github.com/dbuenzli/tsdl/blob/v0.8.2/CHANGES.md#v082-2015-11-20-cambridge-uk

Thanks to Frederic Bour and Julian Squires for their patches.

tsdl provides thin bindings to the cross-platform SDL C library.
Homepage: http://erratique.ch/software/tsdl
      

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00138.html

> I personally believe that currified constructor syntax would be a better
> choice, and that using non-currified constructors is a historical mistake
> of SML/Caml. But I am also not convinced that efforts to change it today
> are worth the trouble, and prefer to concentrate on improving other parts
> of the OCaml ecosystem.

Perhaps there should be explicit syntax for currying, such as
   f a b _
instead of 
   f a b
That would permit currying in other argument positions:
   f a _ c
though I suspect _ may be the wrong symbol for the current language, and 
I also suspect it's far too late tointroduce it in the current language.

I have noticed that almost a the situations where the compiler thinks I 
mean to curry I actually just left out a parameter by mistake.  The type 
inferences it makes based on these errors usually occur elsewhere and 
are truly mystifying.
      

In a previous life I would write Camlp4 extension for fun, and I used the
syntax
\( ... _ ...)
to abstract over an anonymous variables (you could also use \1 \2 \3 etc, and
the n-th occurence of _ from left to right was turned into \n, but mixing
numbers and _ was disallowed). It solves Scala's problem that, the scope of _
being delimited by the closest parentheses, the notation was not composable --
but arguably enforcing a small scope is a good thing.

This is the kind of features that nobody will ever agree on, so it's too hard
to get them in a language. Nowadays I write "(fun x ->" instead of "\(", and
"x" instead of "_", and it is not that bad.

Arthur Charguéraud has been working on an "easy-type-errors" mode with better
typing error messages for OCaml. You may be interested in his article
http://www.chargueraud.org/research/2015/ocaml_errors/ocaml_errors.pdf
although I think this specific case of under-application is not discussed
(using too many argument is discussed).

I also find the work on SHErrLoc, by Danfeng Zhang, Andrew C. Myers and their
collaborators, to be very impressive:
http://www.cs.cornell.edu/Projects/SHErrLoc/
      

> As a side question, is currying really an important language feature? In
> my experience, it hinders readability and makes it harder to reason
> about types ("wait, is it weakly or strongly polymorphic? exactly which
> type variables were generalized?")
>
> After coding a number of years in languages without currying, I haven't
> found myself lacking this feature a single time.

The initial discussion was more about the difference in readability
between two syntaxes for fully-applied functions or constructors,
  f(x, y, z), C(x, y, z)
or
  f x y z, C x y z
I find the latter more readable in many settings, in particular where
functions or constructors are nested. One typical example would be the
"balance" functions for Okasaki-inspired red-black trees, for example
https://www.lri.fr/~filliatr/ftp/ocaml/ds/rbset.ml.html

Compare
    | Red (Red (a,x,b), y, c), z, d ->
        Red (Black (a,x,b), y, Black (c,z,d))
with
    | (Red (Red a x b) y c), z, d
        Red (Black a x b) y (Black c z d)

Note that using this syntax does not in itself require supporting
partial application, even though they are naturally linked in the most
common reading of this syntax as nested unary application.

Now, to your question of "do we need to make it easy to partially
abstract over the last parameter of the function", I think I would
agree with you that this is not essential (especially when the syntax
for abstraction is already lightweight). However, having a good syntax
for application is a rather subtle balance to strike that may require
cooperation of several distinct syntactic elements -- in particular
when you also want to support named parameters (or have a lightweight
enough syntax for records or named tuples that looks like named
parameters). I like named parameters as they often improve the
robustness of APIs -- lightweight records are even better because they
can be both passed and returned.

Finally, in Mezzo ( http://protz.github.io/mezzo/ ) there is a cute
trick that I have not seen anywhere else, and I wonder whether it is
an extraordinary (but ancedotal) coincidence or something that should
be reused. The syntax for function parameters in function prototypes
(declarations, signature items)

   val concat: [a] (consumes list a, consumes list a) -> (list a)

and in function definitions

  val concat [a] (consumes xs: list a, consumes ys: list a): list a =
    ...

is exactly the same.

(See http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-types
, http://protz.github.io/mezzo/tutorial/tutorial.html.pp.html#function-definitions
)

This is only possible because the language has just enough dependent
types to make it natural to name all function parameters in their
types, and even do deep pattern-matching on an argument directly from
the type definition. It reminds us of the strange identification
between types and patterns in CDuce ( http://www.cduce.org/ ).
      

Here is a sneak peek at some potential future features of the Ocaml
compiler, discussed by their implementers in these Github Pull Requests.

[WIP] Menhir-generated parser
https://github.com/ocaml/ocaml/pull/292

Add an imperative if construction
https://github.com/ocaml/ocaml/pull/278

IBM z Systems port of ocamlopt
https://github.com/ocaml/ocaml/pull/275
      

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/.

OCaml Labs compiler hacking: Eleventh OCaml compiler hacking evening at Pembroke College
  http://ocamllabs.github.com/compiler-hacking/2015/11/24/compiler-hacking-at-pembroke.html

@typeocaml: Visualise Randomness
  http://typeocaml.com/2015/11/22/visualise_random/
      

Old cwn

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.

Alan Schmitt