[erlang-questions] Why does Core Erlang have a catch-all clause for everything?

[Richard Carlsson]

The point of leaving it as undefined behaviour is so that the specification
of case clauses is free from any hardwired assumptions about what is the
right thing to do if there is no match.

This is both in order to let the Core Erlang spec be decoupled from any
particular implementation of Erlang or any other language using Core
Erlang, now or in the future, and to force the actual behaviour to be
expressed as explicit code that can be processed by tools rather than being
baked into the behaviour of the case switch (meaning that all tools would
need to know about it, add extra code for it, and get it right every time).


        /Richard

2018-01-19 11:48 GMT+01:00 Anthony Ramine <n.oxyde@REDACTED>:

> It is undefined behaviour from Core Erlang's POV to have a value that
> doesn't match against any case arm. There are other similar UB cases, such
> as a Core Erlang clause guard not evaluating to a boolean.
>
> See the spec for more details.
>
> https://www.it.uu.se/research/group/hipe/cerl/doc/core_erlang-1.0.3.pdf
>
> > Le 19 janv. 2018 à 11:45, Loïc Hoguin <essen@REDACTED> a écrit :
> >
> > Hello,
> >
> > A short discussion about exceptions left us wondering why generated Core
> Erlang code always has a catch-all clause for things that don't match? Is
> it so it can throw a specific exception? And what would happen if the
> catch-all was missing and the input failed to match?
> >
> > Cheers,
> >
> > --
> > Loïc Hoguin
> > https://ninenines.eu
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180119/3b98e2f4/attachment.htm>