Charles Weitzer | 31 Aug 00:35 2015

OCaml opportunity with machine learning group

Voleon Capital Management LP is a startup quantitative hedge fund located in Berkeley, California. We would like to hire a senior software engineer as soon as possible.


Voleon’s founders previously worked together at one of the most successful quantitative hedge funds in the world. Our CEO has a PhD in Computer Science from Stanford and has been CEO and founder of a successful Internet infrastructure startup. Our Chief Investment Officer has a PhD in Statistics from Berkeley. Voleon’s team includes PhD's from leading departments in statistics, computer science, and mathematics. We have made several unpublished advances in the field of machine learning and in other areas as well. 


Here is our formal job description:



* Senior Software Engineer *

Technology-driven investment firm employing cutting-edge statistical machine learning techniques seeks an exceptionally capable software engineer. You will architect and implement new production trading systems, machine learning infrastructure, data integration pipelines, and large-scale storage systems.

The firm researches and deploys systematic trading strategies designed to generate attractive returns without being dependent on the performance of the overall market. Join a team of under 30 people that includes a Berkeley statistics professor as well as over ten PhD's from Berkeley, Chicago, CMU, Princeton, Stanford, and UCLA, led by the founder and CEO of a successful Internet infrastructure technology firm. The firm’s offices are walking distance from BART and the UC Berkeley campus in downtown Berkeley, California. We have a casual and collegial office environment, weekly catered lunches, and competitive benefits packages.

We seek candidates with a proven track record of writing correct, well-designed software, solving hard problems, and delivering complex projects on time. You should preferably have experience designing and implementing fault-tolerant distributed systems. Experience with building large-scale data infrastructure, stream processing systems, or latency-sensitive programs is a bonus.

We are growing rapidly. Willingness to take initiative and a gritty determination to productize are essential.

Required experience:

- developing with C/C++/Python/Go/OCaml in a Linux environment with a focus on performance, concurrency, and correctness.

- experience with functional programming environments (Haskell, Erlang, others).
- working in TCP/IP networking, multi-threading, and server development.
- working with common Internet protocols (IP, TCP/UDP, SSL/TLS, HTTP, SNMP, etc.).
- architecting and designing highly available systems.
- architecting and designing large-scale data management infrastructure.
- working in large codebases and building modular, manageable code.

Preferred experience.:

- debugging and performance profiling, including the use of tools such as strace, valgrind, gdb, tcpdump, etc.
- working with build and test automation tools.
- working with well-defined change management processes.
- diagnosing RDBMS performance problems, exploiting indexing, using EXPLAIN PLAN, optimizing at the code layer, etc.
- working with messaging queues (RabbitMQ, Redis, etc.) as well as distributed caching systems.

Interest in financial applications is essential, but experience in finance is not a primary factor in our hiring.

Benefits and compensation are highly competitive.


The above job description is just a starting point in terms of possible duties and seniority.  We can be very flexible for the right person.

If you are interested or if you know of anyone who might be interested, let us know the best way to get in touch and we can discuss details.

Thank you,



Charles Weitzer

Senior Recruiter

Voleon Capital Management LP

Charles <at>
Office: 510.704.9870 x 7012

Mobile: (510) 558-9182




Oleg | 30 Aug 10:08 2015

Final CFP: FLOPS 2016, International Symposium on Functional and Logic Programming

NEW: revised submission deadlines (Sep 21 for abstracts, Sep 25 for papers)

FLOPS 2016: March 3-6, 2016, Kochi, Japan

Final Call For Papers   

Writing down detailed computational steps is not the only way of
programming. The alternative, being used increasingly in practice, is
to start by writing down the desired properties of the result. The
computational steps are then (semi-)automatically derived from these
higher-level specifications. Examples of this declarative style
include functional and logic programming, program transformation and
re-writing, and extracting programs from proofs of their correctness.

