[m-dev.] tightening up require_complete_switch
Zoltan Somogyi
zoltan.somogyi at runbox.com
Tue Apr 19 17:27:16 AEST 2016
On Tue, 19 Apr 2016 14:05:32 +1000, Peter Wang <novalazy at gmail.com> wrote:
> > Why? Don't you find the variable useful documentation? There are some
> > disjunctions that can be looked at as switches on *more* than one variable
> > (e.g. assoc_list.from_corresponding_lists); I find the variable name slightly
> > useful in that it tells me "you don't have to search for another variable
> > that this disjunction is a switch on".
>
> Perhaps, only just useful.
Does this, ...
> > We could in future even use the
> > variable name in the scope to control switch detection, by checking
> > whether the disjunction it is given is a switch on the named variable
> > *before* checking to see if it is a switch on any other variables.
> > (In fact, I think this should be easy to implement.)
>
> True.
... and this mean that you don't object to keeping the [Var] part?
> How about this?
>
> require_complete_switch [VAR] GOAL
>
> A switch completeness check, typically used to enhance the
> robustness of code.
>
> If GOAL is a switch on VAR and the switch is complete, i.e.
> the switch has an arm for every function symbol that VAR
> could be bound to at this point in the code, then
> `require_complete_switch [VAR] GOAL' is equivalent to GOAL.
>
> If GOAL is a switch on VAR but is @emph{not} complete, or GOAL is
> not a switch at all, then the compiler is required to generate an
> error message.
Thanks. I adopted your proposed language, modulo a minor clarification:
s/not a switch at all/not a switch on VAR at all/
> (Your diff had the old wording "for all the function symbols in
> the type of @var{Var}" in the positive case.)
You are right, that was wrong. The above language fixes it.
Zoltan.
More information about the developers
mailing list