[Caml-list] Terser ppx syntax for common usage (like monads)

[Caml-list] Terser ppx syntax for common usage (like monads)

[Petter A. Urkedal]

Now that we're replacing camlp4 with ppx, we're also replacing e.g.

  lwt x = ....

the longer

  let%lwt x = ...

Now, that's not necessarily a bad thing, but the monad bind operation
tends to be quite invasive, so I'd like to suggest adding a shorter
syntax which the user could choose to map to their most pervasive ppx
rewriter.  I think a good candidate would be

  let* x = ...
  for* x = ... do ... done
  try* ...
  etc.

One way to implement this would be to map kw* to kw%ast, and leave it
to the ppx extensions to accept an option telling it whether to
process "ast" tagged nodes or not. Alternatively, it could be a
compiler option.

My reason for choosing "*" is 1) it looks okay in my opinion, 2) it is
only used as a binary operator, so it can't interfere with existing
code, like e.g. "let!" could.

Re: [Caml-list] Terser ppx syntax for common usage (like monads)

[Petter A. Urkedal]

2015-10-10 15:48 GMT+02:00 Petter A. Urkedal <paurkedal@gmail.com>:
> My reason for choosing "*" is 1) it looks okay in my opinion, 2) it is
> only used as a binary operator, so it can't interfere with existing
> code, like e.g. "let!" could.

I realized that "let!" was a bad example, but "if! r then 1 else 0" is
valid if "r" is a reference, so using "!" for ppx extension points
could invalidate existing code.

Re: [Caml-list] Terser ppx syntax for common usage (like monads)

[Daniel Bünzli]

> Now, that's not necessarily a bad thing, but the monad bind operation
> tends to be quite invasive, so I'd like to suggest adding a shorter
> syntax which the user could choose to map to their most pervasive ppx
> rewriter.

This entails that I can't possibly have an idea of what the code is doing without looking up what the build system is doing which is annoying. We should aim for self-describing sources rather than put too much knowledge in the build systems — which also means that usage of pre-processors should be frown upon in general.

Daniel

Re: [Caml-list] Terser ppx syntax for common usage (like monads)

[Petter A. Urkedal]

I forgot to CC the list when replying, so sending a digest in
cronological order.  (Including Daniel Bünzli's responses, cited in
good faith.)

====

2015-10-10 16:09 GMT+02:00 Daniel Bünzli <daniel.buenzli@erratique.ch>:
>> Now, that's not necessarily a bad thing, but the monad bind operation
>> tends to be quite invasive, so I'd like to suggest adding a shorter
>> syntax which the user could choose to map to their most pervasive ppx
>> rewriter.
>
> This entails that I can't possibly have an idea of what the code is doing without looking up what the build system is doing which is annoying. We should aim for self-describing sources rather than put too much knowledge in the build systems — which also means that usage of pre-processors should be frown upon in general.

The added opaqueness could be avoided by aliasing kw* to kw%ext for
some ext in the source code.  This would also allow delimiting the
scope.

Though, you raise a more general issue.  Do you have an alternative?
Should people stick with [... >>= fun x -> ...], or should monad
support be added to the compiler?  What about deriving extensions?

====

Le samedi, 10 octobre 2015 à 16:20, Petter A. Urkedal a écrit :

> Though, you raise a more general issue. Do you have an alternative?

Not really.
> Should people stick with [... >>= fun x -> ...],

That's personally what I do for now. I don't like pre-processors since
they do not compose in general and needlessly complicate and opacify
build systems and your code. They do solve real problems, but in the
wrong way. I hope that in a few years we will have something along
this line [1]. Meanwhile I'm willing to stay away as much as possible
from pre-processors…
> or should monad support be added to the compiler?

There was some discussion about this at some point to add some magic
for this on `let` keywords, I don't remember the details but it was
rejected — was kind of an ad-hoc hack to be honest. I wanted to point
you to this but the perspective of having to search the mailing list
archive put me off, I'll let you do that…

Best,

Daniel

[1] http://www.lpw25.net/ocaml2015-abs1.pdf

====

2015-10-10 17:28 GMT+02:00 Daniel Bünzli <daniel.buenzli@erratique.ch>:
> Le samedi, 10 octobre 2015 à 16:20, Petter A. Urkedal a écrit :
>> Should people stick with [... >>= fun x -> ...],
>
> That's personally what I do for now. I don't like pre-processors since they do not compose in general and needlessly complicate and opacify build systems and your code. They do solve real problems, but in the wrong way. I hope that in a few years we will have something along this line [1]. Meanwhile I'm willing to stay away as much as possible from pre-processors…

Yes, a macro system would be better.  I was a bit surprised to see
it's typed, considering the issues of representing typed lambda
calculus within it self [2].  I haven't read that close enough to tell
whether it applies here though.  (The original James Chapman may be an
easier read.)

Your [1] reference is talking about performance, and if one is willing
to give up on that, a canonical rewrite might suffice for common
extensions dealing with control flow:

  let%ext x = y in z --> let_ext y (fun x -> z)
  if%ext x then y else z --> if_ext x (fun () -> y) (fun () -> z)
  while%ext x do y done --> while_ext x (fun () -> y)
  etc.

So, concurrency seems to be non-essential use of syntax extension, as
opposed to deriving and other type-driven extensions.

>> or should monad support be added to the compiler?
>
> There was some discussion about this at some point to add some magic for this on `let` keywords, I don't remember the details but it was rejected — was kind of an ad-hoc hack to be honest. I wanted to point you to this but the perspective of having to search the mailing list archive put me off, I'll let you do that…

Didn't find that, but in any case, it does not sound like a good idea
to let the same construct handle both cases without somehow tagging
the usage as monadic, if that was the magic involved.  In any case, I
think it is good to have a system which decouples the development of
new features from the development of OCaml itself, and to avoid
accreting esoteric features.

[1] http://www.lpw25.net/ocaml2015-abs1.pdf
[2] http://homotopytypetheory.org/2014/03/03/hott-should-eat-itself/