How do you disable specific warnings ?

[mraptor]

I want to suppress this warning :

warning: clauses for the same def should be grouped together, ...

how would I do that ?

[Alexei Sholik]

You can suppress that by putting all clauses for the same function together.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/9fcd5474-8494-4e8d-81ad-99700040495a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Onorio Catenacci]

Literally LOL!

[Alex Shneyderman]

Sometimes this does not make logical sense. Logical is relative to the developer who writes this code - so this sort of thing falls under the category of having no right/wrong way of doing things but elixir does introduce a possibility. This is where I prefer erlang way - you simply can not disperse your clauses all over - you have to pull them all together, otherwise you can not compile your module.

As far as I know there is no way to suppress these warnings. There are only 4 recognizable elixirc_options - :docs, :debug_info, :ignore_module_conflict, :warnings_as_errors.

On Monday, October 12, 2015 at 1:34:40 AM UTC-4, Alexei Sholik wrote:

[José Valim]

> you simply can not disperse your clauses all over - you have to pull them all together, otherwise you can not compile your module.

Honestly, releasing/deploying code with warnings is not an option in my book. The reason we emit warnings instead of errors is because there is no reason to make your compilation fail right out of the box, better to collect the warnings and show them for all files, instead of have the frustrating process of fixing one error just for another one to show up. That's also why we don't plan to provide options for disabling warnings: they should be fixed, even if they don't error out upfront.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/720b5816-6dcb-4384-8ee7-20f7055e9836%40googlegroups.com.

[Onorio Catenacci]

I can see disabling warnings while one is developing code though.  I prefer to treat warnings as errors--developing code or not.  And sometimes while I'm working on code I'll put in something that I know will throw a warning.  I will go back and fix it but in the meantime I don't want it to keep my source from building. 

I guess I'm just saying while I don't think mraptor needs to disable this particular warning there are legitimate cases where the ability to disable a warning is handy--if only so I don't have to disrupt my development flow dealing with warnings that I know will get fixed.  But disabling warnings can be a slippery slope because if you add the ability to disable warnings it's not a long step to simply ignoring them all together.

--

Onorio

[mraptor]

I don't want to :)
I'm grouping them on different principle, not based on name, but on functionality.

On Monday, October 12, 2015 at 1:34:40 AM UTC-4, Alexei Sholik wrote:

[Kevin Montuori]

>>>>> "m" == mraptor <mra...@gmail.com> writes:

m> I'm grouping them on different principle, not based on name, but
m> on functionality.

It's easy (and fast) enough to do something like:

def event(:x, var), do: one_thing(var)
def event(:y, var), do: another_thing(var)
def event(:z, var), do: something_else_entirely(var)

and then your maintainers (or your future self) won't curse you forever.
The follow on functions can then be grouped as you see fit.

Although there are no doubt pathalogical cases, what you describe (a
multi-headed function doing different enough stuff that you want to
separate the heads in the source) strikes me as an anti-pattern.


k.

--
Kevin Montuori
mont...@gmail.com

[José Valim]

It's easy (and fast) enough to do something like:

  def event(:x, var), do: one_thing(var)
  def event(:y, var), do: another_thing(var)
  def event(:z, var), do: something_else_entirely(var)

and then your maintainers (or your future self) won't curse you forever.
The follow on functions can then be grouped as you see fit.

This is great feedback! +1

[Sitaram Chamarty]

On 12/10/15 18:32, José Valim wrote:
>> you simply can not disperse your clauses all over - you have to pull them all together, otherwise you can not compile your module.
>
> Honestly, releasing/deploying code with warnings is not an option in
> my book. The reason we emit warnings instead of errors is because
> there is no reason to make your compilation fail right out of the box,
> better to collect the warnings and show them for all files, instead of
> have the frustrating process of fixing one error just for another one

Does this mean that, ideally, you'd turn all warnings into errors
without providing an option to bypass?

If you intend to do that at some undefined point in the future, please
consider restricting it to MIX_ENV=prod, and leave the normal (dev)
compiles as they currently are.