FLOPS aims to bring together practitioners, researchers and
implementors of the declarative programming, to discuss mutually
interesting results and common problems: theoretical advances, their
implementations in language systems and tools, and applications of
these systems in practice. The scope includes all aspects of the
design, semantics, theory, applications, implementations, and teaching
of declarative programming.  FLOPS specifically aims to
promote cross-fertilization between theory and practice and among
different styles of declarative programming.


FLOPS solicits original papers in all areas of the declarative
 * functional, logic, functional-logic programming, re-writing
   systems, formal methods and model checking, program transformations
   and program refinements, developing programs with the help of theorem
   provers or SAT/SMT solvers;
 * foundations, language design, implementation issues (compilation
   techniques, memory management, run-time systems), applications and
   case studies.

FLOPS promotes cross-fertilization among different styles of
declarative programming. Therefore, submissions must be written to be
understandable by the wide audience of declarative programmers and
researchers. Submission of system descriptions and declarative pearls
are especially encouraged.

Submissions should fall into one of the following categories:
 * Regular research papers: they should describe new results and will
   be judged on originality, correctness, and significance.
 * System descriptions: they should contain a link to a working
   system and will be judged on originality, usefulness, and design.
 * Declarative pearls: new and excellent declarative programs or
   theories with illustrative applications.
System descriptions and declarative pearls must be explicitly marked
as such in the title.

Submissions must be unpublished and not submitted for publication
elsewhere. Work that already appeared in unpublished or informally
published workshops proceedings may be submitted. See also ACM SIGPLAN
Republication Policy.

The proceedings will be published by Springer International Publishing
in the Lecture Notes in Computer Science (LNCS) series, as a printed
volume as well as online in the digital library SpringerLink. 

Post-proceedings: The authors of 4-7 best papers will be invited to
submit the extended version of their FLOPS paper to a special issue of
the journal Science of Computer Programming (SCP).

Important dates

Monday, September 21, 2015 (any time zone): Abstract Submission
Friday, September 25, 2015 (any time zone): Submission deadline (FIRM)
Monday, November 16, 2015:                  Author notification
March 3-6, 2016:                            FLOPS Symposium
March 7-9, 2016:                            PPL Workshop

Invited Talks
- Kazunori UEDA (Waseda University)
  The exciting time and hard-won lessons of the Fifth Generation
  Computer Project

- Atze Dijkstra (Utrecht University)
  UHC: Coping with Compiler Complexity


Submissions must be written in English and can be up to 15 pages long
including references, though pearls are typically shorter. The
formatting has to conform to Springer's guidelines.  Regular research
papers should be supported by proofs and/or experimental results. In
case of lack of space, this supporting information should be made
accessible otherwise (e.g., a link to a Web page, or an appendix).

Papers should be submitted electronically at

Program Committee

Andreas Abel         Gothenburg University, Sweden
Lindsay Errington    USA
Makoto Hamana        Gunma University, Japan
Michael Hanus        CAU Kiel, Germany
Jacob Howe           City University London, UK
Makoto Kanazawa      National Institute of Informatics, Japan
Andy King            University of Kent, UK     (PC Co-Chair)
Oleg Kiselyov        Tohoku University, Japan   (PC Co-Chair)
Hsiang-Shang Ko      National Institute of Informatics, Japan
Julia Lawall         Inria-Whisper, France
Andres Loeh          Well-Typed LLP, UK
Anil Madhavapeddy    Cambridge University, UK
Jeff Polakow         USA
Marc Pouzet          Ecole normale superieure, France
Vitor Santos Costa   Universidade do Porto, Portugal
Tom Schrijvers       KU Leuven, Belgium
Zoltan Somogyi       Australia
Alwen Tiu            Nanyang Technological University, Singapore
Sam Tobin-Hochstadt  Indiana University, USA
Hongwei Xi           Boston University, USA
Neng-Fa Zhou         CUNY Brooklyn College and Graduate Center, USA


