[erlang-questions] Guards syntax for multiple values

[Dmitry Belyaev]

If I remember correctly Idris has eager evaluation and also defines 'if then else' in the standard library. So I believe lazy evaluation is not really required for that.

On 27 March 2019 23:48:10 GMT+11:00, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
>On Wed, Mar 27, 2019 at 8:52 AM <zxq9@REDACTED> wrote:
>
>> How much once-cool-but-now-unused syntax is there in C++, Haskell,
>Ruby,
>> etc?
>>
>>
>Haskell is the exception to the rule. In Haskell,  you can define your
>own
>operators and give them precedence. But they are just functions in the
>core
>language. There are very few restricted keywords in Haskell (98): 28
>identifiers such as 'case', 'where', 'deriving', 'class', ... and 27
>symbols such as '*', '!', ... The rest are libraries defining their own
>operators. Almost nothing in Haskell has special handling requiring
>language extension.
>
>Proof Assistants take this idea even further by allowing mixfix
>operators
>to be defined. Agda allows us to define if-then-else:
>
>if_then_else_ : ∀ {a} {A : Set a} → Bool → A → A → A
>if true then t else f = t
>if false then t else f = f
>
>Where the underscores say where the holes are in the expression. That
>is,
>the construct is not built into the language. It is *defined* as part
>of
>the standard library[*]. This also allows far more complicated rules
>such
>as (brace for unicode!) x ·⟨ M ⟩ y, which allows us to have an
>operation
>(the dot) under a given magma[0] for elements x and y of that type.
>
>Personal opinion: It is often better to add generic functionality to a
>language then special case handling. The compiler is free to optimize
>the
>generic situation if it can see some specific structure, and this has
>long-term support. Whereas the other way is far more restrictive
>(though it
>is often alluring). However, syntactic sugar might be necessary in
>certain
>cases, as it makes code easier to read, and often more convenient to
>work
>with. Add sugar, but add it sparingly.
>
>[*] Note this requires evaluation order to be lazy. You can only
>evaluate
>the two branches once you know the result of the conditional.
>Otherwise,
>you don't have the usual semantics of this construct, which is why it
>is
>often implement as a built-in into the language. If you have
>macro-expansion, you can build it on top of case, however.
>[0] https://en.wikipedia.org/wiki/Magma_(algebra)

-- 
Kind regards,
Dmitry Belyaev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190328/5b5b880f/attachment.htm>