[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