Short circuit behaviour is unexpected

[richardkapolnai-da]

Background: DAML has strict function call evaluation and not lazy, meaning that in a function call f (complex expression1) (complex expression2) each complex expression{1,2} is evaluated first and f is called applied only after. There are four exceptions though: && || when unless, see https://github.com/digital-asset/daml/blob/master/compiler/damlc/tests/daml-test-files/ShortCircuit.daml.

The problem: It is a bit difficult to find out what the exceptions are of strict function evaluation. Moreover, reading the docs Functional Programming 101 that "some magic" makes them happening, kind of destroyes the confidence of a reader on understanding evaluation. Programmers are used to short circuit operators in strict languages (e.g. C++ or Erlang), but "regular" functions with complier magic needs some explanation.

Some ideas:

• make it super-clear in the document, in multiple locations
• make it part of the language, elevating "compiler magic" to "compiling the language"
• eliminate short circuit behaviour

[bame-da]

Eliminating the behaviour is quite an impactful breaking change so not really on the cards until the next major language version. Improving docs is always welcome, but I don't know where you think this information is missing right now.

I don't really see a clear distinction between something being "part of the language" or being a "regular function". Almost all DAML inbuilts are wrapped in regular functions and types. So I'd simply consider a function like when which exhibits special behaviour as "part of the language".

[richardkapolnai-da]

I have some idea on documenting them in more detail:

• https://docs.daml.com/daml/reference/expressions.html#logical-operators Does not mention && and || are not strict
• Doc mentions DAML is strict, but it does not explain how is that possible that when and unless are not. Also not clear if a user can write such a function or not
• There is no page listing or short circuit functions. If there are exceptions, it's nice to know which ones are.
• when and unless API doc says they have short circuit behaviour, but could also detail that they are the rare exception, this is not provided by DAML in general

[sofiafaro-da]

In general I'm not in favor of changing these behaviors, since this what is commonly expected in a strict language – even C has short-circuiting semantics for && and ||.

These short-circuiting functions are all well documented in the standard library docs:

(&&) here:

Boolean “and”. This function has short-circuiting semantics, i.e., when both arguments are present and the first arguments evaluates to ‘False’, the second argument is not evaluated at all.

(||) here:

Boolean “or”. This function has short-circuiting semantics, i.e., when both arguments are present and the first arguments evaluates to ‘True’, the second argument is not evaluated at all.

when here:

This function has short-circuiting semantics, i.e., when both arguments are present and the first arguments evaluates to False, the second argument is not evaluated at all.

unless here:

This function has short-circuiting semantics, i.e., when both arguments are present and the first arguments evaluates to False, the second argument is not evaluated at all.