`is_something` versus `something?`

[Вячеслав Павлутин]

Elixir provides predicate method such as `match?` that are expected to return a boolean. At the same time Elixir provides `is_*` functions with the same behavior.

As I understand it's for compatibility with similar Erlang functions. My question, then, isn't it would be more reasonable to provide `*?` functions where possible

since we'd like the language's API to be consistent. For instance, `Integer.is_even` could have an `Integer.even?` alias.

Perhaps, there may be certain implementation-specific reasons why it can't be done and my question is extremely silly, so I'm sorry in advance. :)

[eksperimental]

the convention is that is_* functions to be used in guards.
and whenever you have a "?" ending it means that they will return a
boolean, but are not allowed in guards,
that's pretty much it.

On Fri, 3 Apr 2015 10:04:45 -0700 (PDT)
Вячеслав Павлутин <sl.pa...@gmail.com> wrote:

> Elixir provides predicate method such as `*match?*` that are expected
> to return a boolean. At the same time Elixir provides `*is_**`

> functions with the same behavior.
> As I understand it's for compatibility with similar Erlang functions.

> My question, then, isn't it would be more reasonable to provide `**?`
> *functions where possible

> since we'd like the language's API to be consistent. For instance, `

> *Integer.is_even*` could have an `*Integer.even?*` alias.

[Вячеслав Павлутин]

It's still unclear why we can't have aliases that provide the same functionality beyond guard clauses for the matter of consistency.

For novices it could be difficult to understand why we need to keep both `is_*` and `?` functions and why API provides one or another.

I will investigate further into the matter then. Thanks for your answer.

[Lennart Fridén]

You might want to give my Guardsafe library a spin if you prefer using "something?" over "is_something". https://github.com/DevL/guardsafe

Cheers!

/Lennart

[eksperimental]

Hi Вячеслав:

the reason behind that is that there is a limited set of expresions and
therefore functions that can be executed in guards
so all the functions starting with "is_" are the ones that will work in
guard,
I recommend you to read:
http://elixir-lang.org/getting-started/case-cond-and-if.html#expressions-in-guard-clauses
Expressions in guard clauses

The Erlang Virtual Machine (VM) only allows a limited set of
expressions in guards:
* comparison operators (==, !=, ===, !==, >, <, <=, >=)
* boolean operators (and, or) and negation operators (not, !)
* arithmetic operators (+, -, *, /)
* <> and ++ as long as the left side is a literal
* the in operator
* all the following type check functions:
... just read the article for the full list:
http://elixir-lang.org/getting-started/case-cond-and-if.html#expressions-in-guard-clauses
* and some other functions..

if you want to create your own function/macro to be used in guards, you
can check the source-code for is_record/1 and is_record/2
https://github.com/elixir-lang/elixir/blob/50ab29ffb1217779ed4a38ff41e551c17e2011e3/lib/elixir/lib/record.ex#L72

I hope things are more clear now.
cheers,

On Fri, 3 Apr 2015 14:05:14 -0700 (PDT)
Вячеслав Павлутин <sl.pa...@gmail.com> wrote:

> It's still unclear why we can't have aliases that provide the same
> functionality beyond guard clauses for the matter of consistency.
> For novices it could be difficult to understand why we need to keep

> both ` *is_**` and `*?*` functions and why API provides one or

[Вячеслав Павлутин]

I understand that guard clauses allow only a narrow set of expressions in it. My question originally was addressed at  the matter of consistency in the source code, not

the lack of understanding the difference between the two. I was just curious why we need to keep both options when we can get rid of one of them. I'm getting used to it, though.

 

Thanks for the link to an example of implementing a guard-compatible function. It was helpful in learning, since I'm a beginner as you might notice. Very much appreciated.

And thanks to José Valim and other contributors. They're making a great work to assemble an excellent programming language. Good design decisions are all over the road. Much love.

[Вячеслав Павлутин]

Thanks, but I don't tend to use guard clauses very much and when do use them I prefer to stick to the idiom. But thanks again, Lennart.

[eksperimental]

i totally missed your comment about the aliases..
I guess it will create a lot of confusion, if you see even? many times
in code, you will tend to thing that is_nil? doesn't exist.
is_ functions are pretty much for type checking, with the exception of
is_even, is_odd, is_number

On Fri, 3 Apr 2015 20:18:59 -0700 (PDT)