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 (David McBride)
2. Re: hGetContents and modules architecture idea (baa dg)
3. Re: hGetContents and modules architecture idea (David McBride)
----------------------------------------------------------------------
Message: 1
Date: Fri, 5 May 2017 08:33:07 -0400
From: David McBride <toa...@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:
<CAN+Tr41K=XpPrQ2QPA2wGhAB_RWWr+TmQrTf=kve40yjjpd...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
>
------------------------------
Message: 2
Date: Fri, 5 May 2017 21:31:58 +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:
<calmmzyhm866mxbrxbkrfmfdugrtz0tirdxch5kipedghsfl...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20170505/7cf8bd16/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 5 May 2017 15:19:13 -0400
From: David McBride <toa...@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:
<CAN+Tr404G2md6Hpkq_aW_uXC1qvqM4=afd5fhwdd_dgomv+...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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
>
------------------------------
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 3
*****************************************