Because a lot depends on what the warning is. For example, unused
variable warnings are relatively benign. It's just saying "hint hint,
your stated intent and your actual use are at odds!".

> to show up. That's also why we don't plan to provide options for
> disabling warnings: they should be fixed, even if they don't error out
> upfront.

In this specific case, I don't even understand *why* the warning exists.
The code clearly works (I just tried a quick test) so what's the issue?

I imagine there's some nuance/subtlety deep within Erlang/Elixir that is
hard to explain; is that what it is?

regards
sitaram

>
>
>
> *José Valim*
> www.plataformatec.com.br <http://www.plataformatec.com.br/>

> Skype: jv.ptec
> Founder and Director of R&D
>

> On Mon, Oct 12, 2015 at 7:57 AM, Alex Shneyderman <a.shne...@gmail.com <mailto:a.shne...@gmail.com>> wrote:
>
> Sometimes this does not make logical sense. Logical is relative to the developer who writes this code - so this sort of thing falls under the category of having no right/wrong way of doing things but elixir does introduce a possibility. This is where I prefer erlang way - you simply can not disperse your clauses all over - you have to pull them all together, otherwise you can not compile your module.
>
> As far as I know there is no way to suppress these warnings. There are only 4 recognizable elixirc_options - :docs, :debug_info, :ignore_module_conflict, :warnings_as_errors.
>
> On Monday, October 12, 2015 at 1:34:40 AM UTC-4, Alexei Sholik wrote:
>
> You can suppress that by putting all clauses for the same function together.
>
> On Mon, Oct 12, 2015 at 4:40 AM, mraptor <mra...@gmail.com> wrote:
>
> I want to suppress this warning :
>
> warning: clauses for the same def should be grouped together, ...
>
> how would I do that ?
>
> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/9fcd5474-8494-4e8d-81ad-99700040495a%40googlegroups.com <https://groups.google.com/d/msgid/elixir-lang-talk/9fcd5474-8494-4e8d-81ad-99700040495a%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-ta...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/720b5816-6dcb-4384-8ee7-20f7055e9836%40googlegroups.com <https://groups.google.com/d/msgid/elixir-lang-talk/720b5816-6dcb-4384-8ee7-20f7055e9836%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-ta...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAGnRm4JcA7igj8Yd%3D%3DFFq-HngJ0Z6ZJgdm9S-kHsdLoQK3wu7w%40mail.gmail.com <https://groups.google.com/d/msgid/elixir-lang-talk/CAGnRm4JcA7igj8Yd%3D%3DFFq-HngJ0Z6ZJgdm9S-kHsdLoQK3wu7w%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Sitaram Chamarty]

That sounds like a *style* issue, which is often subjective. Should that
even *be* a compiler warning?

[T Ty]

IMHO The pain comes after ..... 2+ years down the road when you are looking at the code again and wondering where did the rest go because another definition is tuck between two unrelated functions.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/561CC0BA.7040706%40gmail.com.

[Alexei Sholik]

It's more than just a style issue. Function clauses are checked in a specific order at runtime to decide which one to invoke. Changing the order of clauses in your source code will change the semantics of your program.

Spreading clauses all over a module and interleaving them with other functions will only make it more difficult to read the code and make sure it's correct.

So what the Elixir compiler does is the gentle way to handle this issue. An Erlang program wouldn't even compile if it had interleaved function clauses.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/561CC0BA.7040706%40gmail.com.

[Sitaram Chamarty]

On 13/10/15 16:34, Alexei Sholik wrote:
> It's more than just a style issue. Function clauses are checked in a
> specific order at runtime to decide which one to invoke. Changing the
> order of clauses in your source code will change the semantics of your
> program.

This is a valid point but it is not the issue that is in question here,
as far as I can tell.

You appear to be talking about this warning:

aa.ex:5: warning: this clause cannot match because a previous clause
at line 2 always matches

while the question was about this warning:

aa.ex:8: warning: clauses for the same def should be grouped
together, def aa/1 was previously defined (aa.ex:2)

In the latter case, the code still works as designed (as far as I can
tell).

