Send Beginners mailing list submissions to
beginners@haskell.org
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
beginners-requ...@haskell.org
You can reach the person managing the list at
beginners-ow...@haskell.org
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 (baa dg)
----------------------------------------------------------------------
Message: 1
Date: Sun, 7 May 2017 19:11:26 +0300
From: baa dg <aqua...@gmail.com>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <beginners@haskell.org>
Subject: Re: [Haskell-beginners] hGetContents and modules architecture
idea
Message-ID:
<calmmzyf49py6ugebfhqt3v2hz4jnhbhlko9yltwtxz8bw9a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
David, thank you for comprehensive answers!
Have a nice day.
2017-05-06 13:10 GMT+03:00 David McBride <toa...@gmail.com>:
> 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 <aqua...@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 <toa...@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 <aqua...@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 <toa...@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 <aqua...@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@haskell.org
> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >> >> >
> >> >> _______________________________________________
> >> >> Beginners mailing list
> >> >> Beginners@haskell.org
> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Beginners mailing list
> >> > Beginners@haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >> >
> >> _______________________________________________
> >> Beginners mailing list
> >> Beginners@haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >
> >
> >
> > _______________________________________________
> > Beginners mailing list
> > Beginners@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >
> _______________________________________________
> Beginners mailing list
> Beginners@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/20170507/ab623426/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 107, Issue 7
*****************************************
