Functor, Applicative, Monad, Foldable, Traversable instances for (, , ) a b

[amindfv at gmail.com]

> El 1 abr 2017, a las 13:45, amindfv at gmail.com escribió:
> 
> 
> 
>> El 1 abr 2017, a las 05:32, Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> escribió:
>> 
>> On 1 April 2017 at 19:42, Henrik Nilsson
>> <Henrik.Nilsson at nottingham.ac.uk> wrote:
>>> Hi all,
>>> 
>>>> It is perfectly to limit the concept of "length" to
>>>> 
>>>> * linear structures (lists, arrays, etc.)
>>>> [branching structures do not have a length, they may have a size or
>>>> maximum depth]
>>>> 
>>>> * which have variable length
>>>> [why would you otherwise ask for the length?]
>>> 
>>> Just for the record, I could not agree more.
>>> 
>>> Looking up "length", e.g. Merriam-Webster:
>>> 
>>>   1a :  the longer or longest dimension of an object
>>> 
>>> What we really are talking about here is counting the number of
>>> elements in a data structure. That is clearly applicable to lists
>>> as well as trees and tuples interpreted in particular ways.
>>> 
>>> But calling it "length" is not particularly helpful. Nor the effort to
>>> reappropriate the very concept of "length" through a categorical
>>> interpretation.
>>> 
>>> It would have been a lot better if a name suggesting a sense of
>>> counting, or at least a name suggesting that this is something different
>>> than the usual length, would have been picked. Maybe elementcount
>>> or ever flength.
>> 
>> I agree, but on the other hand this should have been done _before_
>> FTP; at this stage, I lean towards marking this down as one of the
>> known warts of Haskell - possibly with a 3 major version GHC cycle to
>> migrate to a better name once the bikeshedding has been completed -
>> and moving on rather than being revisionist and using this as an
>> excuse to go backwards.
>> 
>> So far, the arguments against these instances that I've seen are:
>> 
>> * The name of the length function is misleading for such instances
>> (with all respect to Tony, agreed; but see above); I don't think I've
>> seen anyone else complain about any of the other function names
>> though.
>> 
>> * Since these classes/instances are now exported from the Prelude,
>> previous code that wouldn't have have type-checked are now valid and
>> thus produce unexpected results (I was against the Prelude export when
>> FTP was being debated, but now - with the possible exception of people
>> learning to program - I think this is a matter of needing to be more
>> aware of the types and using our wonderful REPL environments to test
>> functions rather than blindly just writing code without validating the
>> code logic).
> 
> My concern is not that people should be able to write trivial-to-check code without actually testing it. My concern (because it has happened to me in real code!) is people may write complex functions with difficult-to-inspect results.
> 
> The bug that was trickiest to track down was a numerical calculation involving a list whose length was almost always 1, that I performed 'length' on. I wrapped the list in a tuple elsewhere in the code, ghc happily typechecked it, and only in rare cases did I get very weird results. This was deep within a larger calculation, and someone could have easily shipped something like this to production.
> 
> Tom
> 

Just to add: I don't think I've experienced bugs like these myself, but

maximum (89,88) == 88

and friends seem prime for returning seemingly-correct results while a bug lurks, uncaught by the typechecker.

Tom



> 
>> 
>> TL;DR: I didn't 100% agree with the way FTP was done precisely due to
>> the problems people have with these instances, but now let's not go
>> backwards (and the tuple instances I've found very useful).
>> 
>>> 
>>> Names matter.
>>> 
>>> /Henrik
>>> 
>>> 
>>> 
>>> 
>>> This message and any attachment are intended solely for the addressee
>>> and may contain confidential information. If you have received this
>>> message in error, please send it back to me, and immediately delete it.
>>> Please do not use, copy or disclose the information contained in this
>>> message or in any attachment.  Any views or opinions expressed by the
>>> author of this email do not necessarily reflect the views of the
>>> University of Nottingham.
>>> 
>>> This message has been checked for viruses but the contents of an
>>> attachment may still contain software viruses which could damage your
>>> computer system, you are advised to perform your own checks. Email
>>> communications with the University of Nottingham may be monitored as
>>> permitted by UK legislation.
>>> 
>>> 
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>> 
>> 
>> 
>> -- 
>> Ivan Lazar Miljenovic
>> Ivan.Miljenovic at gmail.com
>> http://IvanMiljenovic.wordpress.com
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries