[erlang-questions] Floating guard sequences

[fess]

On Feb 19, 2009, at 7:48 AM, Dominic Williams wrote:

> Hello Michael,
>
>> This is a very preliminary proposal to extend Erlang's
>> guard syntax (based on an idea I briefly mentioned in
>> another thread).  I'd like to hear people's
>> reactions....if there is interest, and if the OTP team
>> doesn't say it's impossible for some reason, I'd be happy
>> to write an EEP.
>
> First, I find the resulting code very hard to read. Maybe
> I'm just used to the current language, but I know that I
> think first in terms of structure and algorithm, and only
> secondarily in terms of typing. With the floating guards
> interleaved with the structure of terms, I can't see what's
> happening anymore.


I think the first two cases Michael mentioned, floating guards in a  
function clause or case clause,  do look more complicated so you  
wouldn't write them that way.  However I find that I often reduce a  
rather common but complex record match in function clauses to a  
macro.  it makes a rather complex record match much simpler, but you  
can't use guards there, so this proposal would allow that.

So, I think that it could improve readability in the macro case, but  
it sounds somewhat like a fake way using them internally to do  
something like Richards abstract patterns.

also floating guards on the LHS of a match seem like they could make  
code much more concise and readable, and erlang-like [ to me ]


   { X when is_integer(X), [ "x" | Rest ] } = string:to_integer(Str),
   { Y when is_integer(Y), _ } = string:to_integer(Rest),

vs:

   Rest = case string:to_integer(Str) of
     { X, [ $x | R ] } when is_integer(X) -> R
   end,
   case string:to_integer(Rest) of
     { Y, _ } when is_integer(Y) -> { X, Y }
   end.

this because string:to_integer/1 returns a 2 element tuple on success  
or failure,  making the standard idiom of matching with '= ' or  
failing need a guard.

maybe I've helped show how this proposal could improve readability?


> Secondly, I am not favourable to anything which allows the
> same code to be written two ways purely as a matter of
> taste.

You mean like case vs if ?  *grin*  [ I'm just joking there. ]

--fess



--fess