[erlang-questions] Guards syntax for multiple values

[Brady Powers]

 I personally have always wanted to see it possible to specify certain functions as "pure" so that they can be used in a guard. 
I understand why using any random function in a guard is a bad idea. But some ability to override should be possible, even if it emitted a warning of some sort. 

Typically, I've seen patterns like so when needing to use a custom function in a guard:
```
function(X) ->
    case custom_guard(X) of
        true -> function_guarded(X)
    end.
```
While a terrible example, the point is there are ways to work around it, and sometimes people have to work around it. So the restriction is bypassed anyway, surely there is a way to dissuade people from using any function in a guard, but allowing people to carefully write a function that would be guard safe. Parse transforms can be way more dangerous, and yet we still allow them, and their use is certainly dissuaded. 

Personally, I think just marking a function as "pure" should be enough to allow it in a guard, possibly with a warning. No need to auto-detect what functions are pure or not, though possibly we could double check the "pure" functions to verify they only call out to the current "blessed" functions and others marked as "pure".     On Monday, March 25, 2019, 11:51:04 AM EDT, Dan Sommers <2QdxY4RzWzUUiLuE@REDACTED> wrote:  
 
 On 3/25/19 9:00 AM, Florent Gallaire wrote:

 > Yes excuse me for my wrong sentence. I was talking about
 > lists:member/2 in a guard:
 > is_fraction(X) when lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒") -> true.
 > which is not possible.

http://erlang.org/doc/reference_manual/expressions.html#guard-sequences
explains

    The set of valid guard expressions (sometimes called guard tests) is
    a subset of the set of valid Erlang expressions. The reason for
    restricting the set of valid expressions is that evaluation of a
    guard expression must be guaranteed to be free of side
    effects. Valid guard expressions are the following:

and later on, there's a list of "blessed" functions that are allowed in
guard expressions.

My experience with Erlang is entirely as a hobbyist, but what are the
pros, cons, and possibilities of expanding the list of such "blessed"
functions?  Many of the functions in the list module have no side
effects, and could make some Erlang code more concise.

That said, I've also discovered (or more likely rediscovered) that
breaking down such functions and guard clauses one more layer also leads
to more concise code.  I don't know Florent's use case, but I could
imagine breaking it down one more level into something like this:

process(X) ->
    Classification = classify(X),
    process(X, Classification).

process(X, fraction) ->
    %% process fractions here
    ok;
process(X, url_character) ->
    %% process URL characters here
    ok;
process(X, whitespace) ->
    %% process whitespace here
    ok;
process(X, UnknownClassification) ->
    %% handle an unknown X here
    ok.

Or maybe all that does is push the problem into the implementation
of classify/1.
_______________________________________________
erlang-questions mailing list
erlang-questions@REDACTED
http://erlang.org/mailman/listinfo/erlang-questions
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190325/86343684/attachment.htm>