[erlang-questions] Must and May convention

[zxq9]

On 2017年09月28日 木曜日 07:43:32 Richard Bowker wrote:
> As Fred already said above, most of these flows are forms of the
> "Railway Oriented Programming" interpretation of Monads. i.e. do
> next step if ok, else shortcut to the end. the "with" concept in
> Elixir may be useful for comparison.

Syntactic sugar is syntactic sugar, and generally undesirable imo.
In this case syntactic sugar over pipeline functions which seem to
exist merely to bewilder those who have yet to encounter their
specially sugary syntactic forms in lang X or Y just yet.

It is nearly always more interesting and self-consistent to build
constructs such as this from the basic tools of the language, IN the
language, and keep that language as small as possible than to cough
up new syntax for each type of thing. It is a particularly bad sign
when a language continues to accumulate new features and syntax well
beyond its first year in production, especially when they are nifty
little "me, too!" sort of sugary cheats.

What if, for example, you want to continue evaluation to the end of
the steps specifically because of some side-effects desired instead
of shortcutting? Building a dead-obvious pipeline that does just that
and says so in the name is not as likely to confuse someone as
introducing new syntax to cover that one case plus the original shortcut
one. Two syntaxes for two types of pipelines... but there are many more
kinds of pipelines. So where do we stop?

"Oh, I know! We'll add a new rule that you can 'hook stuff into this'
as it zips along!" Great. One more thing to try to teach and debug...
when the original construct, if left in the form of functions, would have
been as concise, as clear, and not have wasted anyone's time learning
which non alphanumeric chars on their keyboard they need to be more
closely aware of.

This is the same argument I have, generally speaking, against use
of the `class` keyword to special-case creation of dispatching closures
and brand them "objects" -- particularly when the language in question
doesn't even bother to actually enforce encapsulation. This is also the
reason I dislike XML -- semantic ambiguity grows from having a variety
of equivalent expressions and ruins the party for everyone.

-Craig