Andy King            University of Kent, UK                  (PC Co-Chair)
Oleg Kiselyov        Tohoku University, Japan                (PC Co-Chair)
Yukiyoshi Kameyama   University of Tsukuba, Japan            (General Chair)
Kiminori Matsuzaki   Kochi University of Technology, Japan   (Local Chair)

flops2016 at dot jp


Caml-list mailing list.  Subscription management and archives:
Beginner's list:
Bug reports:

GRLMC | 29 Aug 10:32 2015

LATA 2016: 1st call for papers

*To be removed from our mailing list, please respond to this message with UNSUBSCRIBE in the subject line*





LATA 2016


Prague, Czech Republic


March 14-18, 2016


Organized by:


Department of Theoretical Computer Science

CzechTechnicalUniversity in Prague


Research Group on Mathematical Linguistics (GRLMC)

Rovira i Virgili University





LATA is a conference series on theoretical computer science and its applications. Following the tradition of the diverse PhD training events in the field developed at Rovira i VirgiliUniversity in Tarragona since 2002, LATA 2016 will reserve significant room for young scholars at the beginning of their career. It will aim at attracting contributions from classical theory fields as well as application areas.




LATA 2016 will take place in Prague, a city full of history and cultural attractions, and one of the political and economic cores of central Europe. The venue will be the campus of the CzechTechnicalUniversity in the Dejvice quarter.




Topics of either theoretical or applied interest include, but are not limited to:


algebraic language theory

algorithms for semi-structured data mining

algorithms on automata and words

automata and logic

automata for system analysis and programme verification

automata networks

automata, concurrency and Petri nets

automatic structures

cellular automata


combinatorics on words

computational complexity

data and image compression

descriptional complexity

digital libraries and document engineering

foundations of finite state technology

foundations of XML

fuzzy and rough languages

grammars (Chomsky hierarchy, contextual, unification, categorial, etc.)

grammatical inference and algorithmic learning

graphs and graph transformation

language varieties and semigroups

language-based cryptography

parallel and regulated rewriting



power series

string and combinatorial issues in bioinformatics

string processing algorithms

symbolic dynamics

term rewriting


trees, tree languages and tree automata

unconventional models of computation

weighted automata




LATA 2016 will consist of:


invited talks

invited tutorials

peer-reviewed contributions








(to be completed)


Dana Angluin (YaleUniversity, New Haven, USA)

Franz Baader (Technical University of Dresden, Germany)

Christel Baier (Technical University of Dresden, Germany)

Hans L. Bodlaender (UtrechtUniversity, The Netherlands)

Jean-Marc Champarnaud (University of Rouen, France)

Rod Downey (VictoriaUniversity of Wellington, New Zealand)

Frank Drewes (Umeå University, Sweden)

Ding-Zhu Du (University of Texas, Dallas, USA)

Michael Fellows (CharlesDarwinUniversity, Darwin, Australia)

Mohammad Taghi Hajiaghayi (University of Maryland, College Park, USA)

Yo-Sub Han (Yonsei University, Seoul, South Korea)

Oscar H. Ibarra (University of California, Santa Barbara, USA)

Jan Janoušek (CzechTechnicalUniversity in Prague, Czech Republic)

Galina Jirásková (SlovakAcademy of Sciences, Košice, Slovakia)

Ming-Yang Kao (Northwestern University, Evanston, USA)

Juhani Karhumäki (University of Turku, Finland)

Joost-Pieter Katoen (RWTH Aachen University, Germany)

Martin Kutrib (University of Giessen, Germany)

