My point is that beginners already have to deal with operators. Adding some badly named ones is not worse than adding badly named functions. I have taught beginners and have found that they are confused by the fact that Map and Array do not have syntax associated with them.
If someone is able to use plus with prefix notation, I'm not convinced that custom operators are a big hurdle anymore.
Making your own overloaded functions is harder to learn than (comparable, appendable, number) but without overloading there is no way of making custom comparable types.
Using overloaded functions requires you to understand errors like "No version of (+) takes an argument of type Model." The current model requires understanding of comparable and appendable.
Overloads would make complex type mismatches worse, but those are not understandable anyway unless you add type annotations.
The real reason for why overloading wouldn't work is a technical one. For example a set data structure needs to work with any comparable type and the definition of (<) has to be visible to the module implementing a the set. If this could be elegantly overcome, I think overloading would be the type class replacement for Elm.
Getting rid of appendable would just require the removal of ++ for Strings, though.
Overloading [...] is difficult to combine with currying.
I think it makes sense to require that the functions have the same number of arguments.
My point is that beginners already have to deal with operators.
Beginners usually only deal with operators they already know, like +, -, * and /. As far as I've seen, most people don't use operators in prefix notation.
I'm not convinced that custom operators are a big hurdle anymore.
There's a big difference between + and -~-> though (and yes, that operator existed).
Getting rid of appendable would just require the removal of ++ for Strings, though.
Here we agree, though I'd rather remove ++ for Lists as ++ is really great for String concatenation.
I think it makes sense to require that the functions have the same number of arguments.
You'd still get a problem with stuff like
someFunc:(a->b)->asomeFunc:a->a
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My point is that beginners already have to deal with operators. Adding some badly named ones is not worse than adding badly named functions. I have taught beginners and have found that they are confused by the fact that Map and Array do not have syntax associated with them.
If someone is able to use plus with prefix notation, I'm not convinced that custom operators are a big hurdle anymore.
Making your own overloaded functions is harder to learn than (comparable, appendable, number) but without overloading there is no way of making custom comparable types.
Using overloaded functions requires you to understand errors like "No version of (+) takes an argument of type Model." The current model requires understanding of comparable and appendable.
Overloads would make complex type mismatches worse, but those are not understandable anyway unless you add type annotations.
The real reason for why overloading wouldn't work is a technical one. For example a set data structure needs to work with any comparable type and the definition of (<) has to be visible to the module implementing a the set. If this could be elegantly overcome, I think overloading would be the type class replacement for Elm.
Getting rid of appendable would just require the removal of ++ for Strings, though.
I think it makes sense to require that the functions have the same number of arguments.
Beginners usually only deal with operators they already know, like +, -, * and /. As far as I've seen, most people don't use operators in prefix notation.
There's a big difference between
+and-~->though (and yes, that operator existed).Here we agree, though I'd rather remove
++for Lists as++is really great for String concatenation.You'd still get a problem with stuff like