[Haskell-beginners] hGetContents and modules architecture idea

Sat May 6 10:10:38 UTC 2017

I'd say that haskell depends more on its libraries than most other
languages because they kind of get better over time and a lot of times
the better libraries are not at a beginner level of skill.

As for hGetContents not being generic over its types, people have
actually written typeclasses for that purpose.  See
http://hackage.haskell.org/package/ListLike-4.5.1/docs/Data-ListLike.html#v:hGetContents
it is just that it is not in the standard library.  The problem with
having everything typeclassed is that it makes it so that you have to
fix all the types before your code will compile.  There are a lot of
people who believe that some of the list functions like length should
not be generic in Prelude because it's difficult to get the hang of
when you first start learning haskell.  I'm not one of them, but I
understand what they are getting at.

I personally use pipes, but over the years they've more or less
reached feature parity.  Pipes has a few minor things over conduits,
conduits is slightly easier to use.  You can convert between the two
fairly easily in code.  Which you use is up to you.

On Sat, May 6, 2017 at 1:02 AM, baa dg <aquagnu at gmail.com> wrote:
> Hmm. David, I'm reading about io-stream now (I have never met it early), it
> looks very interesting. Is it the same idea as Pipe/Conduit (to "piping"
> data by fixed memory usage in each "processing phase")?
>
>
> By the way, what do you prefer more: pipes or conduits? Snoyman said that
> pipes has limited design due to exceptions handling possibilities, it is
> true today? What is more stable, better designed, more "clean"?
>
>
> 2017-05-05 22:19 GMT+03:00 David McBride <toad3k at gmail.com>:
>>
>> Sorry I'm having trouble understanding your english and am unfamiliar
>> with some of the terms you are using.
>>
>> -- More natural is to have abstract stream of bytes. And to read only
>> bytes. Then to convert them into
>>
>> There are a lot of abstractions of data in haskell.  Are you looking
>> for something like pipes, conduits, or io-streams?
>>
>> io-streams for example exports different ways to get an io-stream from
>> some source.
>>
>> -- from / to a network
>> socketToStreams :: Socket -> IO (InputStream ByteString, OutputStream
>> ByteString)
>> withFileAsInput
>>
>> -- various to and from files with or without automatic resource management
>> handleToInputStream :: Handle -> IO (InputStream ByteString)
>>
>> -- to / from an interactive command.
>> runInteractiveCommand :: String -> IO (OutputStream ByteString,
>> InputStream ByteString, InputStream ByteString, ProcessHandle)
>>
>> Once you have an OutputStream or an InputStream, you can do whatever
>> you want with them.
>>
>> -- fold an input stream into some type s, via the supplied functions.
>> fold :: (s -> a -> s) -> s -> InputStream a -> IO s
>>
>> -- ensure that every byte in an input stream conforms to a supplied
>> function.
>> all :: (a -> Bool) -> InputStream a -> IO Bool
>>
>> -- zip two input streams into a single input stream with characters from
>> each.
>> zip :: InputStream a -> InputStream b -> IO (InputStream (a, b))
>>
>> -- And if you have access to such a stream, you can manipulate at a
>> very low level if you need to
>> read :: InputStream a -> IO (Maybe a)
>> peek :: InputStream a -> IO (Maybe a)
>> unRead :: a -> InputStream a -> IO ()
>>
>> I don't think I've used hGetContents for many years.  While io-streams
>> is the most straight forward, I personally use pipes quite a bit in my
>> every day code.
>>
>> Beyond that for writing a complex datatype to a bytestring there are
>> numerous libraries like binary and cereal which allow you to write
>> bytes in a very exact fashion, to be put into a file or over the
>> network if you wish.
>>
>> I'm not sure if I've gotten to the heart of what you are asking, but
>> haskell provides a huge wealth of ways to access and manipulate data
>> on every possible level and they pretty much all fit together very
>> well, far better than similar abstractions in other languages ever
>> could, so far as I'm aware.
>>
>> On Fri, May 5, 2017 at 2:31 PM, baa dg <aquagnu at gmail.com> wrote:
>> > This sure makes sense and all other languages follow this practice. But
>> > nevertheless Sndfile has this `hGetContents`. And Darcs module.
>> > But more strange for me is: it is considered that this function
>> > (hGetContents) is sufficiently universaland meets so often. But this is
>> > the
>> > reading from file handler which is not abstract/generic/universal. So:
>> >
>> > - there are types which are in no way related to I/O but their modules
>> > implements I/O functions and this is very strange
>> > - and even more: these I/O related functions are based on concreate kind
>> > of
>> > I/O - file handler based, which means that no ways to read these types
>> > from
>> > SPI, I2C or any other not file-hadler-based I/O. Whether there are any
>> > serious problems with abstraction?
>> >
>> > More natural is to have abstract stream of bytes. And to read only
>> > bytes.
>> > Then to convert them into Text, Sndfiles, etc, but such I/O functions
>> > can
>> > not be in "model"-related modules (where are defined data types). And is
>> > we
>> > will read new type from NEW INTERFACE (which has not file handler),
>> > nothing
>> > will be broken: we will still read bytes from a stream of bytes with
>> > abstract interface (type-class); and this stream may be bound to
>> > register
>> > I/O port, for example, etc - not file handler. If we need such kind of
>> > I/O -
>> > we will add something like `portGetContents` in all these modules: Text,
>> > ByteString, Sndfile, etc ? :)
>> >
>> > This is what I can't understand.
>> >
>> >
>> > 2017-05-05 15:33 GMT+03:00 David McBride <toad3k at gmail.com>:
>> >>
>> >> In haskell you have datatypes like String, Text, Text.Lazy,
>> >> ByteString, etc.  All of those have functions like readFile,
>> >> writeFile, hPutStr, hGetLine (if applicable to that type).  If you
>> >> have your own type, say a Triangle, you would usually get that from
>> >> one of the intermediate types, such as Bytestring -> Triangle.
>> >>
>> >> It is also possible to make a class which allows you to create a
>> >> Triangle from a variety of types, ToShape a => a -> Triangle, where
>> >> instance ToShape ByteString.
>> >>
>> >> For your second question. To do a complex type from say a ByteString,
>> >> most people would use a parser combinator, perhaps something like
>> >> attoparsec, although there are many other options.  That particular
>> >> library allows you to parse from a bytestring or from a file as
>> >> needed.  When using it on a file you might use withFile around
>> >> parseWith and pass hGetContents as its first argument.
>> >>
>> >> On Fri, May 5, 2017 at 5:31 AM, PY <aquagnu at gmail.com> wrote:
>> >> > Hello everyone! I'm trying to understand base idea of Haskell modules
>> >> > architecture. In other languages, "reading from file" is placed in
>> >> > something
>> >> > like "io", "istream", "file", etc modules. Also most languages have a
>> >> > concept of reading from abstract bytes streams. You read bytes from
>> >> > something and translate them into your high level object/type/etc.
>> >> >
>> >> > In Haskell I see that, for example, function hGetContents exists in
>> >> > (this
>> >> > is my local installation):
>> >> >
>> >> > GHC.IO.Handle
>> >> > System.IO
>> >> > Data.ByteString
>> >> > Data.ByteString.Char8
>> >> > Data.ByteString.Lazy
>> >> > Data.ByteString.Lazy.Char8
>> >> > Data.Text.IO
>> >> > Data.Text.Lazy.IO
>> >> > System.IO.Strict
>> >> > Text.Pandoc.UTF8
>> >> > Data.ListLike
>> >> > Data.ListLike.IO
>> >> > ClassyPrelude
>> >> > Hledger.Utils.UTF8IOCompat
>> >> > Data.IOData
>> >> > Darcs.Util.Ratified
>> >> > Sound.File.Sndfile
>> >> > Sound.File.Sndfile.Buffer
>> >> > Data.String.Class
>> >> > Network.BufferType
>> >> >
>> >> > If I'll create module SuperMegaShapes with some Triangle, Rectangle,
>> >> > Square
>> >> > and other things, I'll create (to be consistent with Haskell-way)...
>> >> > hGetContents there??!
>> >> >
>> >> > So, I have 2 questions here:
>> >> >
>> >> > First one: let's imagine that we have Haskell compiler for embedded.
>> >> > And
>> >> > I
>> >> > want to read Text, ByteString, Sndfile and SuperMegaShapes from...
>> >> > SPI.
>> >> > There are many devices andprotocols, right? And I have not FILE
>> >> > HADNLER
>> >> > for
>> >> > most of them. So, this mean that Haskell (like simple script
>> >> > language)
>> >> > supports only concept of FILE HANDLER reading?! And no other
>> >> > ABSTRACTIONS?
>> >> >
>> >> > Second question is: must any new type which we plan to read/write to
>> >> > have
>> >> > hGetContents? What if it is packed in some tricky container?
>> >> > Matreshka?
>> >> > Something else, more tricky? :) And more: what other I/O functions
>> >> > must
>> >> > be
>> >> > injected in our model definitions modules?
>> >> >
>> >> >
>> >> > ===
>> >> > Best regards
>> >> >
>> >> > _______________________________________________
>> >> > Beginners mailing list
>> >> > Beginners at haskell.org
>> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>> >> >
>> >> _______________________________________________
>> >> Beginners mailing list
>> >> Beginners at haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>> >
>> >
>> >
>> > _______________________________________________
>> > Beginners mailing list
>> > Beginners at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>> >
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>