Zhiwu Li (Xidian University, Xi'an, China)

Oded Maler (VERIMAG, Gières, France)

Carlos Martín-Vide (Rovira i Virgili University, Tarragona, Spain, chair)

Ugo Montanari (University of Pisa, Italy)

František Mráz (CharlesUniversity in Prague, Czech Republic)

Mitsunori Ogihara (University of Miami, Coral Gables, USA)

Alexander Okhotin (University of Turku, Finland)

Doron A. Peled (BarIlanUniversity, Ramat Gan, Israel)

Martin Plátek (CharlesUniversity in Prague, Czech Republic)

Daniel Reidenbach (University of Loughborough, UK)

Antonio Restivo (University of Palermo, Italy)

Kai Salomaa (Queen’s University, Kingston, Canada)

Davide Sangiorgi (University of Bologna, Italy)

Uli Sattler (University of Manchester, UK)

Pierre Wolper (University of Liège, Belgium)

Zhilin Wu (Chinese Academy of Sciences, Beijing, China)

Mengchu Zhou (New Jersey Institute of Technology, Newark, USA)




Adrian Horia Dediu (Tarragona)

Jan Janoušek (Prague, co-chair)

Carlos Martín-Vide (Tarragona, co-chair)

Radomír Polách (Prague)

Eliška Šestáková (Prague)

Jan Trávníček (Prague)

Bianca Truthe (Giessen)

Florentina Lilica Voicu (Tarragona)




Authors are invited to submit non-anonymized papers in English presenting original and unpublished research. Papers should not exceed 12 single-spaced pages (including eventual appendices, references, proofs, etc.) and should be prepared according to the standard format for Springer Verlag's LNCS series (see


Submissions have to be uploaded to:




A volume of proceedings published by Springer in the LNCS series will be available by the time of the conference.


A special issue of a major journal will be later published containing peer-reviewed substantially extended versions of some of the papers contributed to the conference. Submissions to it will be by invitation.




The period for registration is open from August 28, 2015 to March 14, 2016. The registration form can be found at:




Paper submission: October 19, 2015 (23:59 CET)

Notification of paper acceptance or rejection: November 27, 2015

Final version of the paper for the LNCS proceedings: December 7, 2015

Early registration: December 7, 2015

Late registration: February 29, 2016

Submission to the journal special issue: June 18, 2016




florentinalilica.voicu <at>




LATA 2016

Research Group on Mathematical Linguistics (GRLMC)

Rovira i Virgili University

Av. Catalunya, 35

43002 Tarragona, Spain


Phone: +34 977 559 543

Fax: +34 977 558 386




České vysoké učení technické v Praze

Universitat Rovira i Virgili


Kenneth Adam Miller | 28 Aug 20:46 2015

Async_core and core in conflict

So, in opam I've hit this problem - I need a package, but it's requirements conflict with another package that I have. Just typing opam install the_package will fail with "No package matches the_package". the_package is async_core

I used the cudf solver farm remotely after hunting  the bug, but as far as this goes, I don't know what to do because I don't have control over those packages or their versions. I can maybe update my version of core (if the upgrade is compatible with a package that I have that uses it).

Any advise for the error below?

The following dependencies couldn't be met:
  - async_core -> core = 109.35.00 | core = 109.36.00 | core = 109.37.00 | core = 109.38.00 | core = 109.40.00 | core = 109.41.00 | core = 109.42.00 | core = 109.45.00 | core = 109.47.00 | core = 109.53.01 | core = <unavailable version> | core < 109.31.00 | core <= 109.31.00 -> pa_test = 109.53.00 -> core_kernel < 111.25.00
  - async_core -> core = 109.35.00 | core = 109.36.00 | core = 109.37.00 | core = 109.38.00 | core = 109.40.00 | core = 109.41.00 | core = 109.42.00 | core = 109.45.00 | core = 109.47.00 | core = 109.53.01 | core = <unavailable version> | core < 109.31.00 | core <= 109.31.00 -> custom_printf = <unavailable version>
  - async_core -> pa_test = 109.53.00 | pa_test <= 109.53.02 -> core_kernel = <unavailable version> | core_kernel < 111.25.00
  - async_core -> zero = 109.21.00 -> core < 109.31.00
Your request can't be satisfied:
  - No package matches core.<unavailable version>.
  - No package matches core_kernel.<unavailable version>.
  - No package matches custom_printf.<unavailable version>.
  - core<109.31.00 is not available because it requires OCaml >= 4.00.1 & < 4.01.0.
  - core_kernel<111.25.00 is not available because it requires OCaml >= 4.01.0 & < 4.02.1.

No solution found, exiting
Amir Chaudhry | 28 Aug 16:16 2015

Fwd: Adopting a Governance framework for

Dear caml-list,

I’ve just posted the following to infrastructure <at> regarding a governance framework
If you have thoughts, please do share them on that list.

Best wishes,

> Begin forwarded message:
> From: Amir Chaudhry <amc79 <at>>
> Subject: Adopting a Governance framework for
> Date: 28 August 2015 15:12:06 BST
> To: infrastructure <infrastructure <at>>
> Dear all,
> Earlier this year, I began working towards a governance framework for the domain and the
projects that make use of it. I wrote about my approach to this and mentioned that such a framework should:
> - demonstrate a commitment to a stable decision-making process.
> - be clear about scope (i.e.
> - document current reality, rather than being aspirational.
> - be a living document, meaning that it can and should evolve.
> Please read the original post for detail on the above points.
> Since that time, I've drafted a governance document and discussed it with those who already run projects
under  We've reached a point where we're ready to discuss this more widely and more formally
adopt the model.
> Starting from today, we're sharing the document publicly and inviting any discussion on this mailing
list (infrastructure <at>  During this time, I'll also be asking the existing
maintainers to ratify the document.
> By the 14th of September we'll wrap things up (for this time around) and publish version 1.0 of the agreed
document on
> You can find a draft linked below and the step-by-step process we're following.  Please do share your
thoughts on this thread.
> Document:
> -- The process for adopting the governance framework --
> 0. I draft and discuss a governance document with existing project maintainers and reach agreement. (DONE).
> 1.  I send an email update to the infra list and caml-list, with a link to a public version of the doc.
> 2.  We allow a period of public discussion on the infra list.
> 3.  During this, I explicitly ask Maintainers and Owner to confirm they will adopt the doc.
> 4.  In parallel, I create an issue on the repo with a list of people to check off as agreements come
in -- important that the responses happen on the mailing list as that's properly archived.
> 5.  Once all the affirmations are in, I push the doc to the site.
> Best wishes,
> Amir


Caml-list mailing list.  Subscription management and archives:
Beginner's list:
Bug reports:
Raoul Duke | 27 Aug 23:57 2015

re: option-type (was Re: We need a rich standard library distributed with OCaml, really)

> It started me thinking about my code, seeing option-type not as
> something strange, that sometimes makes sense, but as something,
> which is really great and might be used more frequently ...


here's hoping the dev world takes it to heart *some day* :-(


Caml-list mailing list.  Subscription management and archives:
Beginner's list:
Bug reports:

Emmanuel Surleau | 27 Aug 20:42 2015

Fwd: We need a rich standard library distributed with OCaml, really

---------- Forwarded message ----------
From: Emmanuel Surleau <emmanuel.surleau <at>>
Date: Thu, Aug 27, 2015 at 7:45 PM
Subject: Re: [Caml-list] We need a rich standard library distributed with OCaml, really
To: Gabriel Scherer <gabriel.scherer <at>>

Quoting Gabriel Scherer (2015-08-27 10:17:08)
> Hongbo, you are saying at the same time that:
> - you want a *rich* (in particular, large) standard library
> - existing third-party base libraries are too large for your taste
> If we magically imported one of those libraries in the OCaml
> distribution, it would still be large, and it would still have
> inter-dependencies between its modules. Why are you unwilling to
> depend on a library provided outside the distribution?
> Depending on external libraries used to be a problem when there was no
> consensus on OCaml packaging (no longer than a few years ago people
> where reluctant to even use ocamlfind). We now have a reasonable
> consensus on a packaging story, and installing third-party libraries
> has never been as easy as it is today -- except on Windows, meh.
> I think you should embrace the idea of depending on software outside
> the OCaml distribution.
> (I understand there are legal issues that make it difficult for some
> companies to use third-party software. It is not our job to work in
> stead of their lawyers.)
> Many of the issues people have with the library distributed with in
> the compiler distribution come from the fact that it is included in
> the compiler distribution -- and thus imposes a maintenance burden on
> the same group, same backward-compatibility constraints, etc. The
> general movements in the current years is to make the compiler
> distribution *smaller*, not *larger*, to avoid these problems.
> I think the criticism you make of existing standard library
> alternatives is fair (at least the Batteries part corresponds to
> something that I think is consensual¹). My preferred solution to help
> solve these issues is to contribute work to improve these libraries.
> ¹: Simon Cruanes has started good work to split Batteries in smaller
> modules that do not depend on each other. This effort is currently
> stalled, in large part by my personal fault (I was too
> perfectionist in hoping for doing this and at the same time preserving
> backward-functionality). Simon may have made the good call in starting
> his own parallel library effort suiting his relatively opinionated
> view of how things should be. I hope to get more time to devote to
> Batteries at some point, and resolve that tension by proposing a good
> compromise (integrating most of Simon's work) for a v3 release.
> There remain the issue that having several "base libraries" risks
> fragmenting the community in incompatible islands of software usage.
> It is true that shoving stuff into the compiler distribution is a way
> to resolve this excess of choice by authority, but it is manifest that
> no one currently wants to bear this authority and the responsibilities
> that come with it. (Except possibly on very localized issues, as the
> `result` type that is being integrated in 4.03+dev).
> I think the way forward is to have smaller independent packages that
> do not require so large a buy-in and consensus. We could have *one*
> package that provides many useful functions for lists, and one
> separate package with many useful functions for strings. In this style
> Daniel Bünzli beautifully documented small packages, or David Sheets
> doing-one-thing libraries would be role models to follow. This wasn't
> an option when Batteries or Core were started, because the packaging
> story was too confused, but it is now and we should take advantage of
> it. Given time (and help?) I hope to evolve Batteries towards this
> model.

(forwarding the original email to the list as I had sent only to Gabriel by accident)

Well, as far collections go, you don't need "large libraries". You just need a
to_gen method in collection types in the stdblib. The gen type itself
is trivially reimplementable, so it's not a hard dependency on ccube's gen
package, and gen itself is a single module that could, if there was the will, be
integrated in the stdlib at little cost. This would greatly extend the
flexibility of existing data structures.

Another issue to consider is that you need to distinguish what is "sugar" and
what is essential infrastructure. You do not want to farm out infrastructure to
third parties. Otherwise, this puts maintainers of OCaml libraries in the
difficult position of choosing for their users. It's mostly a question of data
types. If, for instance, the stdlib had sensible data types for handling time
information, it would be acceptable to leave advanced time-handling mechanics to
specialized libraries outside of the stdlib, as long as they were able to rely
on a *lingua franca* of standard types.

Of course, all that wouldn't solve the design issues of the standard library
(eg, Str, exceptions everywhere, etc.), but adding gen (or at least hooks for
gen) and a number of common data structures would really go a long way.

I wouldn't mind contributing a few hours working on that, assuming we could
reach some kind of consensus.



Christoph Höger | 27 Aug 15:52 2015

Bug or useless error message

Dear all,

right now I am unable to produce a working example of that problem, so
please bear with me.

Basically, I just patched ppx_deriving_yojson to generate polymorphic
functions for recursive types, i.e.

type 'a foo = ...
 and bar = int foo [ <at>  <at> deriving yojson]


let rec foo_of_yojson : 'a. (json -> [`Ok of 'a, `Error of string]) ->
json -> [`Ok of 'a, `Error of string] = ...
and bar_of_yojson = ...

this does, indeed, work in the test cases.

If I apply this method to my (large) real world module, I get a strange

Error: Signature mismatch:
       Values do not match:
         val typedef_struct_of_yojson :
           (Yojson.Safe.json -> [ `Error of string | `Ok of 'a ]) ->
           Yojson.Safe.json ->
           [ `Error of string | `Ok of 'a typedef_struct ]
       is not included in
         val typedef_struct_of_yojson :
           (Yojson.Safe.json -> [ `Error of string | `Ok of 'a ]) ->
           Yojson.Safe.json ->
           [ `Error of string | `Ok of 'a typedef_struct ]

Syntactically, the types are the same, but obviously they are not equal
in their internal representation.

I can workaround this problem by hiding this particular function from
the interface (yes, it only occurs in one function out of ~300).
However, this message bugs me: Is something like this expected when
using explicit generalization?



Christoph Höger

Technische Universität Berlin
Fakultät IV - Elektrotechnik und Informatik
Übersetzerbau und Programmiersprachen

Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin

Tel.: +49 (30) 314-24890
E-Mail: christoph.hoeger <at>


Caml-list mailing list.  Subscription management and archives:
Beginner's list:
Bug reports:

Runhang Li | 27 Aug 15:51 2015

Fwd: Re: [Q] How to use merlin with mikmatch_str ?​



Begin forwarded message:
On Thursday, Aug 27, 2015 at 2:51 PM, Runhang Li <marklrh <at>>, wrote:


I am not maintainer of Merlin, but I think this issue may help:

Thank you



On Thu, Aug 27, 2015 at 2:48 PM, Matej Kosik <5764c029b688c1c0d24a2e97cd764f <at>> wrote:

On 08/27/2015 02:55 PM, Runhang Li wrote:
> Hi, Matej
> See if this issue answers your question:
> You can see all extensions that are being supported at src/kernel/ [1] .
> [1] :


If I understand this correctly, then the support for a particular syntactic extension need to be hardwired into merlin?

Isn't that strange?

(compared to tools such as:

- ocamlc
- ocamlopt
- ocamldep
- ocamldoc

which need not to be sperately modified to support any new (valid) syntactic extension. Do they?

Why is merlin different in this respect?

Matej Kosik | 27 Aug 15:48 2015

Re: [Q] How to use merlin with mikmatch_str ?

On 08/27/2015 02:55 PM, Runhang Li wrote:
> Hi, Matej
> See if this issue answers your question:
> You can see all extensions that are being supported at src/kernel/ [1] .
> [1] :


If I understand this correctly, then the support for a particular syntactic extension need to be hardwired
into merlin?

Isn't that strange?

(compared to tools such as:

	- ocamlc
	- ocamlopt
	- ocamldep
	- ocamldoc

 which need not to be sperately modified to support any new (valid) syntactic extension. Do they?

Why is merlin different in this respect?


Caml-list mailing list.  Subscription management and archives:
Beginner's list:
Bug reports:

Yotam Barnoy | 27 Aug 15:29 2015

Expanding functors

One problem I've commonly encountered in OCaml is the inability to expand the interface of functors after they've been created (I'm not talking about post-application). For example, Map.Make in the stdlib takes an OrderedType module which contains only the compare function. What happens if I want to add something to this interface, such as a show function? I have to copy the whole implementation of Map.Make into my own file to modify it. Compare this to the ability to 'include' a regular module and just add the new functionality, and to take the type of a module and expand that type as needed. Functors are severely lacking in this regard. 

What do people think of this idea -- of allowing functors to be expanded? Ideally, expanding a functor would allow for both replacing its argument type (as in the example I gave) and for adding a second/third functor argument type (so Map.Make(OrderedType) would become Map.Make(OrderedType)(Show).