<html><head></head><body><div class="ydp90a9d76fyahoo-style-wrap" style="font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:13px;"><div></div>
<div>I personally have always wanted to see it possible to specify certain functions as "pure" so that they can be used in a guard. <br>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. <br><br>Typically, I've seen patterns like so when needing to use a custom function in a guard:<br>```<br>function(X) -><br> case custom_guard(X) of<br> true -> function_guarded(X)<br> end.<br>```</div><div><br>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. <br><br>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". </div>
</div><div id="yahoo_quoted_3992999318" class="yahoo_quoted">
<div style="font-family:'Helvetica Neue', Helvetica, Arial, sans-serif;font-size:13px;color:#26282a;">
<div>
On Monday, March 25, 2019, 11:51:04 AM EDT, Dan Sommers <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
</div>
<div><br></div>
<div><br></div>
<div><div dir="ltr">On 3/25/19 9:00 AM, Florent Gallaire wrote:<br clear="none"><br clear="none"> > Yes excuse me for my wrong sentence. I was talking about<br clear="none"> > lists:member/2 in a guard:<br clear="none"> > is_fraction(X) when lists:member(X, "½⅓⅔¼¾⅕⅖⅗⅘⅙⅚⅐⅛⅜⅝⅞⅑⅒") -> true.<br clear="none"> > which is not possible.<br clear="none"><br clear="none"><a shape="rect" href="http://erlang.org/doc/reference_manual/expressions.html#guard-sequences" target="_blank">http://erlang.org/doc/reference_manual/expressions.html#guard-sequences</a><br clear="none">explains<br clear="none"><br clear="none"> The set of valid guard expressions (sometimes called guard tests) is<br clear="none"> a subset of the set of valid Erlang expressions. The reason for<br clear="none"> restricting the set of valid expressions is that evaluation of a<br clear="none"> guard expression must be guaranteed to be free of side<br clear="none"> effects. Valid guard expressions are the following:<br clear="none"><br clear="none">and later on, there's a list of "blessed" functions that are allowed in<br clear="none">guard expressions.<br clear="none"><br clear="none">My experience with Erlang is entirely as a hobbyist, but what are the<br clear="none">pros, cons, and possibilities of expanding the list of such "blessed"<br clear="none">functions? Many of the functions in the list module have no side<br clear="none">effects, and could make some Erlang code more concise.<br clear="none"><br clear="none">That said, I've also discovered (or more likely rediscovered) that<br clear="none">breaking down such functions and guard clauses one more layer also leads<br clear="none">to more concise code. I don't know Florent's use case, but I could<br clear="none">imagine breaking it down one more level into something like this:<br clear="none"><br clear="none">process(X) -><br clear="none"> Classification = classify(X),<br clear="none"> process(X, Classification).<br clear="none"><br clear="none">process(X, fraction) -><br clear="none"> %% process fractions here<br clear="none"> ok;<br clear="none">process(X, url_character) -><br clear="none"> %% process URL characters here<br clear="none"> ok;<br clear="none">process(X, whitespace) -><br clear="none"> %% process whitespace here<br clear="none"> ok;<br clear="none">process(X, UnknownClassification) -><br clear="none"> %% handle an unknown X here<br clear="none"> ok.<br clear="none"><br clear="none">Or maybe all that does is push the problem into the implementation<br clear="none">of classify/1.<div class="yqt8133623820" id="yqtfd36979"><br clear="none">_______________________________________________<br clear="none">erlang-questions mailing list<br clear="none"><a shape="rect" ymailto="mailto:erlang-questions@erlang.org" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br clear="none"><a shape="rect" href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br clear="none"></div></div></div>
</div>
</div></body></html>