addpattern def with no prior match def

[yggdr]

I recently got back into coconut, and I like the improvements and additions. It is now possible to use the addpattern def syntax to add additional pattern matching functions with the same name. Unfortunately, with addpattern def func being merely sugar for @addpattern(func) right now, this means that whatever is the first function cannot use the addpattern def syntax, it has to use match def. So when refactoring one has to keep that in mind.

Now I understand how that developed historically, but I think it would be worthwhile thinking about unifying the syntax here, so that either addpattern def also works in the first instance, or match def incorporates the @addpattern(func) functionality on subsequent function definitions.

[evhub]

Yeah, that's a good point. Should pretty easy to just make addpattern def with no existing function of that name equivalent to match def.

[yggdr]

I have thought about this a bit more, my question is: if unification is easy as you say, and with prepattern being deprecated now, wouldn't it make sense to lose addpattern as well and have match def func not overwrite an existing pattern matching func object like it does now? Is there ever situation where one would want to use match def func to overwrite an existing func? I dabbled in Elixir a while back where you def pattern matching functions of the same name one after the other, so that's where my point of view on this comes from.

[evhub]

@yggdr I'm not a fan of that. I think it's pretty confusing given that normal Python function definitions do overwrite each other. It could be quite easy to expect overwriting behavior, not realize you're shadowing some other function in an enclosing scope, and up with a very hard to debug issue. addpattern def is much more explicit.

[evhub]

This is now live on coconut-develop>=3.0.0-a_dev10.

[yggdr]

Hmm, yeah, I see this could be an issue in a language where, unlike Elixir, pattern matching functions are just one of a few options. Ok, addpattern def sounds great, thanks :)

[evhub]

With #833, this should be deprecated and show a warning if you do it, since case def is now the recommended way to do this and addpattern def working without a prior match def can be a bit confusing.

[evhub]

Deprecation warning has been added; just needs documentation.