Re: [Haskell-cafe] Github support for cabal files
On Sat, 23 Jul 2011 19:25:53 -0700 Greg Weber g...@gregweber.info wrote: I think the haddock description field is a great barrior to documentation. I don't want to clutter my cabal file with lengthy documentation. Michael Snoyberg and I could not figure out how to document the Hamlet syntax because there is no way (as far as I know) to have literal unescaped, uninterpreted text. [1] When I go to a github repo, I expect that I can scroll down to the README and I will get a good overview. When I go to hackage, I expect nothing more than a synopsis, and I hope I can follow several links to find the information I am looking for. It is suggested that the description field should point to a top level module with all the documentation, but although haddock is good for documenting code, it is not an ideal overview style, and not all packages lend themselves well to having one top-level module. I would like a description field that just points to an external (README) file. Cabal could either use the pandoc library, or to avoid that dependency directly it could use the pandoc executable (that would have to be installed first by those of us that want this feature). Alternatively it could just allow an html file for the description and make me responsible for writing a script that runs pandoc and then invokes sdist. [1] http://hackage.haskell.org/package/hamlet The cabal file should be compact, and quite often the description field is very lengthy. I would like it alot if I could reference a README.??? (pandoc compatible extension) from cabal. Then it would be compatible with github and give me more information in my haddock html pages which were generated by `cabal haddock`. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Github support for cabal files
On 24 July 2011 21:11, Joris Putcuyps joris.putcu...@gmail.com wrote: On Sat, 23 Jul 2011 19:25:53 -0700 Greg Weber g...@gregweber.info wrote: I think the haddock description field is a great barrior to documentation. I don't want to clutter my cabal file with lengthy documentation. Michael Snoyberg and I could not figure out how to document the Hamlet syntax because there is no way (as far as I know) to have literal unescaped, uninterpreted text. [1] When I go to a github repo, I expect that I can scroll down to the README and I will get a good overview. When I go to hackage, I expect nothing more than a synopsis, and I hope I can follow several links to find the information I am looking for. It is suggested that the description field should point to a top level module with all the documentation, but although haddock is good for documenting code, it is not an ideal overview style, and not all packages lend themselves well to having one top-level module. I would like a description field that just points to an external (README) file. Cabal could either use the pandoc library, or to avoid that dependency directly it could use the pandoc executable (that would have to be installed first by those of us that want this feature). Alternatively it could just allow an html file for the description and make me responsible for writing a script that runs pandoc and then invokes sdist. [1] http://hackage.haskell.org/package/hamlet The cabal file should be compact, and quite often the description field is very lengthy. I would like it alot if I could reference a README.??? (pandoc compatible extension) from cabal. Then it would be compatible with github and give me more information in my haddock html pages which were generated by `cabal haddock`. Sure, that would be nice; question is, who's going to implement the necessary support in Cabal and Hackage at the very least? :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
Personally, I have nothing against mempty (although I agree that mid makes more sense), but I don't like mappend at all. I wonder what happened to the idea of using instead of mappend (that's what I always do). I think a b c looks so much better than a `mappend` b `mappend` c and it solves the name problem altogether. -- Maciej On Jul 24, 2011 3:42 AM, KC kc1...@gmail.com wrote: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] QuickCheck Questions
Hi all, I would appreciate it if someone can point me in the right direction with the following problem. I'm deliberately implementing a naive Queues packages that uses finite lists as the underlying representation. I've already read through Hughes' paper and the article in The Fun of Programming, but I'm still having some difficulties. Specifically: 1. I have a newtype Queue a = Queue [a] and I want to generate Queues of random Integers that are also of random size. How do I do this in QuickCheck? I guess that I need to write a generator and then make my Queue a concrete type an instance of Arbitrary? How? 2. If I wanted to specify/constrain the ranges of random Integers generated, how would I do this? 3. If I wanted to specify/constrain the Queue sizes how would I do this? On a separate issue, I also see that QuickCheck 2 has some features not discussed anywhere. For example Coarbitrary and shrink are a bit of a mystery to me. Any code examples for any of the above questions would help greatly. I've been stuck on this problem for hours. :) Cheers, Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
Don't forget that some languages use to mean different (as if different meant always superior or inferior...), so some beginners might get confused. I personally often define the alias: (+) = mappend 2011/7/24 Maciej Wos maciej@gmail.com Personally, I have nothing against mempty (although I agree that mid makes more sense), but I don't like mappend at all. I wonder what happened to the idea of using instead of mappend (that's what I always do). I think a b c looks so much better than a `mappend` b `mappend` c and it solves the name problem altogether. -- Maciej On Jul 24, 2011 3:42 AM, KC kc1...@gmail.com wrote: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] file splitter with enumerator package
If you used Data.Enumerator.Text, you would maybe benefit the lines function: lines :: Monad m = Enumeratee Text Text m b But there is something I don't get with that signature: why isn't it: lines :: Monad m = Enumeratee Text [Text] m b ?? 2011/7/23 Eric Rasmussen ericrasmus...@gmail.com Hi Felipe, Thank you for the very detailed explanation and help. Regarding the first point, for this particular use case it's fine if the user-specified file size is extended by the length of a partial line (it's a compact csv file so if the user breaks a big file into 100mb chunks, each chunk would only ever be about 100mb + up to 80 bytes, which is fine for the user). I'm intrigued by the idea of making the bulk copy function with EB.isolate and EB.iterHandle, but I couldn't find a way to fit these into the larger context of writing to multiple file handles. I'll keep working on it and see if I can address the concerns you brought up. Thanks again! Eric On Fri, Jul 22, 2011 at 6:00 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: There is one problem with your algorithm. If the user asks for 4 GiB, then the program will create files with *at least* 4 GiB. So the user would need to ask for less, maybe 3.9 GiB. Even so there's some danger, because there could be a 0.11 GiB line on the file. Now, the biggest problem your code won't run in constant memory. 'EB.take' does not lazily return a lazy ByteString. It strictly returns a lazy ByteString [1]. The lazy ByteString is used to avoid copying data (as it is basically the same as a linked list of strict bytestrings). So if the user asked for 4 GiB files, this program would need at least 4 GiB of memory, probably more due to overheads. If you want to use lazy lazy ByteStrings (lazy ByteStrings with lazy I/O, as oposed to lazy ByteStrings with strict I/O), the enumerator package doesn't really buy you anything. You should just use bytestring package's lazy I/O functions. If you want the guarantee of no leaks that enumerator gives, then you have to use another way of constructing your program. One safe way of doing it is something like: takeNextLine :: E.Iteratee B.ByteString m (Maybe L.ByteString) takeNextLine = ... go :: Monad m = Handle - Int64 - E.Iteratee B.ByteString m (Maybe L.ByteString) go h n = do mline - takeNextLine case mline of Nothing - return Nothing Just line | L.length line = n - L.hPut h line go h (n - L.length line) | otherwise - return mline So 'go h n' is the iteratee that saves at most 'n' bytes in handle 'h' and returns the leftover data. The driver code needs to check its results. Case 'Nothing', then the program finishes. Case 'Just line', save line on a new file and call 'go h2 (n - L.length line)'. It isn't efficient because lines could be small, resulting in many small hPuts (bad). But it is correct and will never use more than 'n' bytes (great). You could also have some compromise where the user says that he'll never have lines longer than 'x' bytes (say, 1 MiB). Then you call a bulk copy function for 'n - x' bytes, and then call 'go h x'. I think you can make the bulk copy function with EB.isolate and EB.iterHandle. Cheers, =) [1] http://hackage.haskell.org/packages/archive/enumerator/0.4.13.1/doc/html/src/Data-Enumerator-Binary.html#take -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] file splitter with enumerator package
On Sun, Jul 24, 2011 at 12:28 PM, Yves Parès limestr...@gmail.com wrote: If you used Data.Enumerator.Text, you would maybe benefit the lines function: lines :: Monad m = Enumeratee Text Text m b It gets arbitrary blocks of text and outputs lines of text. But there is something I don't get with that signature: why isn't it: lines :: Monad m = Enumeratee Text [Text] m b ?? Lists of lines of text? Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] file splitter with enumerator package
Since the program only needs to finish a line after it's made a bulk copy of a potentially large chunk of a file (could be 25 - 500 mb), I was hoping to find a way to copy the large chunk in constant memory and without inspecting the individual bytes/characters. I'm still having some difficulty with this part if anyone has suggestions. Thanks again, Eric On Sun, Jul 24, 2011 at 10:34 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Sun, Jul 24, 2011 at 12:28 PM, Yves Parès limestr...@gmail.com wrote: If you used Data.Enumerator.Text, you would maybe benefit the lines function: lines :: Monad m = Enumeratee Text Text m b It gets arbitrary blocks of text and outputs lines of text. But there is something I don't get with that signature: why isn't it: lines :: Monad m = Enumeratee Text [Text] m b ?? Lists of lines of text? Cheers, =) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
I like the following but again + denotes addition and not a general binary operation. I personally often define the alias: (+) = mappend A lot of math books use + or x enclosed in a circle to indicate that the usual meaning of + nor x is intended for the meaning of the binary operation. I can't figure out if this would compile, the inside () representing a circle. ((+)) = mappend It would be easier for beginners to grok. I don't think so... but while we're at it, what's with that weird name Monoid anyway, let alone Functor, Monad, etc.? ;-) Ivan: I had thought those were words expressing valid mathematical concepts. In order to find similarities between apparently different operations data one wants to reason abstractly; similar to mathematics. -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
On 24 Jul 2011, at 19:19, KC wrote: I like the following but again + denotes addition and not a general binary operation. I personally often define the alias: (+) = mappend A lot of math books use + or x enclosed in a circle to indicate that the usual meaning of + nor x is intended for the meaning of the binary operation. Er no. Both symbols have extremely precise meanings. $\oplus$ is the direct sum of two modules and $\otimes$ is their tensor product. Personally, I wish, given that an additive monad is a kind of monoid, that the names for the zero and addition operations for the two classes were the same. That said, I am not especially happy with mzero and madd, given that their implication, that the monoid is abelian, is generally false. I can't figure out if this would compile, the inside () representing a circle. ((+)) = mappend It would be easier for beginners to grok. I don't think so... but while we're at it, what's with that weird name Monoid anyway, let alone Functor, Monad, etc.? ;-) Ivan: I had thought those were words expressing valid mathematical concepts. In order to find similarities between apparently different operations data one wants to reason abstractly; similar to mathematics. -- -- Regards, KC ___ Beginners mailing list beginn...@haskell.org http://www.haskell.org/mailman/listinfo/beginners ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
Yes, this has sort-of been agreed upon in a GHC ticket about a year ago: http://hackage.haskell.org/trac/ghc/ticket/3339 I had a patch in Darcs, but then came the switch to Git. I ported it to Git, but didn't iron out all the issues. That was quite a while ago so it's currently a bit bitrotten. I don't think it's enough time to get it into 7.2, but since that's largely an unstable release, it wouldn't hurt until 7.4. I'll probably work on it at CamHac in a few weeks. On 24 July 2011 13:14, Maciej Wos maciej@gmail.com wrote: Personally, I have nothing against mempty (although I agree that mid makes more sense), but I don't like mappend at all. I wonder what happened to the idea of using instead of mappend (that's what I always do). I think a b c looks so much better than a `mappend` b `mappend` c and it solves the name problem altogether. -- Maciej On Jul 24, 2011 3:42 AM, KC kc1...@gmail.com wrote: ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck Questions
On Sun, 24 Jul 2011 07:30:56 -0700, Mark Spezzano mark.spezz...@chariot.net.au wrote: Hi all, I would appreciate it if someone can point me in the right direction with the following problem. I'm deliberately implementing a naive Queues packages that uses finite lists as the underlying representation. I've already read through Hughes' paper and the article in The Fun of Programming, but I'm still having some difficulties. Specifically: 1. I have a newtype Queue a = Queue [a] and I want to generate Queues of random Integers that are also of random size. How do I do this in QuickCheck? I guess that I need to write a generator and then make my Queue a concrete type an instance of Arbitrary? How? Mark, One of the great things about QuickCheck is that it is automatically compositional. What I mean by this is that all you need in your instance is how to form a Queue [a] given [a], because there are already QuickCheck instances for forming lists, and as long as a is pretty standard (Integers is fine) then there's likely an Arbitrary instance for that as well. So (from my head, not actually tested in GHC): import Control.Applicative import Test.QuickCheck instance Arbitrary Queue where arbitrary = Queue $ arbitrary Then you can use this as: testProperty length is something propQInts propQInts t = length t == where types = (t :: Queue Integers) The where clause is a fancy way of specifying what the type of t should be without having to express the overall type of propQInts. You could use a more conventional type specification as well. 2. If I wanted to specify/constrain the ranges of random Integers generated, how would I do this? Probably something like this: instance Arbitrary Queue where arbitrary = do li - listOf $ arbitrary lr - liftM $ map rangelimit li return $ Queue lr where rangelimit n = case (n LOW, n HIGH) of (True,_) - LOW (_,True) - HIGH _ - n 3. If I wanted to specify/constrain the Queue sizes how would I do this? Similar to #2. Perhaps: arbitrary = arbitrary = (return . Queue . take CNT . listOf) -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
On Sun, 2011-07-24 at 21:14 +0900, Maciej Wos wrote: Personally, I have nothing against mempty (although I agree that mid makes more sense), but I don't like mappend at all. I wonder what happened to the idea of using instead of mappend (that's what I always do). I think a b c looks so much better than a `mappend` b `mappend` c As of a year or two ago, I think it was common knowledge that this was going to happen. I'd love to see it, definitely. (Regarding it being a comparison operator in other languages, there are plenty of places where operators differ in Haskell... among them, /= and . I don't see this as a serious issue at all. A new language can mean different operators. If there were a *subtle* difference that might be missed, it would be one thing, but this is the sort of thing where if you're confused in that way, nothing will make any sense and you'll ultimately realize that must mean something different.) -- Chris Smith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
On Sat, Jul 23, 2011 at 1:41 PM, KC kc1...@gmail.com wrote: It would be easier for beginners to grok. I think that assumes that all beginners have a strong foundation in algebra. Although it does have the advantage that the names are as abstract as the class. Antoine -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
So is the change taking effect? We were approaching consensus for the addition of of: infixr 6 () :: Monoid m = m - m - m () = mappend and a matching change for (+) in the pretty package. It was also suggested to make () a method of Monoid and insert the following default definitions: () = mappend mappend = () And how about the following: () = mconcat mconcat = () And mempty could be id. The problems with this are: - mconcat is not a binary operator, so using would bring little advantage. You'd always have to use it in its bracketed form, for example. - Changing mempty to id could break a lot of existing code (e.g. due to typeclass ambiguity). This is the main reason. It's also not clear to me that this is a better name (it's just shorter). The current naming of Monoid methods is modelled after list operations, because list is a (the?) free monoid. However, in many cases zero or one would be an equally good name. I think () is fairly uncontroversial because: 1. It's short 2. It's abstract. i.e., no intended pronunciation and it looks like LaTeX's \diamond operator 3. Changing it would be compatible with most existing libraries. For this reason, I think a larger change would have to come with a larger library re-organization. Johan Tibell suggested something like that a while ago: instead of lots of little cuts (backwards incompatible changes), a working group of activists should redesign a whole new (incompatible) alternative set of core libraries. On Sun, Jul 24, 2011 at 11:39 AM, Thomas Schilling nomin...@googlemail.com wrote: Yes, this has sort-of been agreed upon in a GHC ticket about a year ago: http://hackage.haskell.org/trac/ghc/ticket/3339 I had a patch in Darcs, but then came the switch to Git. I ported it to Git, but didn't iron out all the issues. That was quite a while ago so it's currently a bit bitrotten. I don't think it's enough time to get it into 7.2, but since that's largely an unstable release, it wouldn't hurt until 7.4. I'll probably work on it at CamHac in a few weeks. -- -- Regards, KC -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell in the Cloud (http://quid2.org)
Hello Sean, thanks for taking the time to road test quid2.org. And believe me, I totally feel your pain :-) I have just started using it in earnest myself (following the great eat you own dog food principle) and I know how frustrating the whole experience is. However, I am working on it daily and things will improve. Now to come to the points raised in your post: 1) Don't try to use the browser's back button No support for history yet, but is on the todo list. 2) understand the errors They should know look a bit better but there is still a lot of work to do. 3) * Save (with Cmd-S on Mac or Ctrl-S on other systems) before clicking View. * Wait for the done part at the end of the Saving new source message. Sometimes, it doesn't save. Saving is now automatic and you can switch between Edit and View mode without losing your data. You should also see less saving errors. 4) * Don't assume that your saved module is the one being compiled/interpreted. You may want to do a browser refresh to be sure. In one attempt, I produced the following: abcd = abc (where = maps the term on the left to the value on the right) after adding the 'd' to the string and saving the file. There are still inconsistencies when a module is modified, it is next on my todo list. 5) For some reason, the explicit String type is needed for this (minimal) example: concat [a,b,c,d] :: String This is because the OverloadString extension is always active. In the Subject.Quid2.Language module there is now a guide to the differences between standard Haskell and Quid2's own flavour. Keep the feedback coming ! Best, titto On 22 July 2011 16:22, Sean Leather leat...@cs.uu.nl wrote: On Fri, Jul 22, 2011 at 12:00, Pasqualino Titto Assini wrote: Enter Quid2 [1]: the half baked, barely tested, totally unsafe and spectacularly unoptimised Haskell in the Cloud system. Challenging... https://plus.google.com/104222093009939197511/posts/MpgUUayq78o Sean -- Dr. Pasqualino Titto Assini http://quid2.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell in the Cloud (http://quid2.org)
Hi David, no there is no direct relationship to distributed haskell. Quid2's focus is not so much on extending Haskell itself and its runtime to work in a distributed fashion but rather to provide a global naming system for functional values. Very similar to the Web, whose main innovation is to provides a global naming system for all kind of resources that previously had only local names (/dir/myfile versus http://ww.myserver.com/myfile). A description of Quid2 architecture will soon be available and it will be clearer how is meant to work. It will be far from complete, a working functional web will only emerge if many different ideas converge in a coherent whole. Best, titto On 22 July 2011 15:57, David Barbour dmbarb...@gmail.com wrote: Any relationship to distributed haskell? http://www.macs.hw.ac.uk/~dsg/gdh/ On Fri, Jul 22, 2011 at 3:00 AM, Pasqualino Titto Assini tittoass...@gmail.com wrote: Fellow Haskeller, Has your strongly typed, quick checked, formally verified, Oleg blessed, higher order monadic code become a little bit too predictable? Are you feeling a bit bored, emotionally drained and disillusioned with perfection? Longing for the days when Men were Men (and Women were Women for that matter) and squashed bugs out of Assembler code with just their bare hands and a line editor? Enter Quid2 [1]: the half baked, barely tested, totally unsafe and spectacularly unoptimised Haskell in the Cloud system. A delightful blend of Haskell crispiness and JavaScript fluffiness, Quid2 guarantees hours and hours of guilt free hacking enjoyment. Let a soft lamb(a)da rhythm [2] take you over as you gingerly step onto the Haskell Cloud, it's time to party as if it were 1991 all over again! Yours truly, titto [1] http://quid2.org [2] http://www.youtube.com/watch?v=i8mz9uOvFQA -- Dr. Pasqualino Titto Assini http://quid2.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Dr. Pasqualino Titto Assini http://quid2.org/ -- Dr. Pasqualino Titto Assini http://quid2.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
because list is a (the?) free monoid. Yes, all free monoids are isomorphic (to lists). Sebastian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
On 7/24/11 2:29 PM, Julian Porter wrote: On 24 Jul 2011, at 19:19, KC wrote: A lot of math books use + or x enclosed in a circle to indicate that the usual meaning of + nor x is intended for the meaning of the binary operation. Er no. Both symbols have extremely precise meanings. $\oplus$ is the direct sum of two modules and $\otimes$ is their tensor product. Well, they mean that if you're off in module/vector land; but they don't mean that everywhere. Another place they're used frequently is for semirings: with $\oplus$ the associative monoid and $\otimes$ the other monoid. While the tourism board for semirings is less well funded than the one for vectors, it's a beautiful locale with rich history. Natural language processing, graph theory, Boolean algebras, and related logics are nothing to scoff at. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
On Sun, 2011-07-24 at 19:29 +0100, Julian Porter wrote:
On 24 Jul 2011, at 19:19, KC wrote:
I like the following but again + denotes addition and not a
general
binary operation.
I personally often define the alias:
(+) = mappend
A lot of math books use + or x enclosed in a circle to indicate
that the usual meaning of + nor x is intended for the meaning of
the binary operation.
Er no. Both symbols have extremely precise meanings. $\oplus$ is the
direct sum of two modules and $\otimes$ is their tensor product.
Well. Notation depends on branch. I've seen routinely used + as addition
in Z_{2,3,...} - for example 2 + 2 = 0.
For example λ have different meaning when you would say about
exponential distribution/radioactive decay and different when you talk
about wavelength. If you are using lambda calculus it have yet another
meaning. And according to http://en.wikipedia.org/wiki/Lambda those are
just 3 of many meanings.
I've seen ⊕ used as binary operation when the other were already used
before I learned that it may denote the direct sum.
Regards
signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] For class Monoid; better names than mempty mappend might have been: mid (mident) mbinop
On 7/24/11 10:09 PM, Sebastian Fischer wrote: because list is a (the?) free monoid. Yes, all free monoids are isomorphic (to lists). Sebastian For completeness... The free monoid over a set S is the set of all finite sequences of elements drawn from S. Often this is written with the Kleene star: S^*. Finite lists are a particular representation for the free monoid (namely with all operations associated to the right), though this representation may not be isomorphic enough for certain analyses (e.g., algorithmic complexity). Note that the free semigroup over a set S is the set of all finite non-empty sequences of elements drawn from S. We can name this by S^+. Other than the fact that S^+ does not contain the empty sequence, the other important difference is that, while both S^* and S^+ are both closed under the operation, only S^* is co-closed under the operation (i.e., not all elements of S^+ can be decomposed into two elements of S^+ joined by the operator). -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why the reluctance to introduce the Functor requirement on Monad?
I was thinking the reverse. We can already give default implementations of class operations that can be overridden by giving them explicitly when we declare instances, so why shouldn't we be able to give default implementations of operations of more general classes, which could be overridden by a separate instance declaration for these? Then I could say something like a monad is also automatically a functor with fmap by default given by... and if I wanted to give a more efficient fmap for a particular monad I would just instantiate it as a functor explicitly. On Jul 23, 2011, at 3:19 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 24 July 2011 00:49, Sebastien Zany sebast...@chaoticresearch.com wrote: Would it be theoretically possible/convenient to be able to put boilerplate like this in class definitions? Not really: what happens for Functors that aren't Monads? Also, for some Monads there may be a more efficient definition of fmap than using liftM, so even an automatic reverse instance wouldn't always be wanted. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why the reluctance to introduce the Functor requirement on Monad?
On 25 July 2011 13:50, Sebastien Zany sebast...@chaoticresearch.com wrote: I was thinking the reverse. We can already give default implementations of class operations that can be overridden by giving them explicitly when we declare instances, so why shouldn't we be able to give default implementations of operations of more general classes, which could be overridden by a separate instance declaration for these? Then I could say something like a monad is also automatically a functor with fmap by default given by... and if I wanted to give a more efficient fmap for a particular monad I would just instantiate it as a functor explicitly. I believe this has been proposed before, but a major problem is that you cannot do such overriding. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why the reluctance to introduce the Functor requirement on Monad?
Out of (perhaps naive) curiosity, what difficulties does allowing such overriding introduce? Wouldn't the module system prevent the ambiguity of which implementation to use? August Sodora aug...@gmail.com (201) 280-8138 On Sun, Jul 24, 2011 at 11:55 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 25 July 2011 13:50, Sebastien Zany sebast...@chaoticresearch.com wrote: I was thinking the reverse. We can already give default implementations of class operations that can be overridden by giving them explicitly when we declare instances, so why shouldn't we be able to give default implementations of operations of more general classes, which could be overridden by a separate instance declaration for these? Then I could say something like a monad is also automatically a functor with fmap by default given by... and if I wanted to give a more efficient fmap for a particular monad I would just instantiate it as a functor explicitly. I believe this has been proposed before, but a major problem is that you cannot do such overriding. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck Questions
Hi Kevin, Thanks for the response. The first part works well with minor modifications. Part 2 is still a bit vague to me. I basically want to clamp the Integers generated within the Queue to between 0 and some positive number. At present they're giving me numbers all over the place (specifically negative number) Thanks Mark On 25/07/2011, at 4:44 AM, Kevin Quick wrote: On Sun, 24 Jul 2011 07:30:56 -0700, Mark Spezzano mark.spezz...@chariot.net.au wrote: Hi all, I would appreciate it if someone can point me in the right direction with the following problem. I'm deliberately implementing a naive Queues packages that uses finite lists as the underlying representation. I've already read through Hughes' paper and the article in The Fun of Programming, but I'm still having some difficulties. Specifically: 1. I have a newtype Queue a = Queue [a] and I want to generate Queues of random Integers that are also of random size. How do I do this in QuickCheck? I guess that I need to write a generator and then make my Queue a concrete type an instance of Arbitrary? How? Mark, One of the great things about QuickCheck is that it is automatically compositional. What I mean by this is that all you need in your instance is how to form a Queue [a] given [a], because there are already QuickCheck instances for forming lists, and as long as a is pretty standard (Integers is fine) then there's likely an Arbitrary instance for that as well. So (from my head, not actually tested in GHC): import Control.Applicative import Test.QuickCheck instance Arbitrary Queue where arbitrary = Queue $ arbitrary Then you can use this as: testProperty length is something propQInts propQInts t = length t == where types = (t :: Queue Integers) The where clause is a fancy way of specifying what the type of t should be without having to express the overall type of propQInts. You could use a more conventional type specification as well. 2. If I wanted to specify/constrain the ranges of random Integers generated, how would I do this? Probably something like this: instance Arbitrary Queue where arbitrary = do li - listOf $ arbitrary lr - liftM $ map rangelimit li return $ Queue lr where rangelimit n = case (n LOW, n HIGH) of (True,_) - LOW (_,True) - HIGH _ - n 3. If I wanted to specify/constrain the Queue sizes how would I do this? Similar to #2. Perhaps: arbitrary = arbitrary = (return . Queue . take CNT . listOf) -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] QuickCheck Questions
On 25 July 2011 14:31, Mark Spezzano mark.spezz...@chariot.net.au wrote: Hi Kevin, Thanks for the response. The first part works well with minor modifications. Part 2 is still a bit vague to me. I basically want to clamp the Integers generated within the Queue to between 0 and some positive number. At present they're giving me numbers all over the place (specifically negative number) QuickCheck has a NonNegative newtype wrapper you can use for the =0 criteria; to specify the maximum, use the resize function (the instance for Int, etc. use the current size parameter as the maximum value). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
