Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: hGetContents and modules architecture idea (Rein Henrichs)
2. Re: hGetContents and modules architecture idea (PY)
----------------------------------------------------------------------
Message: 1
Date: Mon, 08 May 2017 13:24:32 -0700
From: Rein Henrichs <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] hGetContents and modules architecture
idea
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Please allow me to provide a little more context to David's fine answer:
baa dg <[email protected]> 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]
------------------------------
Message: 2
Date: Tue, 9 May 2017 11:43:57 +0300
From: PY <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] hGetContents and modules architecture
idea
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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 <[email protected]> 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
> [email protected]
> 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-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 107, Issue 8
*****************************************
