Re: [Caml-list] The fastest stream library [Was: Question about

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

In case anyone on the list wonders about MetaOCaml (
http://okmij.org/ftp/ML/MetaOCaml.html ), an excellent resource to learn
about it is Jeremy Yallop's course on staging (as part of an Advanced
Functional Programming course at Cambridge,
https://www.cl.cam.ac.uk/teaching/1415/L28/materials.html ), presented as
an IOCamlJS notebook:

  http://ocamllabs.github.io/iocamljs/staging.html
  http://ocamllabs.github.io/iocamljs/staging2.html
  http://ocamllabs.github.io/iocamljs/staging3.html

The last discussion about whether MetaOCaml could eventually be merged into
OCaml that I'm aware of happened in May 2015:
http://lambda-the-ultimate.org/node/5146 . At the time, Oleg replied that
there are still design aspects of (BER) MetaOCaml that he was not fully
satisfied with, and wanted to wait before proposing it for upstreaming.

(There is a virtuous interaction between MetaOCaml and modular implicits;
in particular, one pain point of MetaOCaml's design is cross-stage
persistence (should it be a language construct or a derived operation?),
and implicits make it much more convenient to define and use persistence
operators.)


On Sat, Nov 12, 2016 at 11:21 AM, Simon Cruanes <simon.cruanes.2007@m4x.org>
wrote:

> Using meta-programming is very nice indeed, but until meta-OCaml is
> merged into OCaml itself, it will be no use for most OCaml programmers
> (at least, those I know of). So it still makes sense to write
> alternative stream libraries that do not rely on metaprogramming nor on
> features yet to come (effects…). For pure OCaml libraries, there is no
> clear winner yet (depends on what API is exposed), Sequence is faster in
> most cases but cannot implement zip/merge, BatSeq/Core.Sequence are good
> in average and probably the best tradeoff overall, Enum is a bit
> complicated but quite comprehensive…
>
> Le Sat, 12 Nov 2016, Oleg a écrit :
> > Gabriel,
> >
> >         Thank you for the detailed and thoughtful message and the
> > motivations behind Enum choices. The library and language design was
> > the central issue in our paper. We do have a different overall
> > approach, which you haven't yet touched. The approach is
> > meta-programming.
> >
> >         It is high-performance community who discovered for themselves
> > that the most promising way to increase or maintain performance is by
> > meta-programming. It was late Ken Kennedy (of High-Performance Fortran
> > fame) who came with telescoping languages and popularized the idea of
> > active libraries. It was again Ken Kennedy who coined the phrase
> > ``abstraction without guilt''. The references (in old, by now) paper
> > make the case that become even clearer by now
> >         http://www-rocq.inria.fr/~acohen/publications/CDGHKP06.ps.gz
> >
> > Thus we can have a very general interface and still very efficient
> > implementation. We can have a pure functional, a fully compositional
> > interface and a very tangled, imperative implementation with
>
> --
> Simon Cruanes
>
> http://weusepgp.info/
> key 49AA62B6, fingerprint 949F EB87 8F06 59C6 D7D3  7D8D 4AC0 1D08 49AA
> 62B6
>

[-- Attachment #2: Type: text/html, Size: 4349 bytes --]