[erlang-questions] Local namespaces in case/try

Richard O'Keefe ok@REDACTED
Wed Jul 11 03:12:37 CEST 2012


On 10/07/2012, at 8:43 PM, Dmitry Groshev wrote:

> Is there any reason why we don't have them?

Yes.

> It's quite annoying to
> have potential error in places like this:
> 
> case do_something() of
>    {ok, Result} -> Result;
>    {error, Error} -> Error
> end,
> case do_another() of
>    {ok, Result} -> Result;
>    {error, Error} -> Error
> 
> end,

I *really* don't want to have to read code like that.
It's a big help to *me* in reading a function if one
name has one meaning throughout a clause.

Heck, despite having been an Algol fan since 1960, I
religiously use -Wshadow in gcc.  I've seen (and made!)
enough mistakes with two variables with the same name
too close together not to.

If Erlang did have this "feature" I would be agitating
for its removal.

If there is an error, why is the first case falling
through into the second?

Can you give us an example where this actually makes sense?

This really has very little to do with 'if', 'case', or 'try'.
There was a proposal years ago that

    begin E1 within E2 end

should be like SML's

    local D1 within D2 end

namely that bindings introduced in (E1,D1) are
visible in (E2,D2) but not exported, while
bindings introduced in (E2,D2) are exported.

Failing that,

	-define(BEGIN, ((fun () ->).
	-define(END,   end)())).
	...
	?BEGIN
	    case do_something()
	      of {ok, Result} -> Result
	       ; {error, Error} -> Error
	    end
	?END,
	?BEGIN
	    case do_another()
	      of {ok, Result} -> Result
	       ; {error, Error} -> Error
	    end
	?END,

should let you do what you want.  The version of Erlang I'm using
does not open-code (fun (T1,...,Tn) -> B end)(E1, ..., En), but I
believe there's no reason why it couldn't, and in the presence of
the preprocessor it's a useful thing to do.  Even without that, I
suspect that the overhead of making a closure and calling it will
be hard for you to measure.





More information about the erlang-questions mailing list