[erlang-questions] Pipe, maybe, and other silly parse transforms

[Fred Hebert]

On 04/02, Andreas Schultz wrote:
>Hi Fred,
>
>Out of curiosity, how does this differ from erlando's
>(https://github.com/rabbitmq/erlando) `state` monad ?
>
>The syntax does seem to a bit more pleasing, but as far as I can tell the
>result is about the same.
>
>Thanks,
>Andreas
>

There's a few differences:

- by tripping onto [term](...) as accepted syntax for an obviously 
  invalid function call, we can *add* semantics to an expression that 
  had none rather than overloading those of an exisiting construct
- by virtue of not being a monad fancyflow is also far less generic and 
  doesn't allow overloading of the >>= nor return operators, which gives 
  Erlando a lot of flexibility that fancyflow does not have
- fancyflow does not use monad terminology, and hence should be immune 
  to burrito-related tutorials
- we avoid all of that pesky imperative programming by banishing the 
  word 'do' and instead using the descriptive words 'pipe' and 'maybe', 
  which totally express what is going to happen
- the monadic approach can be composed and nested, fancyflow isn't that 
  fancy; this probably brings it to the same place as 'fancy feast' cat 
  food, which I am told isn't that fancy of a feast*
- the 'cut' syntax is bound in context a bit more, which lets me work 
  around this Erlando issue I had opened in 2011 
  https://github.com/rabbitmq/erlando/issues/2 (props to them for never 
  closing it in anger)
- Erlando was possibly intended to actually be used by its authors, 
  whereas fancyflow was just me trying to toy with that idea I had 
  posted in the mailing list a few years ago

Again, I can't really advise using either of these libraries in a code 
base. One of the big strengths of Erlang is its simplicity and ease of 
jumping into code, any code, and easily understand what it does. The use 
of parse transforms to overload or add new semantic meaning to existing 
constructs is a thing that should be done with care.

There was certainly not that much care involved in fancyflow's case, 
since the RFC process involved me writing on a mailing list and then 
saying "screw this it's april 1st let's try it" about 2 years after.

Regards,
Fred.

* as a general rule, if a thing needs to assert what it is in the name, 
  it likely does not bear that property. To wit:

  - 'fancy feast' does not make for fancy feasts, as mentioned earlier
  - the S in SOAP stands for 'simple' which by now should have us all 
    laughing; see also a bunch of amazon services
  - restaurants with 'gourmet' in their names (or brightly flashing neon 
    signs) tend not to inspire much confidence
  - calling yourself a classy person likely means you are not that 
    classy to begin with, though if you refer to marxist ideals then it 
    may be an easier point to debate
  - I guess if you have an object oriented language you could also 
    describe it as classy and it would be technically correct
  - flame decals and/or stripes on a car do not make the car go faster, 
    no matter what my former 4 years old self would like to assert.  
    Dodge vipers ain't that cool, 4 years old Fred! You'll drive a 
    humble grey versa for at least 10 years anyway when you're older so 
    don't pretend to be that hot