[erlang-questions] Reassigning variables

[Richard O'Keefe]

On 18 Mar 2009, at 10:19 am, Matthew Dempsky wrote:
> I disagree.  There are ways that reassignment can make code easier to
> analyze, but I'm not suggesting people use reassignment in those
> cases.

_Easier_ to analyse?  I'd love to see an example.
>
>
> Similarly, Erlang doesn't support 'return', but our ad server has
> enough business logic where the code would be much simpler if it did.
> We had some code that was effectively:
>
>    if requested ad size is bad:
>        return {skip, bad_size}
>    if the game has ads disabled:
>        return {skip, disabled}
>    if the game is filtering a domain:
>        return {skip, domain_filtered}
>    return choose_ad()
>

This is a very familiar pattern from Smalltalk.
But surely you don't need a 'return' for that.

> I rewrote this code in 'Erlang style' with a list of funs to check,
> and to short-circuit on the first that returns a skip, when I last
> added to it, and so incrementally it's much less work to add new
> checks than the old code.

I wouldn't have called called that "Erlang style".

There's an EEP to allow "un-nested" cases.  This will allow

	case requested_ad_size(...)
	  of bad      -> {skip, bad_size}
	; or case ad_status(...)
	  of disabled -> {skip, disabled}
	; or case game_filtering(...)
	  of filtered -> {skip, domain_filtered}
	   ; _ ->
	     choose_ad()
	end

Last I heard there was a good chance this would be adopted
but with a different syntax (just dropping the 'or', I think,
but don't quote me).

Absent that, I'd probably do

	case { requested_ad_size(...)
	     , ad_status(...)
	     , game_filtering(...)
	     }
	  of {bad,_,_}      -> {skip, bad_size}
	   ; {_,disabled,_} -> [skip, disabled}
	   ; {_,_,filtered} -> {skip, domain_filtered}
	   ; _ ->
	     choose_ad()
	end

Admittedly, this evaluates all the criteria, but then,
in what we are expecting to be the usual case, we're
going to do that _anyway_.  [If this example reminds you
of a decision table, it should.  Arguably a decision table
is a 'case' of this kind, but lazily evaluated.]

> But it's stupid.

Yes, it is.  The 'case' expression above is not, however.
>
> Programmers understand how variable reassignment and multiple function
> call returns work: every beginner programming language includes them.

Not so:  Melbourne University used to use Miranda as their beginner
programming language, and it doesn't include those things.
For that matter, Monash Caulfield used Scheme as their introductory
language (replacing 3 semesters of COBOL with 1 semester of Scheme
followed by 1 semester of COBOL resulted in students learning
*more* COBOL) and the subset of Scheme they were taught did not
include call-with-current-continuation, so did not have multiple
exits.  (These were _not_ advanced CS students; Monash Caulfield
used to be a technical college.  These days they probably teach VB.)