[erlang-questions] style question - best way to test multiple non-guard conditions sequentially

[Anthony Ramine]

Hello,

I’ve thought about this again and realised that there is a technical reason not to expand cond expressions to nested cases directly. That reason is scoping rules.

Let’s assume we compile this expression naively to nested cases:

	cond X = false -> X;
	     X = true -> X
	end

=>

	case X = false of
	    true -> X;
	    false ->
	        case X = true of
	            true -> X;
	        end
	end.

I would be *extremely* surprised that such an expression would crash with badmatch instead of returning true as it should.

Regards,

-- 
Anthony Ramine

Le 9 juil. 2013 à 00:12, Richard A. O'Keefe <ok@REDACTED> a écrit :

> 
> On 8/07/2013, at 8:35 PM, Anthony Ramine wrote:
> 
>> No this example was just confusing, what I meant is that if you need a warning "no clause will ever match" in the case of an explicit "case foobar of true -> ok; false -> ok end" and a warning "this clause will crash" in the case of "cond foobar -> ok; true -> ok end". There is no rewording that makes the warning fit in both situations, they need to be handled separately.
> 
> In the English text here you have an "if" with no consequent.
> 
> 	case foobar of true -> ok ; false -> ok end
> 
> Yes, it is appropriate to say "No matching clause" here.
> 
> As for
> 
> 	cond foobar -> {ok,1} ; true-> {ok,2} end
> 
> this should *BE*
> 
> 	case foobar
>          of true -> {ok,1}
>           ; false -> case true of true -> {ok,2} end
>        end
> 
> and no error message is appropriate here because there
> *is* a clause that will match and be selected.  It is only
> true that the two situations need separate handling because
> one of them is not an error.
> 
> Another not-entirely-unreasonable translation of
> 
> 	cond C1 -> B1 ; ... ; Cn -> Bn end
> 
> would be
> 
> 	case (C1 andalso true)
> 	  of true -> B1
>           ; false -> ...
> 		case (Cn andalso true)
> 		  of true -> Bn
>                end
> 	end
> 
> and in this case you might just possibly get a warning from
> the compiler that might just possibly actually be useful
> (unlike 'this clause will crash'): you might be told
> "expression cannot be Boolean".
> 
> It could *never* be appropriate to say "this clause will crash"
> for the simple reason that it's *not* the clause that would
> crash but the *condition* of the clause.  "This condition cannot
> be Boolean" might make sense, but not the other.
>