Here is the latest OCaml Weekly News, for the week of November 17 to 24, 2015.
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00118.htmlRunhang Li asked and Gabriel Scherer replied:
> 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.Jonas Jensen also replied:
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.htmlAshish Agarwal announced:
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 firstname.lastname@example.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.htmlKevin Chen announced:
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.htmlDaniel Bünzli announced:
It's my pleasure to announce the release of Uucp 1.1.0. This release adds support for the East Asian width  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 . Folding Uucp.Break.tty_width_hint  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  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  http://www.unicode.org/reports/tr11/tr11-29.html  https://github.com/pqwy/notty  http://erratique.ch/software/uucp/doc/Uucp.Break.html#VALtty_width_hint
Archive: https://sympa.inria.fr/sympa/arc/caml-list/2015-11/msg00128.htmlDaniel Bünzli announced:
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.htmlContinuing this old thread, Hendrik Boom replied to Gabriel Scherer:
> 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.Gabriel Scherer then said:
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/David Teller then asked and Gabriel Scherer replied:
> 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/
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.