The criteria for determining this apparent danger, in all cases I have seen, is arbitrary nonsense. Try defining it in a coherent way.
"But the inconsistency with my intuition for the function named l-e-n-g-t-h that I learned in C programming school in the 1980s" is the best criteria that I have seen, and which commands outright dismissal. I am sceptical of anything better, and therefore, worth considering.
Other contenders:
* feels bad in my bones
* don't like it
* there's lots of us!
All these arguments have been, by moral imperative, and in
practice, dismissed.
The length of ((,) a) is very definitely 1. That this is not
bleedingly obvious, busted intuitions aside, is becoming more
laborious as this not-really-debate drags on.
We have a kind system, we have a type system, we have
parametricity. Use them. If you choose not to, fine, but don't try
to take superior tools away from me for no benefit. I will stop
you.
----
An anecdote on danger. A twin piston engine aircraft recently
crashed into a shopping centre on take-off from an airport in
southern Australia. All onboard were killed. Nobody on the ground
was injured. The cause is yet unknown and is under investigation.
It is an unusual circumstance. A friend of mine declared to me
that the airport should be closed. When I asked why, I was told,
"I used to work in the same type of shopping centre, at a
different airport, and I felt like I was in danger when aeroplanes
flew overhead." It is extremely fortunate that we don't have such
ridiculous assessments of danger dictating the policies of
aviation safety. Indeed, flying aeroplanes is one very effective
way to get away from that nonsense. Imagine if that "sense of
danger" were to dictate aviation safety regulations. What a
dangerous world we would be living in!
----
Ask yourself where the danger is and be reasonable about it. Hope
that helps.
That you can't should be a hint that length for ((,) a) is very definitely 1.
To be frank, this seems like a non-sequitur. Many of us find e.g.:
length (_, _) = 1maximum (_, b) = b
to be dangerous instances. We don't want to accidentally call them. We'd like a way to opt out or warn on use.
The inability to opt out or be warned does not seem to me to be an argument that the above instances are good instances.
Feel free to clarify if I haven't understood your point.
Thanks!Tom
Simply, use a different function, not length, which is well-defined for ((,) a) and other instances.
On Mon, Mar 20, 2017 at 3:15 AM, <amindfv@gmail.com> wrote:
Is there a clear way to implement this instance warning? I.e. given:
f x = 2 * length x
Can we guarantee at compile time that "f" will never be passed a 2-tuple?
TomI'm on the fence about the instance existing. I'm +1 for a warning, and thus would be +1 on keeping the instance. +1 on making the warning opt-in and +1 keeping it out of -Wall.
On Sun, 19 Mar 2017 at 00:51 <amindfv@gmail.com> wrote:
> El 18 mar 2017, a las 16:01, Lana Black <lanablack@amok.cc> escribió:
>
>> On 18/03/17 19:49, Henning Thielemann wrote:
>>
>>> On Sat, 18 Mar 2017, Carter Schonwald wrote:
>>>
>>> for what?
>>
>> A warning if someone e.g. calls 'length (a,b)', or more generally, if
>> certain instances are used.
>> _______________________________________________
>> Libraries mailing list
>> Libraries@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> Please no. Many of us like our code Wall-clean while still being able to
> write polymorphic functions. Adding more warnings that are often
> triggered by correct code (redundant constraints, anyone?) only leads to
> more headache.
>
> You could make that an hlint rule on the other hand.
Can it be a hlint rule? It seems quite difficult to predict that "length" will not ever be passed e.g. a 2-tuple in the general case, within hlint.
I would also favor a warning, and happily have -Wall not include it (though I'd prefer inclusion).
Tom
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries