<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.<br>
</p>
<p>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 <span style="color: rgb(73, 73, 73); font-family:
DDG_ProximaNova, DDG_ProximaNova_UI_0, DDG_ProximaNova_UI_1,
DDG_ProximaNova_UI_2, DDG_ProximaNova_UI_3,
DDG_ProximaNova_UI_4, DDG_ProximaNova_UI_5,
DDG_ProximaNova_UI_6, "Proxima Nova", "Helvetica
Neue", Helvetica, "Segoe UI", "Nimbus Sans
L", "Liberation Sans", "Open Sans",
FreeSans, Arial, sans-serif; font-size: 19.8202px; font-style:
normal; font-variant-ligatures: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal; orphans: 2;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;"></span>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 :)</p>
<p>/Paul<br>
</p>
<br>
<div class="moz-cite-prefix">08.05.2017 23:24, Rein Henrichs пишет:<br>
</div>
<blockquote type="cite" cite="mid:m2r2zz14hr.fsf@gmail.com">
<pre wrap="">
Please allow me to provide a little more context to David's fine answer:
baa dg <a class="moz-txt-link-rfc2396E" href="mailto:aquagnu@gmail.com"><aquagnu@gmail.com></a> writes:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
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] [<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Expression_problem">https://en.wikipedia.org/wiki/Expression_problem</a>]
[2] [<a class="moz-txt-link-freetext" href="https://userpages.uni-koblenz.de/~laemmel/TheEagle/resources/pdf/xproblem1.pdf">https://userpages.uni-koblenz.de/~laemmel/TheEagle/resources/pdf/xproblem1.pdf</a>]
_______________________________________________
Beginners mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Beginners@haskell.org">Beginners@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a>
</pre>
</blockquote>
<br>
</body>
</html>