From lionhive at gmail.com Tue May 2 21:20:15 2017 From: lionhive at gmail.com (Leon x) Date: Wed, 3 May 2017 09:20:15 +1200 Subject: [Haskell-beginners] Struggling with integrating standalone function with existing vty based app Message-ID: I have the following code working fine: https://github.com/leonstafford/pandoctest But struggling in bringing it into this vty based app. I admit to not quite understanding the control flow / IO here and could use some tips as to what I'm doing wrong with this one: https://github.com/leonstafford/cli-rss-reader/blob/feature/pandoc-render-article/Main.hs As per the comments, I've tried to understand the existing code, but now just finding myself flailing keys and switching type signatures to no avail. Humbly seeking guidance from above! Cheers, Leon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Wed May 3 04:00:07 2017 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Wed, 3 May 2017 11:00:07 +0700 Subject: [Haskell-beginners] Foldable for (,) In-Reply-To: References: Message-ID: Hey Jonathon, Based on the last email you sent, it seems like you're not quite satisfied with the responses. And for good reason. It turns out that there is more to length (2,3) = 1 sum (2,3) = product (2,3) = 3 than just the offending Traversable instance of the tuple pair (,). Would you mind resending your first email of Apr 23 to the haskell-cafe mailing list? If you do so, I'll contribute by opening a discussion of the Functor instance. Best, Kim-Ee On Sunday, April 23, 2017, Jonathon Delgado wrote: > I've seen many threads, including the one going on now, about why we need > to have: > > length (2,3) = 1 > product (2,3) = 3 > sum (2,3) = 3 > or (True,False) = False > > but the justifications all go over my head. Is there a beginner-friendly > explanation for why such seemingly unintuitive operations should be allowed > by default? > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquagnu at gmail.com Fri May 5 09:31:42 2017 From: aquagnu at gmail.com (PY) Date: Fri, 5 May 2017 12:31:42 +0300 Subject: [Haskell-beginners] hGetContents and modules architecture idea Message-ID: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Fri May 5 12:33:07 2017 From: toad3k at gmail.com (David McBride) Date: Fri, 5 May 2017 08:33:07 -0400 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: 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 at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From aquagnu at gmail.com Fri May 5 18:31:58 2017 From: aquagnu at gmail.com (baa dg) Date: Fri, 5 May 2017 21:31:58 +0300 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: 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 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: From toad3k at gmail.com Fri May 5 19:19:13 2017 From: toad3k at gmail.com (David McBride) Date: Fri, 5 May 2017 15:19:13 -0400 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: 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 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 : >> >> 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 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 > From aquagnu at gmail.com Sat May 6 04:24:39 2017 From: aquagnu at gmail.com (baa dg) Date: Sat, 6 May 2017 07:24:39 +0300 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: Oh, David, execuse my English!! I'm sorry so much. I know about pipes and conduits libraries, but they are not part of language itsef and more: no such thing like "batteries included": you can avoid use of them or you can use both or even use libraries which depends on pipe and conduit at one time, so to have both in one project. It's not the same as "yield" in Python which is a path of the language, or "async", for example. So, is hGetContents is legacy? My ponits were: 1) hGetContents IMHO should be in I/O related modules, not in "data definitions" modules. Because when somebody creates new modules, defining some new data types, he should not thing about I/O of these types. Even more, he don't know what kind of I/O and I/O functions he must to "inject" there. Is not it a design error in Haskell? 2) hGetContents "supposes" that I/O is based on file handlers. This limits Haskell as simple little script language. There are another kinds of I/O, where you have not files and their handlers, for example, in embedded, when you can read/write bytes from ports through different protocols: I2C, SPI, etc, ports may be mapped to memory addresses or be available via fixed register names, etc. Is not it a design limitation of Haskell, related to this ubiquitous hGetContents? 3) Concept that you must read Text or Sndfile from input file leads (if it is a idea of placing this hGetContents in all of that modules) to practice when other libraries authors would implement hGetContents for their types. They and we :) Is not it a lossing of abstraction? To combine all of these things together you should read/write bytes and encode/decode types from abstract bytes' streams, is not it? But, in this case, what does hGetContents in all of these modules today?! :) I'm programmer from 96 and used many different languages, and today, when I'm using Haskell, it's important for me, as to any other programmer, which begining to use new language (Haskell in the case) to accept and understand, to feel base ideas of language's infrastructure design: modules/ecosystem. Today languages are easy, but their ecosystem and infrastrucutre often are complex, different, strange and sometimes surprises us. As for me, all of these thoughts are related to "accepting" of language ecosystem/core/infrastructure. To understand why so, why in this manner... I like Haskell, it looks like functional C, not C++ even: lambda and types, nothing else. But such thoughts (like about hGetContents) embarras me. I'm not sure, is it right place to ask such questions, I tryed on StackOverflow but their is not the place, may be Haskell-cafe? Other programmers, with background in other languages, I'm sure, also ask themselves similar questions and tried to accept these design, so, as for me, I'll very glad to listen about experience of others. What they thing about such design/libraries/modules ecosystem. Early, I asked about this on StackOverflow, also about functions like "fold", "elem", "intercalate", many other, which are in List module and other modules too. As for me, they all are candidates to be totally abstract (via typeclass) and should not be in List or Map/Hashmap/etc modules only. Something like C++ interfaces, SML signatures. And as I understand from answer, this actually so because of legacy reason, and today there are attempts to solve this problem in Haskell: there are new packages (alternative preludes, etc) which defines such type-classes (sure, there are famouse Alternatives, Applicatives, Foldable, Traversable, but it's not the same). If, hGetContents is such legacy - OK, this is understandable, makes sense :) And again, David, execuse my terrible English, please! 2017-05-05 22:19 GMT+03:00 David McBride : > 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 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 : > >> > >> 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 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: From aquagnu at gmail.com Sat May 6 05:02:06 2017 From: aquagnu at gmail.com (baa dg) Date: Sat, 6 May 2017 08:02:06 +0300 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: 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 : > 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 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 : > >> > >> 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 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: From szymonpajzert at gmail.com Sat May 6 09:08:44 2017 From: szymonpajzert at gmail.com (Szymon Pajzert) Date: Sat, 6 May 2017 11:08:44 +0200 Subject: [Haskell-beginners] Monads of functions Message-ID: Hello, Lately I'm working with Reader monad. Because of that, I have to use function of signature: Monad m => (a -> m b) -> m (a -> b). Is this even possible to do so? Thanks in advance for your help. Best Regards, Szymon Pajzert -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Sat May 6 10:10:38 2017 From: toad3k at gmail.com (David McBride) Date: Sat, 6 May 2017 06:10:38 -0400 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: 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 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 : >> >> 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 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 : >> >> >> >> 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 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 > From szymonpajzert at gmail.com Sun May 7 10:44:46 2017 From: szymonpajzert at gmail.com (Szymon Pajzert) Date: Sun, 7 May 2017 12:44:46 +0200 Subject: [Haskell-beginners] Monads of functions In-Reply-To: References: Message-ID: Colleague has helped me with the solution for the Reader, without general solution (probably it's not possible to do so for every monad): foo :: (a -> Reader r b) -> Reader r (a -> b) foo f = do r <- ask return $ \a -> runReader (f a) r Hope that's gonna help someone in the future. On 6 May 2017 at 11:08, Szymon Pajzert wrote: > Hello, > > Lately I'm working with Reader monad. Because of that, I have to use > function of signature: > > Monad m => (a -> m b) -> m (a -> b). > > Is this even possible to do so? Thanks in advance for your help. > > Best Regards, > Szymon Pajzert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquagnu at gmail.com Sun May 7 16:11:26 2017 From: aquagnu at gmail.com (baa dg) Date: Sun, 7 May 2017 19:11:26 +0300 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: David, thank you for comprehensive answers! Have a nice day. 2017-05-06 13:10 GMT+03:00 David McBride : > 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 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 : > >> > >> 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 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 : > >> >> > >> >> 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 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 > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rein.henrichs at gmail.com Mon May 8 20:24:32 2017 From: rein.henrichs at gmail.com (Rein Henrichs) Date: Mon, 08 May 2017 13:24:32 -0700 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: Please allow me to provide a little more context to David's fine answer: baa dg writes: > So, is hGetContents is legacy? My ponits were: 1) hGetContents IMHO > should be in I/O related modules, not in "data definitions" modules. > Because when somebody creates new modules, defining some new data > types, he should not thing about I/O of these types. Even more, he > don't know what kind of I/O and I/O functions he must to "inject" > there. Is not it a design error in Haskell? This is an instance of the expression problem[1]. We have a lot of IO actions that read a Handle and return its contents as represented by some Haskell data type. The question, then, is where do we put these things? The three most promising options for organizing them are: 1. Put them all together in a module for doing I/O. 2. Put them together with the data type they return. 3. Factor out common functionality — such as reading a handle — and only implement what's different, e.g., coercing a stream of bytes (possibly interpreted via some encoding) into a given data type. The first option is impossible — or at least impractical — because the collection of data-types is large and fully extensible. This module would need to depend on every package that provides data types, both those currently existing and any developed in the future. The maintenance burden on this module would be immense, as would be the amount of friction introduced into the development of new data types. The second option is the one we currently use for hGetContents, and it's the one you dislike (for entirely legitimate reasons). But it's not the only option provided by the language, or even the only option available to you today! So I wouldn't say it's a design error of the language per se (as the expression problem applies to all languages), just a less-than-ideal choice made early on in the growth of the Haskell ecosystem. The third option solves the expression problem with type classes[2] and other methods of abstraction, of which David has already shared a number of examples. Factoring out the common I/O behavior reduces duplication and increases modularity and while we're still left with an expression problem — Where do the implementations of the type class instances live? — it's a more tractable problem and solving it provides more value. — Rein Henrichs [1] [https://en.wikipedia.org/wiki/Expression_problem] [2] [https://userpages.uni-koblenz.de/~laemmel/TheEagle/resources/pdf/xproblem1.pdf] From aquagnu at gmail.com Tue May 9 08:43:57 2017 From: aquagnu at gmail.com (PY) Date: Tue, 9 May 2017 11:43:57 +0300 Subject: [Haskell-beginners] hGetContents and modules architecture idea In-Reply-To: References: <4fb2cb71-d68d-7d93-ce1b-09dc69fac614@gmail.com> Message-ID: <35c95093-fbd0-17f3-ef5c-d73bbd1355d3@gmail.com> Yes, it makes sense. So, this is the evolution of the ecosystem and in the future this may be redesigned, right? And more abstract thing, like "streams" objects may replace file handlers in such "hGetContents", to support reading from string I/O, different devices, etc. But here, I see another question. How is it possible if today there are many libraries/approaches, and no "main" one, no even such thing like "batteries", which can be "included" due nature of Haskell community, may be... It's not bad but it is so. What abstraction can be used? Machines/streams/pipes/conduits/etc? No "benevolent dictator" in the language, so no way to create one solid library... For example, after "stack install something" you get "mtl" and "transformers". But why both, they looks like solution for one/same task. The same about "pipes" and "conduits": sure I have both installed. And often dependencies are very big and IMHO no way to make standard mechanism in the language like in all other... Thoughts out loud, nothing more :) /Paul 08.05.2017 23:24, Rein Henrichs пишет: > Please allow me to provide a little more context to David's fine answer: > > baa dg writes: >> So, is hGetContents is legacy? My ponits were: 1) hGetContents IMHO >> should be in I/O related modules, not in "data definitions" modules. >> Because when somebody creates new modules, defining some new data >> types, he should not thing about I/O of these types. Even more, he >> don't know what kind of I/O and I/O functions he must to "inject" >> there. Is not it a design error in Haskell? > This is an instance of the expression problem[1]. We have a lot of IO > actions that read a Handle and return its contents as represented by > some Haskell data type. The question, then, is where do we put these > things? The three most promising options for organizing them are: > > 1. Put them all together in a module for doing I/O. > 2. Put them together with the data type they return. > 3. Factor out common functionality — such as reading a handle — and only > implement what's different, e.g., coercing a stream of bytes > (possibly interpreted via some encoding) into a given data type. > > The first option is impossible — or at least impractical — because the > collection of data-types is large and fully extensible. This module > would need to depend on every package that provides data types, both > those currently existing and any developed in the future. The > maintenance burden on this module would be immense, as would be the > amount of friction introduced into the development of new data types. > > The second option is the one we currently use for hGetContents, and it's > the one you dislike (for entirely legitimate reasons). But it's not the > only option provided by the language, or even the only option available > to you today! So I wouldn't say it's a design error of the language per > se (as the expression problem applies to all languages), just a > less-than-ideal choice made early on in the growth of the Haskell > ecosystem. > > The third option solves the expression problem with type classes[2] and > other methods of abstraction, of which David has already shared a number > of examples. Factoring out the common I/O behavior reduces duplication > and increases modularity and while we're still left with an expression > problem — Where do the implementations of the type class instances live? > — it's a more tractable problem and solving it provides more value. > > — > Rein Henrichs > > [1] [https://en.wikipedia.org/wiki/Expression_problem] > [2] [https://userpages.uni-koblenz.de/~laemmel/TheEagle/resources/pdf/xproblem1.pdf] > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick.browne at dit.ie Thu May 11 19:38:59 2017 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Thu, 11 May 2017 20:38:59 +0100 Subject: [Haskell-beginners] Quickcheck: pushing element onto stack increases stack size Message-ID: Hi, I am trying to use Quickcheck to check that pushing an element increases the size of a stack. Something like: prop_size2 x s = (size (Push x s)) > (size s) Is this possible? Below is my effort using an empty stack. Thanks in advance, Pat module Stack (empty, push, pop, top, isEmpty) where import Test.QuickCheck data Stack a = Empty | Push a (Stack a) deriving Show empty :: Stack a empty = Empty push :: a -> Stack a -> Stack a push x ss = Push x ss pop :: Stack a -> Stack a pop Empty = error "pop emptyStack" pop (Push x ss) = ss top :: Stack a -> a top Empty = error "top emptyStack" top (Push x ss) = x isEmpty :: Stack a -> Bool isEmpty Empty = True isEmpty (Push x ss) = False size :: (Stack a) -> Int size Empty = 0 size (Push x ss) = succ (size ss) prop_size x = (size (Push x Empty)) > (size Empty) -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ó ITBÁC a tháinig an ríomhphost seo. Má fuair tú an ríomhphost seo trí earráid, scrios de do chóras é le do thoil. Tabhair ar aird, mura tú an seolaí ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon chóipeáil, aon dáileadh nó ar aon ghníomh a dhéanfar bunaithe ar an ábhar atá sa ríomhphost nó sna hiatáin seo. www.dit.ie Tá ITBÁC ag aistriú go Gráinseach Ghormáin – DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From toad3k at gmail.com Thu May 11 20:00:57 2017 From: toad3k at gmail.com (David McBride) Date: Thu, 11 May 2017 16:00:57 -0400 Subject: [Haskell-beginners] Quickcheck: pushing element onto stack increases stack size In-Reply-To: References: Message-ID: First you need a way to generate an arbitrary stack. Here's a simple method that just gives you a 50% chance at each level of generating an extra layer. instance Arbitrary a => Arbitrary (Stack a) where arbitrary = oneof [return Empty, Push <$> arbitrary <*> arbitrary ] prop_size_succeeds x s = size (Push x s) > size s prop_size_fails x s = size s > size Empty >quickCheck prop_size_fails *** Failed! Falsifiable (after 6 tests): () Empty On Thu, May 11, 2017 at 3:38 PM, PATRICK BROWNE wrote: > Hi, > I am trying to use Quickcheck to check that pushing an element increases the > size of a stack. > Something like: > prop_size2 x s = (size (Push x s)) > (size s) > > Is this possible? Below is my effort using an empty stack. > Thanks in advance, > Pat > > > module Stack (empty, push, pop, top, isEmpty) where > import Test.QuickCheck > > data Stack a = Empty | Push a (Stack a) deriving Show > > empty :: Stack a > empty = Empty > > push :: a -> Stack a -> Stack a > push x ss = Push x ss > > pop :: Stack a -> Stack a > pop Empty = error "pop emptyStack" > pop (Push x ss) = ss > > top :: Stack a -> a > top Empty = error "top emptyStack" > top (Push x ss) = x > > isEmpty :: Stack a -> Bool > isEmpty Empty = True > isEmpty (Push x ss) = False > > > size :: (Stack a) -> Int > size Empty = 0 > size (Push x ss) = succ (size ss) > > > prop_size x = (size (Push x Empty)) > (size Empty) > > This email originated from DIT. If you received this email in error, please > delete it from your system. Please note that if you are not the named > addressee, disclosing, copying, distributing or taking any action based on > the contents of this email or attachments is prohibited. www.dit.ie > > Is ó ITBÁC a tháinig an ríomhphost seo. Má fuair tú an ríomhphost seo trí > earráid, scrios de do chóras é le do thoil. Tabhair ar aird, mura tú an > seolaí ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon chóipeáil, aon > dáileadh nó ar aon ghníomh a dhéanfar bunaithe ar an ábhar atá sa ríomhphost > nó sna hiatáin seo. www.dit.ie > > Tá ITBÁC ag aistriú go Gráinseach Ghormáin – DIT is on the move to > Grangegorman > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > From patrick.browne at dit.ie Thu May 11 21:55:55 2017 From: patrick.browne at dit.ie (PATRICK BROWNE) Date: Thu, 11 May 2017 22:55:55 +0100 Subject: [Haskell-beginners] Quickcheck: pushing element onto stack increases stack size In-Reply-To: References: Message-ID: David, Thanks for the help. Much appreciated, Pat On 11 May 2017 at 21:00, David McBride wrote: > First you need a way to generate an arbitrary stack. Here's a simple > method that just gives you a 50% chance at each level of generating an > extra layer. > > instance Arbitrary a => Arbitrary (Stack a) where > arbitrary = oneof [return Empty, Push <$> arbitrary <*> arbitrary ] > > prop_size_succeeds x s = size (Push x s) > size s > prop_size_fails x s = size s > size Empty > > >quickCheck prop_size_fails > *** Failed! Falsifiable (after 6 tests): > () > Empty > > > On Thu, May 11, 2017 at 3:38 PM, PATRICK BROWNE > wrote: > > Hi, > > I am trying to use Quickcheck to check that pushing an element increases > the > > size of a stack. > > Something like: > > prop_size2 x s = (size (Push x s)) > (size s) > > > > Is this possible? Below is my effort using an empty stack. > > Thanks in advance, > > Pat > > > > > > module Stack (empty, push, pop, top, isEmpty) where > > import Test.QuickCheck > > > > data Stack a = Empty | Push a (Stack a) deriving Show > > > > empty :: Stack a > > empty = Empty > > > > push :: a -> Stack a -> Stack a > > push x ss = Push x ss > > > > pop :: Stack a -> Stack a > > pop Empty = error "pop emptyStack" > > pop (Push x ss) = ss > > > > top :: Stack a -> a > > top Empty = error "top emptyStack" > > top (Push x ss) = x > > > > isEmpty :: Stack a -> Bool > > isEmpty Empty = True > > isEmpty (Push x ss) = False > > > > > > size :: (Stack a) -> Int > > size Empty = 0 > > size (Push x ss) = succ (size ss) > > > > > > prop_size x = (size (Push x Empty)) > (size Empty) > > > > This email originated from DIT. If you received this email in error, > please > > delete it from your system. Please note that if you are not the named > > addressee, disclosing, copying, distributing or taking any action based > on > > the contents of this email or attachments is prohibited. www.dit.ie > > > > Is ó ITBÁC a tháinig an ríomhphost seo. Má fuair tú an ríomhphost seo trí > > earráid, scrios de do chóras é le do thoil. Tabhair ar aird, mura tú an > > seolaí ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon chóipeáil, aon > > dáileadh nó ar aon ghníomh a dhéanfar bunaithe ar an ábhar atá sa > ríomhphost > > nó sna hiatáin seo. www.dit.ie > > > > Tá ITBÁC ag aistriú go Gráinseach Ghormáin – DIT is on the move to > > Grangegorman > > > > > > _______________________________________________ > > Beginners mailing list > > Beginners at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > > > -- This email originated from DIT. If you received this email in error, please delete it from your system. Please note that if you are not the named addressee, disclosing, copying, distributing or taking any action based on the contents of this email or attachments is prohibited. www.dit.ie Is ó ITBÁC a tháinig an ríomhphost seo. Má fuair tú an ríomhphost seo trí earráid, scrios de do chóras é le do thoil. Tabhair ar aird, mura tú an seolaí ainmnithe, go bhfuil dianchosc ar aon nochtadh, aon chóipeáil, aon dáileadh nó ar aon ghníomh a dhéanfar bunaithe ar an ábhar atá sa ríomhphost nó sna hiatáin seo. www.dit.ie Tá ITBÁC ag aistriú go Gráinseach Ghormáin – DIT is on the move to Grangegorman -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike_k_houghton at yahoo.co.uk Fri May 12 07:49:12 2017 From: mike_k_houghton at yahoo.co.uk (mike h) Date: Fri, 12 May 2017 08:49:12 +0100 Subject: [Haskell-beginners] Runge-Kutta and vectors Message-ID: <41C956B2-13A1-4471-885E-08B59A59762C@yahoo.co.uk> Having looked at 'Learn Physics by Programming in Haskell’ I became quite wobbly with excitement! :) So I took and implemented some of their ideas. My University level maths is around 40 years old and so I struggled with some of the later things - but it's slowly coming back! (I have a copy at https://github.com/banditpig/vectors/blob/master/LearnPhysics.pdf) So I have type Scalar = Double type XYZ = (Scalar, Scalar, Scalar) newtype Vector = V { xyz :: XYZ} and set of vector operations (^+^) :: Vector -> Vector -> Vector (^-^) :: Vector -> Vector -> Vector (*^) :: Scalar -> Vector -> Vector (^*) :: Vector -> Scalar -> Vector (^/) :: Vector -> Scalar -> Vector (>.<) :: Vector -> Vector -> Scalar -- dot (><) :: Vector -> Vector -> Vector -- cross etc I then have type Time = Double type Displacement = Vector type Velocity = Vector type State = (Time, Displacement, Velocity) eulerStep :: (State -> Vector) -> Double -> State -> State eulerStep f dt st@(t, r, v) = (t', r', v') where t' = t + dt r' = r ^+^ v ^* dt v' = v ^+^ f st ^* dt and so for a given acceleration function, time step and start state a solution is given by solution :: (State -> Vector) -> Double -> State -> [State] solution a dt = iterate (eulerStep a dt) What I'm trying to do is replace the Euler method of solving with the Rung-Kutta method. I'm really struggling in seeing how the Rung-Kutta examples I've seen are implemented using vectors. How should I progress? Any advice would be welcome! (I really want to implement it using the types I have rather than using an external library ) Many Thanks Mike From zhangnaixiao at me.com Tue May 23 13:58:41 2017 From: zhangnaixiao at me.com (=?utf-8?B?5LmD5r2HIOW8oA==?=) Date: Tue, 23 May 2017 21:58:41 +0800 Subject: [Haskell-beginners] =?utf-8?q?Got_=22parse_error_on_input_?= =?utf-8?b?4oCYPeKAmeKAnSBpbiBFbWFjcyBJbnRlcm8gUkVQTCB3aGVuIGRlZmluZSBh?= =?utf-8?q?ny_function?= Message-ID: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> Hi, I am trying to define some functions in a REPL window of emacs intero. However, I always got "parse error on input ‘=’” as blow: Starting: stack ghci --with-ghc intero "--docker-run-args=--interactive=true --tty=false" --no-build --no-load --ghci-options -odir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea --ghci-options -hidir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea baby Intero 0.1.20 (GHC 8.0.2) Type :intro and press enter for an introduction of the standard commands.  addTwo x y = x + y :2:12: error: parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5’ I did some research, seems like “let” is not a must here for ghci version above 8.0. And my ghc version is 8.0.2. So is it a issue of ghci or intero? Thanks, Sid -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangnaixiao at me.com Tue May 23 14:04:26 2017 From: zhangnaixiao at me.com (=?utf-8?B?5LmD5r2HIOW8oA==?=) Date: Tue, 23 May 2017 22:04:26 +0800 Subject: [Haskell-beginners] =?utf-8?q?Got_=22parse_error_on_input_?= =?utf-8?b?4oCYPeKAmeKAnSBpbiBFbWFjcyBJbnRlcm8gUkVQTCB3aGVuIGRlZmluZSBh?= =?utf-8?q?ny_function?= In-Reply-To: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> Message-ID: I find if I run “stack ghci intero” (remove the “—with-ghc”) from terminal, then the issue will not occur. Does anyone have idea why? > On May 23, 2017, at 9:58 PM, 乃潇 张 wrote: > > Hi, I am trying to define some functions in a REPL window of emacs intero. However, I always got "parse error on input ‘=’” as blow: > > Starting: > stack ghci --with-ghc intero "--docker-run-args=--interactive=true --tty=false" --no-build --no-load --ghci-options -odir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea --ghci-options -hidir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea baby > Intero 0.1.20 (GHC 8.0.2) > Type :intro and press enter for an introduction of the standard commands. > >  addTwo x y = x + y > > :2:12: error: > parse error on input ‘=’ > Perhaps you need a 'let' in a 'do' block? > e.g. 'let x = 5' instead of 'x = 5’ > > I did some research, seems like “let” is not a must here for ghci version above 8.0. And my ghc version is 8.0.2. So is it a issue of ghci or intero? > > > Thanks, > Sid > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners -------------- next part -------------- An HTML attachment was scrubbed... URL: From aquagnu at gmail.com Tue May 23 16:22:04 2017 From: aquagnu at gmail.com (baa dg) Date: Tue, 23 May 2017 19:22:04 +0300 Subject: [Haskell-beginners] =?utf-8?q?Got_=22parse_error_on_input_?= =?utf-8?b?4oCYPeKAmeKAnSBpbiBFbWFjcyBJbnRlcm8gUkVQTCB3aGVuIGRlZmlu?= =?utf-8?q?e_any_function?= In-Reply-To: References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> Message-ID: try with "let": let f x y = x + y 2017-05-23 17:04 GMT+03:00 乃潇 张 : > I find if I run “stack ghci intero” (remove the “—with-ghc”) from > terminal, then the issue will not occur. Does anyone have idea why? > > On May 23, 2017, at 9:58 PM, 乃潇 张 wrote: > > Hi, I am trying to define some functions in a REPL window of emacs intero. > However, I always got "parse error on input ‘=’” as blow: > > Starting: > stack ghci --with-ghc intero "--docker-run-args=--interactive=true > --tty=false" --no-build --no-load --ghci-options -odir=/Users/spike/Code/ > haskell/learn-haskell/baby/.stack-work/intero/intero445zea --ghci-options > -hidir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea > baby > Intero 0.1.20 (GHC 8.0.2) > Type :intro and press enter for an introduction of the standard commands. > > addTwo x y = x + y > > :2:12: error: > parse error on input ‘=’ > Perhaps you need a 'let' in a 'do' block? > e.g. 'let x = 5' instead of 'x = 5’ > > I did some research, seems like “let” is not a must here for ghci version > above 8.0. And my ghc version is 8.0.2. So is it a issue of ghci or intero? > > > Thanks, > Sid > _______________________________________________ > 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: From zhangnaixiao at me.com Wed May 24 01:04:44 2017 From: zhangnaixiao at me.com (=?utf-8?B?5LmD5r2HIOW8oA==?=) Date: Wed, 24 May 2017 09:04:44 +0800 Subject: [Haskell-beginners] =?utf-8?q?Got_=22parse_error_on_input_?= =?utf-8?b?4oCYPeKAmeKAnSBpbiBFbWFjcyBJbnRlcm8gUkVQTCB3aGVuIGRlZmluZSBh?= =?utf-8?q?ny_function?= In-Reply-To: References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> Message-ID: Thanks, I know if using “let”, there’ll be no error. My question is: 1. what does option "—with-ghc” do? 2. Is it better to remove “—with-ghc” when running in intero REPL? If yes, how to remove it? > On May 24, 2017, at 12:22 AM, baa dg wrote: > > try with "let": > let f x y = x + y > > 2017-05-23 17:04 GMT+03:00 乃潇 张 >: > I find if I run “stack ghci intero” (remove the “—with-ghc”) from terminal, then the issue will not occur. Does anyone have idea why? > >> On May 23, 2017, at 9:58 PM, 乃潇 张 > wrote: >> >> Hi, I am trying to define some functions in a REPL window of emacs intero. However, I always got "parse error on input ‘=’” as blow: >> >> Starting: >> stack ghci --with-ghc intero "--docker-run-args=--interactive=true --tty=false" --no-build --no-load --ghci-options -odir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea --ghci-options -hidir=/Users/spike/Code/haskell/learn-haskell/baby/.stack-work/intero/intero445zea baby >> Intero 0.1.20 (GHC 8.0.2) >> Type :intro and press enter for an introduction of the standard commands. >> >> addTwo x y = x + y >> >> :2:12: error: >> parse error on input ‘=’ >> Perhaps you need a 'let' in a 'do' block? >> e.g. 'let x = 5' instead of 'x = 5’ >> >> I did some research, seems like “let” is not a must here for ghci version above 8.0. And my ghc version is 8.0.2. So is it a issue of ghci or intero? >> >> >> Thanks, >> Sid >> _______________________________________________ >> 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: From mihai.maruseac at gmail.com Wed May 24 14:46:32 2017 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Wed, 24 May 2017 07:46:32 -0700 Subject: [Haskell-beginners] ANNOUNCE: Haskell Communities and Activities Report (32nd ed., May 2017) Message-ID: On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (32nd edition, May 2017) is now available, in PDF and HTML formats: http://haskell.org/communities/05-2017/report.pdf http://haskell.org/communities/05-2017/html/report.html All previous editions of HCAR can be accessed on the wiki at https://wiki.haskell.org/Haskell_Communities_and_Activities_Report Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editors collect all the contributions into a single report and feed that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ======================================== End of September 2016: target deadline for contributions to the November 2017 edition of the HCAR Report ======================================== Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editors for a simple e-mail reminder in November (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From frederic-emmanuel.picca at synchrotron-soleil.fr Wed May 24 12:18:21 2017 From: frederic-emmanuel.picca at synchrotron-soleil.fr (PICCA Frederic-Emmanuel) Date: Wed, 24 May 2017 12:18:21 +0000 Subject: [Haskell-beginners] Attoparsec parser question Message-ID: Hello I have this kind ot type data PoniEntry a = PoniEntry { poniEntryHeader :: [Text] , poniEntryDetector :: (Maybe (Detector a)) -- ^ Detector Name , poniEntryPixelSize1 :: (Length Double) -- ^ pixels size 1 , poniEntryPixelSize2 :: (Length Double) -- ^ pixels size 1 , poniEntryDistance :: (Length Double) -- ^ pixels size 2 , poniEntryPoni1 :: (Length Double) -- ^ poni1 , poniEntryPoni2 :: (Length Double) -- ^ poni2 , poniEntryRot1 :: (Angle Double) -- ^ rot1 , poniEntryRot2 :: (Angle Double) -- ^ rot2 , poniEntryRot3 :: (Angle Double) -- ^ rot3 , poniEntrySpline :: (Maybe Text) -- ^ spline file , poniEntryWavelength :: WaveLength -- ^ wavelength } deriving (Show) type Poni a = [PoniEntry a] And I try to create a Parser for the Poni type lengthP :: Text -> Parser (Length Double) lengthP key = do value <-doubleP key pure $ value *~ meter detectorP ∷ ToPyFAI a ⇒ a → Parser a detectorP a = do _ ← "Detector: " *> string (toPyFAI a) <* endOfLine pure a poniEntryP ∷ Detector a ⇒ a → Parser (PoniEntry a) poniEntryP a = PoniEntry <$> headerP <*> optional (detectorP a) <*> lengthP "PixelSize1: " <*> lengthP "PixelSize2: " <*> lengthP "Distance: " <*> lengthP "Poni1: " <*> lengthP "Poni2: " <*> angleP "Rot1: " <*> angleP "Rot2: " <*> angleP "Rot3: " <*> optional ("SplineFile: " *> takeTill isEndOfLine <* endOfLine) <*> lengthP "Wavelength: " "poniEntryP" poniP :: Detector a ⇒ a → Parser (Poni a) poniP a = some (poniEntryP a) But when I compile this I get this error message. src/Hkl/PyFAI/Poni.hs:(118,16)-(131,24): Couldn't match type `attoparsec-0.10.4.0:Data.Attoparsec.Internal.Types.Parser Text (PoniEntry a)' with `a -> Parser (PoniEntry a)' Expected type: a -> Parser (PoniEntry a) Actual type: Parser (PoniEntry a) In the expression: PoniEntry <$> headerP <*> optional (detectorP a) <*> lengthP "PixelSize1: " <*> lengthP "PixelSize2: " <*> lengthP "Distance: " <*> lengthP "Poni1: " <*> lengthP "Poni2: " <*> angleP "Rot1: " <*> angleP "Rot2: " <*> angleP "Rot3: " <*> optional ("SplineFile: " *> takeTill isEndOfLine <* endOfLine) <*> lengthP "Wavelength: " "poniEntryP" In an equation for `poniEntryP': poniEntryP a = PoniEntry <$> headerP <*> optional (detectorP a) <*> lengthP "PixelSize1: " <*> lengthP "PixelSize2: " <*> lengthP "Distance: " <*> lengthP "Poni1: " <*> lengthP "Poni2: " <*> angleP "Rot1: " <*> angleP "Rot2: " <*> angleP "Rot3: " <*> optional ("SplineFile: " *> takeTill isEndOfLine <* endOfLine) <*> lengthP "Wavelength: " "poniEntryP" src/Hkl/PyFAI/Poni.hs:134:11-29: Couldn't match type `[Parser (PoniEntry a)]' with `Parser (Poni a)' Expected type: a -> Parser (Poni a) Actual type: a -> [Parser (PoniEntry a)] In the return type of a call of `some' In the expression: some (poniEntryP a) In an equation for `poniP': poniP a = some (poniEntryP a) I must say, that I do not understand what is wrong with my code. The lengthP code is ok, so why the detectorP is wrong ? thanks for your help Frederic From fa-ml at ariis.it Wed May 24 16:20:23 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Wed, 24 May 2017 18:20:23 +0200 Subject: [Haskell-beginners] Attoparsec parser question In-Reply-To: References: Message-ID: <20170524162023.GB20506@casa.casa> On Wed, May 24, 2017 at 12:18:21PM +0000, PICCA Frederic-Emmanuel wrote: > Hello Hello Frederic, maybe next time attach a simple .hs file which replicates the issue (with import modules, etc.), this way it is simpler to diagnose. Just by scanning the code, this raises a red flag: > detectorP ∷ ToPyFAI a ⇒ a → Parser a > detectorP a = do > _ ← "Detector: " *> string (toPyFAI a) <* endOfLine > pure a "Detector: " is a plain String, so i guess putting a `string` before it (or whatever is needed) should solve the issue. Does that solve the problem? -F From aquagnu at gmail.com Thu May 25 15:10:27 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 25 May 2017 18:10:27 +0300 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> Message-ID: <20170525181027.1a74deff@Pavel> Hello, everybody! I can process list in monad style with "do" syntax and to use "guard" function in the body. Something like: fn :: [a] -> [a] fn lst = do el <- lst guard $ condition el ... return $ change el How can I do the same but with possibility to call "tell" of "Write" monad in the fn's body? As I understand it should be: ListT (Writer w) Int for this example? - but how to write it? - how to call (run) it? - and how is it safe ("transformers" package has bug in ListT, so "mtl" must be used?)? - is there other canonical way to do it without to use fold*, recursive calls/fix, State/RWS ? /Cheers From fa-ml at ariis.it Thu May 25 15:43:49 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 25 May 2017 17:43:49 +0200 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525181027.1a74deff@Pavel> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> Message-ID: <20170525154349.GA9213@casa.casa> On Thu, May 25, 2017 at 06:10:27PM +0300, Baa wrote: > fn :: [a] -> [a] > fn lst = do > el <- lst > guard $ condition el > ... > return $ change el > > How can I do the same but with possibility to call "tell" of "Write" > monad in the fn's body? As I understand it should be: Should be as easy as: import Control.Monad.List import Control.Monad.Writer type Prova = ListT (Writer String) Int fn :: Prova -> Prova fn lst = do el <- lst guard (rem el 2 == 0) lift $ tell "hey bby" return (el + 1) From toad3k at gmail.com Thu May 25 15:52:01 2017 From: toad3k at gmail.com (David McBride) Date: Thu, 25 May 2017 11:52:01 -0400 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525181027.1a74deff@Pavel> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> Message-ID: ListT is a bit weird in that it affects whatever monad is underneath it, so the order of your types in your Transformer stack matters. Both ways have different meanings and each have legitimate uses. In any case you must use the lift function to get to the monad below the one you are at. import Control.Monad.List import Control.Monad.Writer test :: IO () test = do (runListT $ runWriterT proc1) >>= print (runWriterT $ runListT proc2) >>= print return () proc1 :: Monad m => WriterT String (ListT m) Int proc1 = do tell ("started: " :: String) x <- lift $ ListT (return [1,2]) y <- lift $ ListT (return [3,4,5]) lift $ guard (y /= 5) tell ("x:" ++ show x) tell ("y:" ++ show y) return (x * y) proc2 :: Monad m => ListT (WriterT String m) Int proc2 = do lift $ tell ("started: " :: String) x <- ListT (return [1,2]) y <- ListT (return [3,4,5]) guard (y /= 5) lift $ tell (" x:" ++ show x) lift $ tell (" y:" ++ show y) return (x * y) On Thu, May 25, 2017 at 11:10 AM, Baa wrote: > Hello, everybody! > > I can process list in monad style with "do" syntax and to use "guard" > function in the body. Something like: > > fn :: [a] -> [a] > fn lst = do > el <- lst > guard $ condition el > ... > return $ change el > > How can I do the same but with possibility to call "tell" of "Write" > monad in the fn's body? As I understand it should be: > > ListT (Writer w) Int > > for this example? > > - but how to write it? > - how to call (run) it? > - and how is it safe ("transformers" package has bug in ListT, so "mtl" > must be used?)? > - is there other canonical way to do it without to use fold*, recursive > calls/fix, State/RWS ? > > > /Cheers > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From aquagnu at gmail.com Thu May 25 16:02:58 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 25 May 2017 19:02:58 +0300 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525154349.GA9213@casa.casa> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525154349.GA9213@casa.casa> Message-ID: <20170525190258.7b6b0c13@Pavel> В Thu, 25 May 2017 17:43:49 +0200 Francesco Ariis пишет: > On Thu, May 25, 2017 at 06:10:27PM +0300, Baa wrote: > > fn :: [a] -> [a] > > fn lst = do > > el <- lst > > guard $ condition el > > ... > > return $ change el > > > > How can I do the same but with possibility to call "tell" of "Write" > > monad in the fn's body? As I understand it should be: > > Should be as easy as: > > import Control.Monad.List > import Control.Monad.Writer > > type Prova = ListT (Writer String) Int > > fn :: Prova -> Prova > fn lst = do el <- lst > guard (rem el 2 == 0) > lift $ tell "hey bby" > return (el + 1) Yes! And this is the source of my questions.. 1) How to call it? 2) What does mean to provide argument of type ".. Writer .."? As result, it's good: you can run it with "runWriter", but what is "writer" in input argument? Fake writer (which is ignoring)? > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From aquagnu at gmail.com Thu May 25 16:11:50 2017 From: aquagnu at gmail.com (Baa) Date: Thu, 25 May 2017 19:11:50 +0300 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> Message-ID: <20170525191150.51d8e3ac@Pavel> В Thu, 25 May 2017 11:52:01 -0400 David McBride пишет: Hello, David! Am I right that "WriterT ... ListT" is "list of writers"? As I understand, internal representation is "m (a, w)" where m is a-la List? So, this is list of "writers"? I am confused only of this "m" in your "proc1" function, because I suppose this must be Identity and type becomes "WriterT String [Int]" ? Or? Can this function "proc1" be modified in the way to get input list and to "iterate" over its elements with "do el <- ..." but to can call Writer's tell in the same time? This is the problem for my mind - I can not understand how to pass input list and to have writer inside :) You call ListT's bind but over internal hardcoded list values... > ListT is a bit weird in that it affects whatever monad is underneath > it, so the order of your types in your Transformer stack matters. > Both ways have different meanings and each have legitimate uses. In > any case you must use the lift function to get to the monad below the > one you are at. > > import Control.Monad.List > import Control.Monad.Writer > > test :: IO () > test = do > (runListT $ runWriterT proc1) >>= print > (runWriterT $ runListT proc2) >>= print > return () > > > proc1 :: Monad m => WriterT String (ListT m) Int > proc1 = do > tell ("started: " :: String) > x <- lift $ ListT (return [1,2]) > y <- lift $ ListT (return [3,4,5]) > lift $ guard (y /= 5) > tell ("x:" ++ show x) > tell ("y:" ++ show y) > return (x * y) > > > proc2 :: Monad m => ListT (WriterT String m) Int > proc2 = do > lift $ tell ("started: " :: String) > x <- ListT (return [1,2]) > y <- ListT (return [3,4,5]) > guard (y /= 5) > lift $ tell (" x:" ++ show x) > lift $ tell (" y:" ++ show y) > > return (x * y) > > On Thu, May 25, 2017 at 11:10 AM, Baa wrote: > > Hello, everybody! > > > > I can process list in monad style with "do" syntax and to use > > "guard" function in the body. Something like: > > > > fn :: [a] -> [a] > > fn lst = do > > el <- lst > > guard $ condition el > > ... > > return $ change el > > > > How can I do the same but with possibility to call "tell" of "Write" > > monad in the fn's body? As I understand it should be: > > > > ListT (Writer w) Int > > > > for this example? > > > > - but how to write it? > > - how to call (run) it? > > - and how is it safe ("transformers" package has bug in ListT, so > > "mtl" must be used?)? > > - is there other canonical way to do it without to use fold*, > > recursive calls/fix, State/RWS ? > > > > > > /Cheers > > _______________________________________________ > > 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 From toad3k at gmail.com Thu May 25 16:55:00 2017 From: toad3k at gmail.com (David McBride) Date: Thu, 25 May 2017 12:55:00 -0400 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525191150.51d8e3ac@Pavel> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525191150.51d8e3ac@Pavel> Message-ID: To start all these types with T at the end are transformers. They are a type that is wrapped around some inner m. StateT s m, ErrorT e m a, and so on. In order to use do notation, you must be in a type which is an instance of Monad. newtype ListT (m :: * -> *) a = ListT {runListT :: m [a]} instance [safe] Monad m => Monad (ListT m) newtype WriterT w (m :: * -> *) a = WriterT {runWriterT :: m (a, w)} instance [safe] (Monoid w, Monad m) => MonadWriter w (WriterT w m) These types and their instances say the following: ListT m a is a Monad if m is a Monad. WriterT w m a is a Monad if m is a Monad and w is a Monoid. So in order to use do notation in a WriterT String (ListT m) a, I must add the Monad m contstraint to proc, and also ensure that the writer's w is a monoid (it is because it is a string). Now to pass in a ListT as an argument, I must construct one. Remember that in order to use the return function, m must be in a monad, so I must add the Monad constraint. foo :: Monad m => ListT m Int foo = ListT (return [1,2,3]) test = (runListT $ runWriterT (proc3 foo)) >>= print proc3 :: Monad m => ListT m Int -> WriterT String (ListT m) Int proc3 foo = do tell ("started: " :: String) x <- lift foo y <- lift $ ListT (return [3,4,5]) lift $ guard (y /= 5) tell ("x:" ++ show x) tell ("y:" ++ show y) return (x * y) As you saw in the other comment in this thread, most people use a type alias to make it more palatable. type MyApp m a = WriterT String (ListT m) Int -- or type MyApp a = WriterT String (ListT IO) Int proc3 :: Monad m =>ListT m a -> MyApp m Int -- or proc3 :: ListT m a -> MyApp Int On Thu, May 25, 2017 at 12:11 PM, Baa wrote: > В Thu, 25 May 2017 11:52:01 -0400 > David McBride пишет: > > Hello, David! Am I right that "WriterT ... ListT" is "list of writers"? > As I understand, internal representation is "m (a, w)" where m is a-la > List? So, this is list of "writers"? I am confused only of this "m" in > your "proc1" function, because I suppose this must be Identity and type > becomes "WriterT String [Int]" ? Or? > > Can this function "proc1" be modified in the way to get input list and > to "iterate" over its elements with "do el <- ..." but to can call > Writer's tell in the same time? This is the problem for my mind - I can > not understand how to pass input list and to have writer inside :) You > call ListT's bind but over internal hardcoded list values... > > >> ListT is a bit weird in that it affects whatever monad is underneath >> it, so the order of your types in your Transformer stack matters. >> Both ways have different meanings and each have legitimate uses. In >> any case you must use the lift function to get to the monad below the >> one you are at. >> >> import Control.Monad.List >> import Control.Monad.Writer >> >> test :: IO () >> test = do >> (runListT $ runWriterT proc1) >>= print >> (runWriterT $ runListT proc2) >>= print >> return () >> >> >> proc1 :: Monad m => WriterT String (ListT m) Int >> proc1 = do >> tell ("started: " :: String) >> x <- lift $ ListT (return [1,2]) >> y <- lift $ ListT (return [3,4,5]) >> lift $ guard (y /= 5) >> tell ("x:" ++ show x) >> tell ("y:" ++ show y) >> return (x * y) >> >> >> proc2 :: Monad m => ListT (WriterT String m) Int >> proc2 = do >> lift $ tell ("started: " :: String) >> x <- ListT (return [1,2]) >> y <- ListT (return [3,4,5]) >> guard (y /= 5) >> lift $ tell (" x:" ++ show x) >> lift $ tell (" y:" ++ show y) >> >> return (x * y) >> >> On Thu, May 25, 2017 at 11:10 AM, Baa wrote: >> > Hello, everybody! >> > >> > I can process list in monad style with "do" syntax and to use >> > "guard" function in the body. Something like: >> > >> > fn :: [a] -> [a] >> > fn lst = do >> > el <- lst >> > guard $ condition el >> > ... >> > return $ change el >> > >> > How can I do the same but with possibility to call "tell" of "Write" >> > monad in the fn's body? As I understand it should be: >> > >> > ListT (Writer w) Int >> > >> > for this example? >> > >> > - but how to write it? >> > - how to call (run) it? >> > - and how is it safe ("transformers" package has bug in ListT, so >> > "mtl" must be used?)? >> > - is there other canonical way to do it without to use fold*, >> > recursive calls/fix, State/RWS ? >> > >> > >> > /Cheers >> > _______________________________________________ >> > 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 From aquagnu at gmail.com Thu May 25 18:37:03 2017 From: aquagnu at gmail.com (aquagnu) Date: Thu, 25 May 2017 21:37:03 +0300 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525191150.51d8e3ac@Pavel> Message-ID: <20170525213703.54e8296a@gmail.com> David, many thanks for such a detailed answer and explanation!! So, if I know that I'll iterate over list (vs abstract "m"'s bind), can I replace "m" with Identity, to get list instead of abstract "ListT m"? And last question: what is more canonical (Haskelish) way to iterate over list with state? Fold*/State/Writer? Actually my ultimate goal was to process list items with some state and possible IO (REST calls, something else)... Is the usage of ListT + Writer (or ListT + State) a good solution or better is to make all logic in one function and to pass it to fold* (so state will be accumulating value)? I will iterate over items of items of this list too: some of them are also lists, so ListT looks more naturally IMHO, but I'm not sure... David, in all cases - many thanks!! В Thu, 25 May 2017 12:55:00 -0400 David McBride пишет: > To start all these types with T at the end are transformers. They are > a type that is wrapped around some inner m. StateT s m, ErrorT e m a, > and so on. > > In order to use do notation, you must be in a type which is an > instance of Monad. > > newtype ListT (m :: * -> *) a = ListT {runListT :: m [a]} > instance [safe] Monad m => Monad (ListT m) > > newtype WriterT w (m :: * -> *) a = WriterT {runWriterT :: m (a, w)} > instance [safe] (Monoid w, Monad m) => MonadWriter w (WriterT w m) > > These types and their instances say the following: > ListT m a is a Monad if m is a Monad. > WriterT w m a is a Monad if m is a Monad and w is a Monoid. > > So in order to use do notation in a WriterT String (ListT m) a, I must > add the Monad m contstraint to proc, and also ensure that the writer's > w is a monoid (it is because it is a string). > > Now to pass in a ListT as an argument, I must construct one. Remember > that in order to use the return function, m must be in a monad, so I > must add the Monad constraint. > > foo :: Monad m => ListT m Int > foo = ListT (return [1,2,3]) > > test = (runListT $ runWriterT (proc3 foo)) >>= print > > proc3 :: Monad m => ListT m Int -> WriterT String (ListT m) Int > proc3 foo = do > tell ("started: " :: String) > x <- lift foo > y <- lift $ ListT (return [3,4,5]) > lift $ guard (y /= 5) > tell ("x:" ++ show x) > tell ("y:" ++ show y) > return (x * y) > > As you saw in the other comment in this thread, most people use a type > alias to make it more palatable. > > type MyApp m a = WriterT String (ListT m) Int > -- or type MyApp a = WriterT String (ListT IO) Int > > proc3 :: Monad m =>ListT m a -> MyApp m Int > -- or proc3 :: ListT m a -> MyApp Int > > On Thu, May 25, 2017 at 12:11 PM, Baa wrote: > > В Thu, 25 May 2017 11:52:01 -0400 > > David McBride пишет: > > > > Hello, David! Am I right that "WriterT ... ListT" is "list of > > writers"? As I understand, internal representation is "m (a, w)" > > where m is a-la List? So, this is list of "writers"? I am confused > > only of this "m" in your "proc1" function, because I suppose this > > must be Identity and type becomes "WriterT String [Int]" ? Or? > > > > Can this function "proc1" be modified in the way to get input list > > and to "iterate" over its elements with "do el <- ..." but to can > > call Writer's tell in the same time? This is the problem for my > > mind - I can not understand how to pass input list and to have > > writer inside :) You call ListT's bind but over internal hardcoded > > list values... > > > > > >> ListT is a bit weird in that it affects whatever monad is > >> underneath it, so the order of your types in your Transformer > >> stack matters. Both ways have different meanings and each have > >> legitimate uses. In any case you must use the lift function to > >> get to the monad below the one you are at. > >> > >> import Control.Monad.List > >> import Control.Monad.Writer > >> > >> test :: IO () > >> test = do > >> (runListT $ runWriterT proc1) >>= print > >> (runWriterT $ runListT proc2) >>= print > >> return () > >> > >> > >> proc1 :: Monad m => WriterT String (ListT m) Int > >> proc1 = do > >> tell ("started: " :: String) > >> x <- lift $ ListT (return [1,2]) > >> y <- lift $ ListT (return [3,4,5]) > >> lift $ guard (y /= 5) > >> tell ("x:" ++ show x) > >> tell ("y:" ++ show y) > >> return (x * y) > >> > >> > >> proc2 :: Monad m => ListT (WriterT String m) Int > >> proc2 = do > >> lift $ tell ("started: " :: String) > >> x <- ListT (return [1,2]) > >> y <- ListT (return [3,4,5]) > >> guard (y /= 5) > >> lift $ tell (" x:" ++ show x) > >> lift $ tell (" y:" ++ show y) > >> > >> return (x * y) > >> > >> On Thu, May 25, 2017 at 11:10 AM, Baa wrote: > >> > Hello, everybody! > >> > > >> > I can process list in monad style with "do" syntax and to use > >> > "guard" function in the body. Something like: > >> > > >> > fn :: [a] -> [a] > >> > fn lst = do > >> > el <- lst > >> > guard $ condition el > >> > ... > >> > return $ change el > >> > > >> > How can I do the same but with possibility to call "tell" of > >> > "Write" monad in the fn's body? As I understand it should be: > >> > > >> > ListT (Writer w) Int > >> > > >> > for this example? > >> > > >> > - but how to write it? > >> > - how to call (run) it? > >> > - and how is it safe ("transformers" package has bug in ListT, so > >> > "mtl" must be used?)? > >> > - is there other canonical way to do it without to use fold*, > >> > recursive calls/fix, State/RWS ? > >> > > >> > > >> > /Cheers > >> > _______________________________________________ > >> > 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 -- Best regards, Paul a.k.a. 6apcyk From fa-ml at ariis.it Thu May 25 18:44:57 2017 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 25 May 2017 20:44:57 +0200 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525190258.7b6b0c13@Pavel> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525154349.GA9213@casa.casa> <20170525190258.7b6b0c13@Pavel> Message-ID: <20170525184457.GA12662@casa.casa> On Thu, May 25, 2017 at 07:02:58PM +0300, Baa wrote: > > В Thu, 25 May 2017 17:43:49 +0200 > > Should be as easy as: > > > > import Control.Monad.List > > import Control.Monad.Writer > > > > type Prova = ListT (Writer String) Int > > Yes! And this is the source of my questions.. 1) How to call it? 2) > What does mean to provide argument of type ".. Writer .."? As result, > it's good: you can run it with "runWriter", but what is "writer" in > input argument? Fake writer (which is ignoring)? I am not sure for question #1. If we look at the constructor of ListT (`runListT :: m [a]`) and MonadWriter (`(a, w)`) and we compose the two we get: ([a], w) -- or ([Integer], String) in our example -- e.g. ListT (writer ([1,2], "ciao")) <-- to construct No idea what is the correct name of this critter. As we can see by running it, the argument in `fn` (both the list part and the string part) is not ignored: λ> fn $ ListT (writer ([1,2], "ciao")) ListT (WriterT (Identity ([3],"ciaohey baby"))) Does this answer your questions? From toad3k at gmail.com Thu May 25 19:10:10 2017 From: toad3k at gmail.com (David McBride) Date: Thu, 25 May 2017 15:10:10 -0400 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525213703.54e8296a@gmail.com> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525191150.51d8e3ac@Pavel> <20170525213703.54e8296a@gmail.com> Message-ID: If you fill in Identity for m, ListT m Int ends up becoming Identity [Int], which is just a list. Doing effects over a list is a classic FoldM. You can use the foldl library on hackage to do most things, I think. To do it over a list of lists, that actually sounds like something you would use ListT for, but I don't use it much in my code, so I can't say for sure how well it will work for you. For what it is worth I've also heard that the version of ListT in base is not quite correct, although I don't know why. If you are feeling adventurous, check out the pipes tutorial http://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-Tutorial.html, there is a ListT done right section toward the end where it shows how to construct and use IO code from his version of a ListT. That would require you to understand and buy into the pipes ecosystem. On Thu, May 25, 2017 at 2:37 PM, aquagnu wrote: > David, many thanks for such a detailed answer and explanation!! > > So, if I know that I'll iterate over list (vs abstract "m"'s bind), can > I replace "m" with Identity, to get list instead of abstract "ListT m"? > > And last question: what is more canonical (Haskelish) way to iterate > over list with state? Fold*/State/Writer? Actually my ultimate goal was > to process list items with some state and possible IO (REST calls, > something else)... Is the usage of ListT + Writer (or ListT + State) a > good solution or better is to make all logic in one function and to > pass it to fold* (so state will be accumulating value)? I will iterate > over items of items of this list too: some of them are also lists, > so ListT looks more naturally IMHO, but I'm not sure... > > David, in all cases - many thanks!! > > > > В Thu, 25 May 2017 12:55:00 -0400 > David McBride пишет: > >> To start all these types with T at the end are transformers. They are >> a type that is wrapped around some inner m. StateT s m, ErrorT e m a, >> and so on. >> >> In order to use do notation, you must be in a type which is an >> instance of Monad. >> >> newtype ListT (m :: * -> *) a = ListT {runListT :: m [a]} >> instance [safe] Monad m => Monad (ListT m) >> >> newtype WriterT w (m :: * -> *) a = WriterT {runWriterT :: m (a, w)} >> instance [safe] (Monoid w, Monad m) => MonadWriter w (WriterT w m) >> >> These types and their instances say the following: >> ListT m a is a Monad if m is a Monad. >> WriterT w m a is a Monad if m is a Monad and w is a Monoid. >> >> So in order to use do notation in a WriterT String (ListT m) a, I must >> add the Monad m contstraint to proc, and also ensure that the writer's >> w is a monoid (it is because it is a string). >> >> Now to pass in a ListT as an argument, I must construct one. Remember >> that in order to use the return function, m must be in a monad, so I >> must add the Monad constraint. >> >> foo :: Monad m => ListT m Int >> foo = ListT (return [1,2,3]) >> >> test = (runListT $ runWriterT (proc3 foo)) >>= print >> >> proc3 :: Monad m => ListT m Int -> WriterT String (ListT m) Int >> proc3 foo = do >> tell ("started: " :: String) >> x <- lift foo >> y <- lift $ ListT (return [3,4,5]) >> lift $ guard (y /= 5) >> tell ("x:" ++ show x) >> tell ("y:" ++ show y) >> return (x * y) >> >> As you saw in the other comment in this thread, most people use a type >> alias to make it more palatable. >> >> type MyApp m a = WriterT String (ListT m) Int >> -- or type MyApp a = WriterT String (ListT IO) Int >> >> proc3 :: Monad m =>ListT m a -> MyApp m Int >> -- or proc3 :: ListT m a -> MyApp Int >> >> On Thu, May 25, 2017 at 12:11 PM, Baa wrote: >> > В Thu, 25 May 2017 11:52:01 -0400 >> > David McBride пишет: >> > >> > Hello, David! Am I right that "WriterT ... ListT" is "list of >> > writers"? As I understand, internal representation is "m (a, w)" >> > where m is a-la List? So, this is list of "writers"? I am confused >> > only of this "m" in your "proc1" function, because I suppose this >> > must be Identity and type becomes "WriterT String [Int]" ? Or? >> > >> > Can this function "proc1" be modified in the way to get input list >> > and to "iterate" over its elements with "do el <- ..." but to can >> > call Writer's tell in the same time? This is the problem for my >> > mind - I can not understand how to pass input list and to have >> > writer inside :) You call ListT's bind but over internal hardcoded >> > list values... >> > >> > >> >> ListT is a bit weird in that it affects whatever monad is >> >> underneath it, so the order of your types in your Transformer >> >> stack matters. Both ways have different meanings and each have >> >> legitimate uses. In any case you must use the lift function to >> >> get to the monad below the one you are at. >> >> >> >> import Control.Monad.List >> >> import Control.Monad.Writer >> >> >> >> test :: IO () >> >> test = do >> >> (runListT $ runWriterT proc1) >>= print >> >> (runWriterT $ runListT proc2) >>= print >> >> return () >> >> >> >> >> >> proc1 :: Monad m => WriterT String (ListT m) Int >> >> proc1 = do >> >> tell ("started: " :: String) >> >> x <- lift $ ListT (return [1,2]) >> >> y <- lift $ ListT (return [3,4,5]) >> >> lift $ guard (y /= 5) >> >> tell ("x:" ++ show x) >> >> tell ("y:" ++ show y) >> >> return (x * y) >> >> >> >> >> >> proc2 :: Monad m => ListT (WriterT String m) Int >> >> proc2 = do >> >> lift $ tell ("started: " :: String) >> >> x <- ListT (return [1,2]) >> >> y <- ListT (return [3,4,5]) >> >> guard (y /= 5) >> >> lift $ tell (" x:" ++ show x) >> >> lift $ tell (" y:" ++ show y) >> >> >> >> return (x * y) >> >> >> >> On Thu, May 25, 2017 at 11:10 AM, Baa wrote: >> >> > Hello, everybody! >> >> > >> >> > I can process list in monad style with "do" syntax and to use >> >> > "guard" function in the body. Something like: >> >> > >> >> > fn :: [a] -> [a] >> >> > fn lst = do >> >> > el <- lst >> >> > guard $ condition el >> >> > ... >> >> > return $ change el >> >> > >> >> > How can I do the same but with possibility to call "tell" of >> >> > "Write" monad in the fn's body? As I understand it should be: >> >> > >> >> > ListT (Writer w) Int >> >> > >> >> > for this example? >> >> > >> >> > - but how to write it? >> >> > - how to call (run) it? >> >> > - and how is it safe ("transformers" package has bug in ListT, so >> >> > "mtl" must be used?)? >> >> > - is there other canonical way to do it without to use fold*, >> >> > recursive calls/fix, State/RWS ? >> >> > >> >> > >> >> > /Cheers >> >> > _______________________________________________ >> >> > 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 > > > > -- > Best regards, > Paul a.k.a. 6apcyk > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From aquagnu at gmail.com Fri May 26 08:16:37 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 26 May 2017 11:16:37 +0300 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: <20170525184457.GA12662@casa.casa> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525154349.GA9213@casa.casa> <20170525190258.7b6b0c13@Pavel> <20170525184457.GA12662@casa.casa> Message-ID: <20170526111559.50bd33dd@Pavel> @Francesco, yes, it completely answers my questions. Thank you very much for clarification!! I got it. В Thu, 25 May 2017 20:44:57 +0200 Francesco Ariis пишет: > On Thu, May 25, 2017 at 07:02:58PM +0300, Baa wrote: > > > > В Thu, 25 May 2017 17:43:49 +0200 > > > Should be as easy as: > > > > > > import Control.Monad.List > > > import Control.Monad.Writer > > > > > > type Prova = ListT (Writer String) Int > > > > Yes! And this is the source of my questions.. 1) How to call it? 2) > > What does mean to provide argument of type ".. Writer .."? As > > result, it's good: you can run it with "runWriter", but what is > > "writer" in input argument? Fake writer (which is ignoring)? > > I am not sure for question #1. If we look at the constructor of ListT > (`runListT :: m [a]`) and MonadWriter (`(a, w)`) and we compose the > two we get: > > ([a], w) > -- or ([Integer], String) in our example > -- e.g. ListT (writer ([1,2], "ciao")) <-- to construct > > No idea what is the correct name of this critter. > > As we can see by running it, the argument in `fn` (both the list part > and the string part) is not ignored: > > λ> fn $ ListT (writer ([1,2], "ciao")) > ListT (WriterT (Identity ([3],"ciaohey baby"))) > > Does this answer your questions? > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners From aquagnu at gmail.com Fri May 26 08:49:43 2017 From: aquagnu at gmail.com (Baa) Date: Fri, 26 May 2017 11:49:43 +0300 Subject: [Haskell-beginners] ListT + Writer In-Reply-To: References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170525181027.1a74deff@Pavel> <20170525191150.51d8e3ac@Pavel> <20170525213703.54e8296a@gmail.com> Message-ID: <20170526114943.177421e6@Pavel> David, On https://hackage.haskell.org/package/transformers-0.5.4.0/docs/Control-Monad-Trans-List.html is written that "Deprecated: This transformer is invalid on most monads". Also I found this: https://wiki.haskell.org/ListT_done_right. But no such warning in the "mtl" package, and I don't know is it done rightly in the "mtl" package... David, what does mean "space leak" here: "Use this foldl library when you want to compute multiple folds over a collection in one pass over the data without space leaks" --http://hackage.haskell.org/package/foldl ? As I understand no real space leak when we are talking about Haskell code, only not optimal usage of memory (for example, thunks number grows up drastically)? Guys, it's so good that there are people like you who have enough time and desire to support us - Haskell beginners. В Thu, 25 May 2017 15:10:10 -0400 David McBride пишет: > If you fill in Identity for m, ListT m Int ends up becoming Identity > [Int], which is just a list. > > Doing effects over a list is a classic FoldM. You can use the foldl > library on hackage to do most things, I think. To do it over a list > of lists, that actually sounds like something you would use ListT for, > but I don't use it much in my code, so I can't say for sure how well > it will work for you. For what it is worth I've also heard that the > version of ListT in base is not quite correct, although I don't know > why. > > If you are feeling adventurous, check out the pipes tutorial > http://hackage.haskell.org/package/pipes-4.3.4/docs/Pipes-Tutorial.html, > there is a ListT done right section toward the end where it shows how > to construct and use IO code from his version of a ListT. That would > require you to understand and buy into the pipes ecosystem. > > On Thu, May 25, 2017 at 2:37 PM, aquagnu wrote: > > David, many thanks for such a detailed answer and explanation!! > > > > So, if I know that I'll iterate over list (vs abstract "m"'s bind), > > can I replace "m" with Identity, to get list instead of abstract > > "ListT m"? > > > > And last question: what is more canonical (Haskelish) way to iterate > > over list with state? Fold*/State/Writer? Actually my ultimate goal > > was to process list items with some state and possible IO (REST > > calls, something else)... Is the usage of ListT + Writer (or ListT > > + State) a good solution or better is to make all logic in one > > function and to pass it to fold* (so state will be accumulating > > value)? I will iterate over items of items of this list too: some > > of them are also lists, so ListT looks more naturally IMHO, but I'm > > not sure... > > > > David, in all cases - many thanks!! > > > > > > > > В Thu, 25 May 2017 12:55:00 -0400 > > David McBride пишет: > > > >> To start all these types with T at the end are transformers. They > >> are a type that is wrapped around some inner m. StateT s m, > >> ErrorT e m a, and so on. > >> > >> In order to use do notation, you must be in a type which is an > >> instance of Monad. > >> > >> newtype ListT (m :: * -> *) a = ListT {runListT :: m [a]} > >> instance [safe] Monad m => Monad (ListT m) > >> > >> newtype WriterT w (m :: * -> *) a = WriterT {runWriterT :: m (a, > >> w)} instance [safe] (Monoid w, Monad m) => MonadWriter w (WriterT > >> w m) > >> > >> These types and their instances say the following: > >> ListT m a is a Monad if m is a Monad. > >> WriterT w m a is a Monad if m is a Monad and w is a Monoid. > >> > >> So in order to use do notation in a WriterT String (ListT m) a, I > >> must add the Monad m contstraint to proc, and also ensure that the > >> writer's w is a monoid (it is because it is a string). > >> > >> Now to pass in a ListT as an argument, I must construct one. > >> Remember that in order to use the return function, m must be in a > >> monad, so I must add the Monad constraint. > >> > >> foo :: Monad m => ListT m Int > >> foo = ListT (return [1,2,3]) > >> > >> test = (runListT $ runWriterT (proc3 foo)) >>= print > >> > >> proc3 :: Monad m => ListT m Int -> WriterT String (ListT m) Int > >> proc3 foo = do > >> tell ("started: " :: String) > >> x <- lift foo > >> y <- lift $ ListT (return [3,4,5]) > >> lift $ guard (y /= 5) > >> tell ("x:" ++ show x) > >> tell ("y:" ++ show y) > >> return (x * y) > >> > >> As you saw in the other comment in this thread, most people use a > >> type alias to make it more palatable. > >> > >> type MyApp m a = WriterT String (ListT m) Int > >> -- or type MyApp a = WriterT String (ListT IO) Int > >> > >> proc3 :: Monad m =>ListT m a -> MyApp m Int > >> -- or proc3 :: ListT m a -> MyApp Int > >> > >> On Thu, May 25, 2017 at 12:11 PM, Baa wrote: > >> > В Thu, 25 May 2017 11:52:01 -0400 > >> > David McBride пишет: > >> > > >> > Hello, David! Am I right that "WriterT ... ListT" is "list of > >> > writers"? As I understand, internal representation is "m (a, w)" > >> > where m is a-la List? So, this is list of "writers"? I am > >> > confused only of this "m" in your "proc1" function, because I > >> > suppose this must be Identity and type becomes "WriterT String > >> > [Int]" ? Or? > >> > > >> > Can this function "proc1" be modified in the way to get input > >> > list and to "iterate" over its elements with "do el <- ..." but > >> > to can call Writer's tell in the same time? This is the problem > >> > for my mind - I can not understand how to pass input list and to > >> > have writer inside :) You call ListT's bind but over internal > >> > hardcoded list values... > >> > > >> > > >> >> ListT is a bit weird in that it affects whatever monad is > >> >> underneath it, so the order of your types in your Transformer > >> >> stack matters. Both ways have different meanings and each have > >> >> legitimate uses. In any case you must use the lift function to > >> >> get to the monad below the one you are at. > >> >> > >> >> import Control.Monad.List > >> >> import Control.Monad.Writer > >> >> > >> >> test :: IO () > >> >> test = do > >> >> (runListT $ runWriterT proc1) >>= print > >> >> (runWriterT $ runListT proc2) >>= print > >> >> return () > >> >> > >> >> > >> >> proc1 :: Monad m => WriterT String (ListT m) Int > >> >> proc1 = do > >> >> tell ("started: " :: String) > >> >> x <- lift $ ListT (return [1,2]) > >> >> y <- lift $ ListT (return [3,4,5]) > >> >> lift $ guard (y /= 5) > >> >> tell ("x:" ++ show x) > >> >> tell ("y:" ++ show y) > >> >> return (x * y) > >> >> > >> >> > >> >> proc2 :: Monad m => ListT (WriterT String m) Int > >> >> proc2 = do > >> >> lift $ tell ("started: " :: String) > >> >> x <- ListT (return [1,2]) > >> >> y <- ListT (return [3,4,5]) > >> >> guard (y /= 5) > >> >> lift $ tell (" x:" ++ show x) > >> >> lift $ tell (" y:" ++ show y) > >> >> > >> >> return (x * y) > >> >> > >> >> On Thu, May 25, 2017 at 11:10 AM, Baa > >> >> wrote: > >> >> > Hello, everybody! > >> >> > > >> >> > I can process list in monad style with "do" syntax and to use > >> >> > "guard" function in the body. Something like: > >> >> > > >> >> > fn :: [a] -> [a] > >> >> > fn lst = do > >> >> > el <- lst > >> >> > guard $ condition el > >> >> > ... > >> >> > return $ change el > >> >> > > >> >> > How can I do the same but with possibility to call "tell" of > >> >> > "Write" monad in the fn's body? As I understand it should be: > >> >> > > >> >> > ListT (Writer w) Int > >> >> > > >> >> > for this example? > >> >> > > >> >> > - but how to write it? > >> >> > - how to call (run) it? > >> >> > - and how is it safe ("transformers" package has bug in > >> >> > ListT, so "mtl" must be used?)? > >> >> > - is there other canonical way to do it without to use fold*, > >> >> > recursive calls/fix, State/RWS ? > >> >> > > >> >> > > >> >> > /Cheers > >> >> > _______________________________________________ > >> >> > 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 > > > > > > > > -- > > Best regards, > > Paul a.k.a. 6apcyk > > _______________________________________________ > > 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 From aquagnu at gmail.com Sat May 27 15:30:28 2017 From: aquagnu at gmail.com (aquagnu) Date: Sat, 27 May 2017 18:30:28 +0300 Subject: [Haskell-beginners] First steps with Streaming library In-Reply-To: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> Message-ID: <20170527183028.01b9d95a@gmail.com> I'm trying to start working with Streaming package. First attempt is to simulate source of stream items (I call the function "gen") and some processor ("proc"). Both should be stateful: to be able to sabe some info about processing steps, etc. ... import Streaming import qualified Streaming.Prelude as S ... gen :: S.Stream (S.Of Int) IO [String] gen = do S.yield 1000 S.yield 2000 x <- lift getLine return ["a", "b", "c", x] -- results proc :: S.Stream (S.Of Int) IO [String] -> S.Stream (S.Of Int) IO [String] proc str = do e <- str lift $ print "Enter x:" x <- lift getLine return $ e ++ [" -- " ++ x] -- put stream items in result main :: IO main = do s <- S.mapM_ print $ S.map show gen p <- S.mapM_ print $ proc gen putStr "s: " >> print s putStr "p: " >> print p And I try to simulate "piping" between "gen" and "proc", seems that function application is enought to compose producers and consumers. But this snippet is not correct: "e <- str" extracts element not from stream, but from results (of "gen"). Even more, I don't know how to "yield" new items, based on stream items. Something like "await" of Conduit, or like in Python "for e in str: ... yield modified(e)...". Is it possible to do it with "do" notation? --- Best, Paul From aquagnu at gmail.com Sun May 28 12:44:55 2017 From: aquagnu at gmail.com (aquagnu) Date: Sun, 28 May 2017 15:44:55 +0300 Subject: [Haskell-beginners] First steps with Streaming library In-Reply-To: <20170527183028.01b9d95a@gmail.com> References: <04C0433B-3D6A-4DE9-ABEC-488EF59859AE@me.com> <20170527183028.01b9d95a@gmail.com> Message-ID: <20170528154455.58109344@gmail.com> I'll try to clarify the question. Sure I can traverse the stream items with function like `a -> m b` applying it with `mapM`. But in this case I will not have access to return of previous stream node, which I'm planning to use as global state for whole pipe workflow: .--state-------+--state'--------+--state''--> | | | [e0..eN] ==> [e0'...eN'] ==> [e0''..eN''] =====> This "state" will be used for statistics, errors, whatever - through the whold workflow. This "pipe" will iterate over `eN` items (which will be streams too), concatenates results... How this can be achieved with Streaming library? I mean each "node" should have access to stream items but to "global" state (result of prev. node return?) too. Is it possible? В Sat, 27 May 2017 18:30:28 +0300 aquagnu пишет: > I'm trying to start working with Streaming package. First attempt > is to simulate source of stream items (I call the function "gen") > and some processor ("proc"). Both should be stateful: to be able > to sabe some info about processing steps, etc. > > ... > import Streaming > import qualified Streaming.Prelude as S > ... > > gen :: S.Stream (S.Of Int) IO [String] > gen = do > S.yield 1000 > S.yield 2000 > x <- lift getLine > return ["a", "b", "c", x] -- results > > proc :: S.Stream (S.Of Int) IO [String] -> S.Stream (S.Of Int) IO > [String] proc str = do > e <- str > lift $ print "Enter x:" > x <- lift getLine > return $ e ++ [" -- " ++ x] -- put stream items in result > > main :: IO > main = do > s <- S.mapM_ print $ S.map show gen > p <- S.mapM_ print $ proc gen > putStr "s: " >> print s > putStr "p: " >> print p > > And I try to simulate "piping" between "gen" and "proc", seems that > function application is enought to compose producers and consumers. > But this snippet is not correct: "e <- str" extracts element not from > stream, but from results (of "gen"). Even more, I don't know how to > "yield" new items, based on stream items. Something like "await" of > Conduit, or like in Python "for e in str: ... yield modified(e)...". > Is it possible to do it with "do" notation? > > --- > Best, > Paul -- Best regards, Paul a.k.a. 6apcyk