Hi, On 12/29/2016 12:48 PM, Andreas Abel wrote:
What are the types and definitions of
nonEmpty, (:|), and the type constructor NonEmpty.
?
Must be something generic, overloaded, given the name...
Indeed, one would assume so, given the names. But:
What are the types and definitions of
nonEmpty, (:|), and the type constructor NonEmpty.
?
See http://hackage.haskell.org/package/base-4.9.0.0/docs/ Data-List-NonEmpty.html
there is nothing generic at all about these: I am assuming that the idea is that these three definitions will be made available for unqualified use (while all other library functions for programming with non-empty lists would have to be imported explicitly from Data.List.NonEmpty, as currently is the case). But these are really poor names for something this specific being made available unqualified everywhere: there are lots of things that could be called "NonEmpty" or "nonEmpty", and ":|" is a perfectly good combinator name for other purposes. So this addition would do little beside increasing the footprint of the Prelude and causing issues clashes with code that happens to use these names already. To quote Yuras Shumovich from a related thread (Add readMaybe (and possibly readEither) to Prelude): "We should be careful with Prelude." Additionally, as is evidenced by the type signatures of the module NonEmpty, the utility of keeping track of non-empty lists at the type level in a language like Haskell is in general limited (which is not to say that it cannot be very useful sometimes). Even in a language with dependent types the approach (of integrating properties with data types) is not always smooth as it may lead to a proliferation of different related but distinct types which quickly becomes clunky. As far as I am aware, solving this conundrum is still an open research problem. (And nothing new under the sun, either: people familiar with Pascal or Ada will have had similar experiences with a proliferation of integral types of various ranges. In simple cases, very useful to ensure e.g. an array index is not out of bounds, but does not go very far.) Finally, why single out "non-empty" specifically as a property worthy to keep track at the type level in the prelude? Why not lists of finite length as well, for example? That could help ensuring termination. (Just to be clear: I am not proposing this. I am just saying that I can't see how adding variations of existing types with specific properties to the prelude possibly can result in a principled design for a language like Haskell as it currently stands.) /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.