> Spreading clauses all over a module and interleaving them with other
> functions will only make it more difficult to read the code and make
> sure it's correct.

That still sounds like a style issue to me.

Consider something like this:

def handle_call( :foobar ) do
... a bit of logic involving a couple of convenience functions
... called "foo" and "bar" that are only used by this piece of
... code
end
def foo (...) do
...
end
def bar (...) do
...
end

#... more handle_calls with other requests, and their corresponding
#... helper functions defined right after them

I do agree that putting all the helper functions somewhere else is one
way to organise your code. It might even be the *better* way in 90% of
the cases.

But it's not the only way. And in some situations the one above will
read easier for someone trying to debug one specific request type.

I don't mind if you say "yes, this is a style issue that we feel so
strongly about that we enforce it with a compiler warning". That's
fine, just say so.

What's confusing me is that you seem to be saying it's something *more
than just style*, and I am unable to see where that comes from.

regards
sitaram

>
> So what the Elixir compiler does is the gentle way to handle this
> issue. An Erlang program wouldn't even compile if it had interleaved
> function clauses.
>

> On Tue, Oct 13, 2015 at 11:28 AM, Sitaram Chamarty <sita...@gmail.com <mailto:sita...@gmail.com>> wrote:
>
> On 13/10/15 05:22, Kevin Montuori wrote:

> >>>>>> "m" == mraptor <mra...@gmail.com <mailto:mra...@gmail.com>> writes:
> >
> > m> I'm grouping them on different principle, not based on name, but
> > m> on functionality.
> >
> > It's easy (and fast) enough to do something like:
> >
> > def event(:x, var), do: one_thing(var)
> > def event(:y, var), do: another_thing(var)
> > def event(:z, var), do: something_else_entirely(var)
> >
> > and then your maintainers (or your future self) won't curse you forever.
> > The follow on functions can then be grouped as you see fit.
> >
> > Although there are no doubt pathalogical cases, what you describe (a
> > multi-headed function doing different enough stuff that you want to
> > separate the heads in the source) strikes me as an anti-pattern.
>
> That sounds like a *style* issue, which is often subjective. Should that
> even *be* a compiler warning?
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-talk%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/561CC0BA.7040706%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-ta...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAAPY6eMbwzrQ%2BCyoDBTKdTwo7j3soi9A%3Dnmqn36pVHTjC%3Dx9Mg%40mail.gmail.com <https://groups.google.com/d/msgid/elixir-lang-talk/CAAPY6eMbwzrQ%2BCyoDBTKdTwo7j3soi9A%3Dnmqn36pVHTjC%3Dx9Mg%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[James Fish]

A warning is there to warn you that there is probably a mistake. In this situation it is more likely to be a mistake that a function with the same name and arity has been defined multiple times, rather than separated by design. Similarly if a clause can never match it is more likely a mistake than intentional. The same is true for an unused variable and declaring default arguments with multiple function heads in an ambiguous fashion.

I suppose it is possible to argue all of these are style issues.

To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/561CECC0.4030002%40gmail.com.

[Sitaram Chamarty]

On 13/10/15 17:58, James Fish wrote:
> A warning is there to warn you that there is probably a mistake. In
> this situation it is more likely to be a mistake that a function with
> the same name and arity has been defined multiple times, rather than
> separated by design. Similarly if a clause can never match it is more
> likely a mistake than intentional. The same is true for an unused
> variable and declaring default arguments with multiple function heads
> in an ambiguous fashion.
>
> I suppose it is possible to argue all of these are style issues.

I don't know; the "clause [that] can never match" and "declaring default
arguments with multiple function heads in an ambiguous fashion" sound
more serious than style to me.

regards
sitaram

> > >>>>>> "m" == mraptor <mra...@gmail.com <mailto:mra...@gmail.com> <mailto:mra...@gmail.com <mailto:mra...@gmail.com>>> writes:
> > >
> > > m> I'm grouping them on different principle, not based on name, but
> > > m> on functionality.
> > >
> > > It's easy (and fast) enough to do something like:
> > >
> > > def event(:x, var), do: one_thing(var)
> > > def event(:y, var), do: another_thing(var)
> > > def event(:z, var), do: something_else_entirely(var)
> > >
> > > and then your maintainers (or your future self) won't curse you forever.
> > > The follow on functions can then be grouped as you see fit.
> > >
> > > Although there are no doubt pathalogical cases, what you describe (a
> > > multi-headed function doing different enough stuff that you want to
> > > separate the heads in the source) strikes me as an anti-pattern.
> >
> > That sounds like a *style* issue, which is often subjective. Should that
> > even *be* a compiler warning?
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-talk%2Bunsu...@googlegroups.com> <mailto:elixir-lang-talk%2Bunsu...@googlegroups.com <mailto:elixir-lang-talk%252Buns...@googlegroups.com>>.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/561CC0BA.7040706%40gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-talk%2Bunsu...@googlegroups.com> <mailto:elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-talk%2Bunsu...@googlegroups.com>>.

> > To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CAAPY6eMbwzrQ%2BCyoDBTKdTwo7j3soi9A%3Dnmqn36pVHTjC%3Dx9Mg%40mail.gmail.com <https://groups.google.com/d/msgid/elixir-lang-talk/CAAPY6eMbwzrQ%2BCyoDBTKdTwo7j3soi9A%3Dnmqn36pVHTjC%3Dx9Mg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-talk%2Bunsu...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/561CECC0.4030002%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>
>

> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-ta...@googlegroups.com <mailto:elixir-lang-ta...@googlegroups.com>.

> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-talk/CA%2BibZ98EqL%3D_p_nsaXBqi0mSQYARtSC7AT45S_39WW6iaFh9KQ%40mail.gmail.com <https://groups.google.com/d/msgid/elixir-lang-talk/CA%2BibZ98EqL%3D_p_nsaXBqi0mSQYARtSC7AT45S_39WW6iaFh9KQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Kevin Montuori]

>>>>> "sc" == Sitaram Chamarty <sita...@gmail.com> writes:

>> On 13/10/15 17:58, James Fish wrote:
>> I suppose it is possible to argue all of these are style issues.

sc> I don't know; the "clause [that] can never match" and "declaring
sc> default arguments with multiple function heads in an ambiguous
sc> fashion" sound more serious than style to me.

I'd consider a clause that can always match

def handle_call(_request, _from, state), do: {:reply, ok, state}

tucked away unobtrusively at the end of a module to be just as serious
as a clause that can never match. If there's one of these I want it
right there with the rest of my handle_calls, tucked in between my init
and handle_cast functions. Principle of least surprise.

Elixir also considers them to be equally serious and Elixir isn't all
that whiny of a language.

It's early to tell what Elixir idioms are going to stick but there seems
to be great benefit in keeping the shape of Erlang gen_servers:

Public API
Callbacks
Private Functions

GenServers then are not only generic to the compiler but are generic too
for the human reader.

[mraptor]

This specific warning is heritage from Prolog or to be more correct because both use head-matching they have similar behaviors in some sense.
In my specific case, the reason I wanted to disable it cause I have the following interface :

def blah1 state, ....
def blah2 state, ....

.... then sometimes later ....

def blah1 registry, name, ....
def blah2 registry, name, ....
 
Some may argue to move the registry functionality to separate module, but this was uncomfortable for use, and too verbose and prone to typing mistakes, esp in iex.
I would like to use sort of multi-method dispatch like functionality.
(It is interesting another observation I have now that I spent little time with Elixir, I expected the code to be much more terse ..... but in many cases
 it happens to be worse than Java :), no biggy, just surprised).

Anyway it is not a big deal, I can live with it..  I was just curious.

[Josh Adams]

This idea (letting you separate the clauses) sounds terrible to me.
Having said that, if you want it you should easily be able to write a
macro that reorders the AST and wrap your module interior in it.

> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elixir-lang-ta...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/elixir-lang-talk/6a885adf-c94e-46ac-a1d7-8a6cba54635b%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Josh Adams

[Onorio Catenacci]

To be very blunt, if your Elixir code is more verbose than Java then you're doing it wrong. 

--

Onorio