[Haskell-beginners] hGetContents and modules architecture idea

Sat May 6 05:02:06 UTC 2017

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20170506/d012a847/attachment-0001.html>