Yes, it makes sense. So, this is the evolution of the ecosystem and in the future this may be redesigned, right? And more abstract thing, like "streams" objects may replace file handlers in such "hGetContents", to support reading from string I/O, different devices, etc.

But here, I see another question. How is it possible if today there are many libraries/approaches, and no "main" one, no even such thing like "batteries", which can be "included" due nature of Haskell community, may be... It's not bad but it is so. What abstraction can be used? Machines/streams/pipes/conduits/etc? No "benevolent dictator" in the language, so no way to create one solid library... For example, after "stack install something" you get "mtl" and "transformers". But why both, they looks like solution for one/same task. The same about "pipes" and "conduits": sure I have both installed. And often dependencies are very big and IMHO no way to make standard mechanism in the language like in all other...  Thoughts out loud, nothing more :)

/Paul

Please allow me to provide a little more context to David's fine answer:

baa dg <aquagnu@gmail.com> writes:

So, is hGetContents is legacy? My ponits were: 1) hGetContents IMHO
should be in I/O related modules, not in "data definitions" modules.
Because when somebody creates new modules, defining some new data
types, he should not thing about I/O of these types. Even more, he
don't know what kind of I/O and I/O functions he must to "inject"
there. Is not it a design error in Haskell?

This is an instance of the expression problem[1]. We have a lot of IO
actions that read a Handle and return its contents as represented by
some Haskell data type. The question, then, is where do we put these
things? The three most promising options for organizing them are:

1. Put them all together in a module for doing I/O.
2. Put them together with the data type they return.
3. Factor out common functionality — such as reading a handle — and only
   implement what's different, e.g., coercing a stream of bytes
   (possibly interpreted via some encoding) into a given data type.

The first option is impossible — or at least impractical — because the
collection of data-types is large and fully extensible. This module
would need to depend on every package that provides data types, both
those currently existing and any developed in the future. The
maintenance burden on this module would be immense, as would be the
amount of friction introduced into the development of new data types.

The second option is the one we currently use for hGetContents, and it's
the one you dislike (for entirely legitimate reasons). But it's not the
only option provided by the language, or even the only option available
to you today! So I wouldn't say it's a design error of the language per
se (as the expression problem applies to all languages), just a
less-than-ideal choice made early on in the growth of the Haskell
ecosystem.

The third option solves the expression problem with type classes[2] and
other methods of abstraction, of which David has already shared a number
of examples. Factoring out the common I/O behavior reduces duplication
and increases modularity and while we're still left with an expression
problem — Where do the implementations of the type class instances live?
— it's a more tractable problem and solving it provides more value.

—
Rein Henrichs

[1] [https://en.wikipedia.org/wiki/Expression_problem]
[2] [https://userpages.uni-koblenz.de/~laemmel/TheEagle/resources/pdf/xproblem1.pdf]
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners