
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
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
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