[Haskell-beginners] hGetContents and modules architecture idea

[PY]

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


08.05.2017 23:24, Rein Henrichs пишет:
> Please allow me to provide a little more context to David's fine answer:
>
> baa dg <aquagnu at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20170509/9f7a8abb/attachment.html>