Re: [Haskell-cafe] UTF-8 in Haskell.
On Thu, 2010-12-23 at 14:15 +0800, Magicloud Magiclouds wrote: On Thu, Dec 23, 2010 at 2:01 PM, Mark Lentczner ma...@glyphic.com wrote: On Dec 22, 2010, at 9:29 PM, Magicloud Magiclouds wrote: Thus under all situation (ascii, UTF-8, or even UTF-32), my program always send 4 bytes through the network. Is that OK? Generally, no. Haskell strings are sequences of Unicode characters. Each character has an integral code point value, from 0 to 0x10, but technically, the code point itself is just a number, not a pattern of bits to be exchanged. That is an encoding. In any protocol you need know the encoding before you exchange characters as bytes or words. In some protocols it is implicit, in others explicit in header or meta data, and in yet others (IRC comes to mind) it is undefined (which makes problems for the user). The UTF-8 encoding uses a variable number of bytes to represent each character, depending on the code point, not Word32 as you suggested. Converting from Haskell's String to various encodings can be done with either the text package or utf8-string package. - Mark I see. I just realize that, in this case (ssh), I could use CString to avoid all problems about encoding. By using CString you may avoid problems by putting them on users. CString is char * and Foreign marshaling just use ASCII. And as non only English speaking user of computer programs I ask to have support of unicode (for example utf-8). Unless you mean only commands, not data, in which you probably should check details of protocol. In any case I don't think that CString is correct approach to network data and you probably should use ByteString in place of CString. 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
[Haskell-cafe] New simplified primes; no VIP necessary.
Hi, For those who remember the discussion about this about a year ago, it turns out there was a simpler version after all lurking somewhere in there (or is it _out_?). I've just posted it to the haskellwiki's Prime Numbers page: primes = 2: primes' where primes' = 3: 5: [7,9..] `minus` tfold [ [p*p,p*p+2*p..] | p - primes' ] tfold ((x:xs):t)= x : xs `union` tfold (pairs t) pairs ((x:xs):ys:t) = (x: union xs ys) : pairs t The full code with double-feed, wheel and better folding structure is also there. Speed and complexity weren't changed by this. But it is rather _short_. :) Cheers, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functor = Applicative = Monad
On 22/12/10 19:17, John Smith wrote: On 22/12/2010 19:03, Simon Marlow wrote: On 14/12/2010 08:35, Isaac Dupree wrote: On 12/14/10 03:13, John Smith wrote: I would like to formally propose that Monad become a subclass of Applicative, with a call for consensus by 1 February. The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, That page isn't written as a proposal yet, it's written as a bunch of ideas. I would be happy to see something along the lines of Bas van Dijk's work http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/14740 . This is a proposal with far-reaching consequences, and with several alternative designs. I'm not sure I understand all the tradeoffs. Some parts of the proposal are orthogonal to the rest (e.g. changing fmap to map), and should probably be considered separately. Could someone please write a detailed proposal, enumerating all the pros and cons, and the rationale for this design compared to other designs? Cheers, Simon The wiki page was admittedly too broad of scope when I first wrote it, and it's getting broader with time. The ticket at http://hackage.haskell.org/trac/ghc/ticket/4834 has patches for only one change, making Monad a subclass of Applicative. (I would update the description to make this clear, but I can't edit the ticket description, so this has been relegated to a comment.) Dealing with one issue at a time is great. But even with this single change, we need to weight up the advantages and disadvantages - it's difficult to make an assessment without trawling through long email threads, and yet I don't want to let the proposal pass without comment. So it would help a lot if someone could take the time to explain the design space and the tradeoffs. I know for example I have lots of code that defines a Monad instance and doesn't need an Applicative instance, so this change will force me to jump through hoops that I don't need to. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yet Another Haskell Tutorial missing (maybe lost on server move?)
The page http://www.haskell.org/haskellwiki/Yet_Another_Haskell_Tutorial says that there is a darcs repository at http://darcs.haskell.org/yaht/ but it is not. Also in the canonical replacement location http://code.haskell.org/yaht/ I cannot find it. The Wikiboook https://secure.wikimedia.org/wikibooks/en/wiki/Haskell/YAHT mentions the same URL and additionally a PDF at http://darcs.haskell.org/yaht/yaht.pdf which is missing, too. Can someone please tell me, where it is, update HaskellWiki and Wikibook and add a forward from darcs.haskell.org to the new location? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] UTF-8 in Haskell.
On 23 December 2010 05:29, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: If so, OK, then I think I could make a packInt which turns an Int into 4 Word8 first. Thus under all situation (ascii, UTF-8, or even UTF-32), my program always send 4 bytes through the network. Is that OK? I think you are describing the UTF-32 encoding (under the assumption that fromEnum on Char returns the Unicode code point of that character, which I think is true). UTF-32 is capable of describing every Unicode code point so this is indeed non-lossy. UTF-32 is a reasonable wire transfer format (if a bit inefficient!). Don't roll your own encoding logic though, System.IO provides a TextEncoding for UTF-32 you can use to do the job more reliably. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] non_lazy_ptr ld error?
Lately I've been seeing this error occasionally when recompiling: Undefined symbols: _UiziTrackC_d26DB, referenced from: _UiziTrackC_d26DB$non_lazy_ptr in TrackC.o ld: symbol(s) not found If I delete the .o file for the mentioned module and recompile, it links fine. This makes me think something in the dependency analysis is mixed up and not recompiling something that should be recompiled. But I'm using --make and letting ghc figure out the deps. Does this error look familiar to anyone? This is ghc 6.12.3 on OS X 10.5.8. On a probably unrelated note, a few times lately I've had a startup segfault on a program which was previously fine. The stack trace on the crashing thread is: Thread 2 Crashed: 0 libSystem.B.dylib 0x954f9fa0 strcmp + 80 1 elaforge.seq.seq0x0143f7dd lookupHashTable + 131 2 elaforge.seq.seq0x01444243 ghciInsertStrHashTable + 24 3 elaforge.seq.seq0x01445a87 ocGetNames_MachO + 1803 4 elaforge.seq.seq0x014447bf loadObj + 500 5 elaforge.seq.seq0x007064a4 sYy_info + 12 This is a little worrying because I've never seen this before and I don't know why it's started. It seems to happen consistently until I make clean and recompile. My app uses hint and I suspect this is part of the hint initialization and has to do with inconsistent .o files or something... anyone seen this either? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec2 vs. parsec3... again
On Thu, Dec 23, 2010 at 1:01 AM, Evan Laforge qdun...@gmail.com wrote: So, my current options are either figure out some way to speed up parsec3+Text, revert to parsec2+String and give up, or try an entirely different parsing library. I've heard attoparsec is fast but I'd have to switch to utf8 bytestring which is a big change, and Text seems like the more correct choice anyway. Any ideas or experience? Michael Snoyman wants attoparsec-text as well [1]. [1] http://docs.yesodweb.com/blog/wishlist/ -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof in Haskell
On Dec 21, 2010, at 6:57 PM, austin seipp wrote: https://gist.github.com/750279 I took Austins code and modified it to run on a Tree GADT which is parameterized by its shape: https://gist.github.com/752982 Would this count as a function mirror with proof that mirror (mirror x) == x? -- Sjoerd Visscher ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Help!! Cannot get RandT and liftIO to work together...
Hello all, sorry I must have taken my stupid pills this morning, I cannot get the following code to compile, what am I missing? data MyState=MyState Integer newState:: (RandomGen g) = RandT g IO MyState newState = do time-liftIO getCPUTime rand-getRandomR (1,6) return $ MyState (time+rand) newStateIO :: IO MyState newStateIO = do r-getStdGen evalRandT newState r - Could not deduce (MonadIO (RandT g IO)) from the context (RandomGen g) arising from a use of `liftIO' at ...:4:15-31 Possible fix: add (MonadIO (RandT g IO)) to the context of the type signature for `newState' or add an instance declaration for (MonadIO (RandT g IO)) Pirates.hs /Pirates/src line 167 Problem But the MonadRandom docs say: Instances: MonadIOhttp://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-IO-Class.html#t:MonadIO m = MonadIOhttp://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-IO-Class.html#t:MonadIO (RandThttp://hackage.haskell.org/packages/archive/MonadRandom/0.1.6/doc/html/Control-Monad-Random.html#t:RandT g m) And the MonadIO docs say: Instances: MonadIOhttp://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-IO-Class.html#t:MonadIO IOhttp://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/System-IO.html#t:IO So it looks to me it should work! I've also tried to replace IO by MonadIO m= in the signature, or remove all signatures. No joy. Thanks for any help. -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Functor = Applicative = Monad
On 22/12/2010 19:03, Simon Marlow wrote: On 14/12/2010 08:35, Isaac Dupree wrote: On 12/14/10 03:13, John Smith wrote: I would like to formally propose that Monad become a subclass of Applicative, with a call for consensus by 1 February. The change is described on the wiki at http://haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal, That page isn't written as a proposal yet, it's written as a bunch of ideas. I would be happy to see something along the lines of Bas van Dijk's work http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/14740 . This is a proposal with far-reaching consequences, and with several alternative designs. I'm not sure I understand all the tradeoffs. Some parts of the proposal are orthogonal to the rest (e.g. changing fmap to map), and should probably be considered separately. Could someone please write a detailed proposal, enumerating all the pros and cons, and the rationale for this design compared to other designs? Cheers, Simon I don't know exactly what the proposal process is, but what I'd like to see is something like the following: 1) Subclasses may declare default implementations of inherited methods. For example: class Functor f = Applicative f where ... fmap f x = pure f * x class Applicative f = Monad f where ... pure = return (*) = ap 2) Unless superclass instances are already in scope at declaration of an instance, an instance declaration implicitly also declares the superclass (and may also explicitly define functions in the superclass). For example: instance Monad Maybe where return = Just (=) = ... fmap = ... This declaration, in the absence of any explicit instance Functor Maybe and instance Applicative Maybe, would implicitly define those instances as well, with the default implementations of fmap, pure, and * given. It would be a compile-time error to inherit multiple default definitions of a method, unless: a) There is a clear shadowing (eg, if the Monad class declaration included a default fmap, that would take precedence over the one in Applicative) b) The instance declaration explicitly defines the function, thus resolving the conflict. These changes, I believe, would make it possible to restructure the heirarchy with negligible impact on user code. The only potential impact I see so far would have to involve orphan instances, which are already considered risky/not a good idea. Specifically, if there were already an orphan Monad instance in one place and an orphan Applicative instance in another, the orphaned Applicative instance would become a duplicate instance which could potentially bite an end-user importing both modules. It would also be possible with fairly small user impact to move 'return' to Applicative, or even to a new 'Pointed' superclass of Applicative. To the end user, the type 'return :: Monad m = a - m a' would still be valid, as would including return in a Monad instance declaration. Including 'pure' as well in Applicative (with defaults pure = return, return = pure) would allow old Applicative declarations to continue to work unchanged as well, though that obviously has the downside of introducing a new recursive default which is always potentially confusing to writers of new instances. -- James PS. Incidentally, I'd also prefer a class like the following instead of Applicative as it is now: class Functor f = Monoidal f where return :: a - f a (*) :: f a - f b - f (a,b) But that would be a much more disruptive change. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help!! Cannot get RandT and liftIO to work together...
On Thursday 23 December 2010 15:52:40, JP Moresmau wrote: Hello all, sorry I must have taken my stupid pills this morning, I cannot get the following code to compile, what am I missing? Works here. Which versions of the packages and GHC are you using? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help!! Cannot get RandT and liftIO to work together...
On Thursday 23 December 2010 15:52:40, JP Moresmau wrote: what am I missing? Maybe I just spotted it: But the MonadRandom docs say: Instances: MonadIOhttp://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control- Monad-IO-Class.html#t:MonadIO m links to the transformers package, but MonadRandom uses mtl. = MonadIOhttp://hackage.haskell.org/packages/archive/transformers/0.2.2.0 /doc/html/Control-Monad-IO-Class.html#t:MonadIO ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help!! Cannot get RandT and liftIO to work together...
GHC 6.12.1, base 4.2.0.0, MonadRandom-0.1.6, transformers-0..2.2.0, on Windows.Could it be that my system is not picking up the MonadIO I think it does? JP On Thu, Dec 23, 2010 at 4:13 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Thursday 23 December 2010 15:52:40, JP Moresmau wrote: Hello all, sorry I must have taken my stupid pills this morning, I cannot get the following code to compile, what am I missing? Works here. Which versions of the packages and GHC are you using? -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help!! Cannot get RandT and liftIO to work together...
On Thursday 23 December 2010 16:21:05, JP Moresmau wrote: GHC 6.12.1, base 4.2.0.0, MonadRandom-0.1.6, transformers-0..2.2.0, on Windows. Could it be that my system is not picking up the MonadIO I think it does? Probably. With 6.12.1, you'll probably have an mtl-1.* installed, so the MonadIO used by MonadRandom is not the same as the one provided by transformers. Reinstall mtl to get version 2.* and MonadRandom if that's the case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Help!! Cannot get RandT and liftIO to work together...
Thanks a million, it worked! Following all the dependencies sometimes is a bit of a headache. But in a sense, I'm happy to see I had understood how to use the monad transformer correctly, it wasn't me being (too) stupid. Thanks again! JP On Thu, Dec 23, 2010 at 4:32 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Thursday 23 December 2010 16:21:05, JP Moresmau wrote: GHC 6.12.1, base 4.2.0.0, MonadRandom-0.1.6, transformers-0..2.2.0, on Windows. Could it be that my system is not picking up the MonadIO I think it does? Probably. With 6.12.1, you'll probably have an mtl-1.* installed, so the MonadIO used by MonadRandom is not the same as the one provided by transformers. Reinstall mtl to get version 2.* and MonadRandom if that's the case. -- JP Moresmau http://jpmoresmau.blogspot.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof in Haskell
I think it's pretty legit. You aren't actually making a claim about the values in the tree but I think parametricity handles that for you, especially since you have existential types for the payload at every tree level (so you can't go shuffling those around). The only thing missing (and that you can't change in Haskell) is that your statement is about Mirror (Mirror x) == x, rather than mirror (mirror x) == x. mirror gives you Mirror but there's currently no proof to show that it's the only way to do it, so there's a missing step there, I think. Anyway, for those talking about the coinductive proof, I made one in Agda: http://hpaste.org/42516/mirrormirror Simulating bottoms wouldn't be too hard, but I don't think the statement is even true in the presence of bottoms, is it? Dan On Thu, Dec 23, 2010 at 9:27 AM, Sjoerd Visscher sjo...@w3future.comwrote: On Dec 21, 2010, at 6:57 PM, austin seipp wrote: https://gist.github.com/750279 I took Austins code and modified it to run on a Tree GADT which is parameterized by its shape: https://gist.github.com/752982 Would this count as a function mirror with proof that mirror (mirror x) == x? -- Sjoerd Visscher ___ 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] parsec2 vs. parsec3... again
On Thu, Dec 23, 2010 at 3:03 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: Michael Snoyman wants attoparsec-text as well [1]. [1] http://docs.yesodweb.com/blog/wishlist/ It's on my Christmas wishlist too. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] parsec2 vs. parsec3... again
On Thu, Dec 23, 2010 at 6:21 PM, Johan Tibell johan.tib...@gmail.com wrote: On Thu, Dec 23, 2010 at 3:03 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: Michael Snoyman wants attoparsec-text as well [1]. [1] http://docs.yesodweb.com/blog/wishlist/ It's on my Christmas wishlist too. Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Since I'm sure everyone is thinking it at this point, I'll just say it: we're all hoping Bryan O'Sullivan saves the day again and writes this package. He wrote both attoparsec *and* text, so if he writes attoparsec-text, it will just be double the awesomeness. So Bryan, please do tell: how many beers (or any other consumable) will it take to get you to write it? I'll start up the collection fund, and throw in a six pack ;). Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why is Haskell flagging this?
Haha, not exactly. You can replace sj - get let (a, sk) = runState something sj put sk with a - something Also, you don't need do notation for single statements; do return x is just return x On Wed, Dec 22, 2010 at 7:21 PM, michael rice nowg...@yahoo.com wrote: Thanks for the tip, Ozgur. It worked for me. Is this what you had in mind, Ryan? Michael == import Control.Monad.State.Lazy import Control.Monad import System.Random type GeneratorState = State StdGen data Craps a = Roll a | Win a | Lose a deriving (Show) genRandomR :: Random a = (a,a) - GeneratorState a genRandomR = state . randomR rollDie :: GeneratorState Int rollDie = genRandomR (1,6) roll2Dice :: GeneratorState Int roll2Dice = liftM2 (+) rollDie rollDie f :: Craps [Int] - GeneratorState (Craps [Int]) f (Roll []) = do g0 - get let (throw1,g1) = runState roll2Dice g0 put g1 case throw1 of 2 - return (Lose [throw1]) 3 - return (Lose [throw1]) 7 - return (Win [throw1]) 11 - return (Win [throw1]) _ - do g1 - get let (throw2,g2) = runState roll2Dice g1 put g2 if throw2 == throw1 then do return (Win [throw1,throw2]) else if throw2 == 7 then do return (Lose [throw1,throw2]) else do f (Roll [throw1,throw2]) f (Roll z@(throw1:throws)) = do g0 - get let (throw,g1) = runState roll2Dice g0 put g1 if throw == throw1 then do return (Win (z ++ [throw])) else if throw == 7 then do return (Lose (z ++ [throw])) else do f (Roll (z ++ [throw])) --- On *Wed, 12/22/10, Ozgur Akgun ozgurak...@gmail.com* wrote: From: Ozgur Akgun ozgurak...@gmail.com Subject: Re: [Haskell-cafe] Why is Haskell flagging this? To: Ryan Ingram ryani.s...@gmail.com Cc: haskell-cafe@haskell.org, Daniel Fischer daniel.is.fisc...@googlemail.com Date: Wednesday, December 22, 2010, 7:37 PM see also: http://hackage.haskell.org/packages/archive/mtl/latest/doc/html/Control-Monad-State-Lazy.html#v:state On 22 December 2010 20:02, Ryan Ingram ryani.s...@gmail.comhttp://mc/compose?to=ryani.s...@gmail.com wrote: Interesting. In that case, state f = StateT $ \s - Identity (f s) allows state to replace State in that code. Ozgur -Inline Attachment Follows- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mc/compose?to=haskell-c...@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
[Haskell-cafe] List of numbers to list of ranges
Hi all, Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] My attempt using foldl yields me the output in reverse. I can ofcourse reverse the result, but what would be a better way? f xs = foldl ff [] xs where [] `ff` i = [(i,i)] ((s,e):ns) `ff` i = if i == e+1 then (s,i):ns else (i,i):(s,e):ns Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof in Haskell
On Thu, Dec 23, 2010 at 8:19 AM, Daniel Peebles pumpkin...@gmail.com wrote: Simulating bottoms wouldn't be too hard, but I don't think the statement is even true in the presence of bottoms, is it? Isn't it? data Tree a = Tip | Node (Tree a) a (Tree a) mirror :: Tree a - Tree a mirror Tip = Tip mirror (Node x y z) = Node (mirror z) y (mirror x) -- -- base cases mirror (mirror _|_) = mirror _|_ = _|_ mirror (mirror Tip) = mirror Tip = Tip -- inductive case mirror (mirror (Node x y z)) = mirror (Node (mirror z) y (mirror x)) = Node (mirror (mirror x)) y (mirror (mirror z)) -- induction = Node x y z -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof in Haskell
On Tue, Dec 21, 2010 at 9:57 AM, austin seipp a...@hacks.yi.org wrote:
For amusement, I went ahead and actually implemented 'Mirror' as a
type family, and used a little bit of hackery thanks to GHC to prove
that indeed, 'mirror x (mirror x) = x' since with a type family we can
express 'mirror' as a type level function via type families. It uses
Ryan Ingram's approach to lightweight dependent type programming in
Haskell.
https://gist.github.com/750279
Thanks for the shout out :)
I think the type of your proof term is incorrect, though; it requires
the proof to be passed in, which is sort of a circular logic.
The type you want is
proof1 :: forall r x. BinTree x = ((x ~ Mirror (Mirror x)) = x - r) - r
proof1 t k = ...
Alternatively,
data TypeEq a b where Refl :: TypeEq a a
proof1 :: forall x. BinTree x = x - TypeEq (Mirror (Mirror x)) x
proof1 t = ...
Here's an implementation for the latter
newtype P x = P { unP :: TypeEq (Mirror (Mirror x)) x }
baseCase :: P Tip
baseCase = P Refl
inductiveStep :: forall a b c. P a - P c - P (Node a b c)
inductiveStep (P Refl) (P Refl) = P Refl
proof1 t = unP $ treeInduction t baseCase inductiveStep
(I haven't tested this, but I believe it should work)
-- ryan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On Thursday 23 December 2010 18:27:43, C K Kashyap wrote: Hi all, Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] My attempt using foldl yields me the output in reverse. I can ofcourse reverse the result, but what would be a better way? f xs = foldl ff [] xs where [] `ff` i = [(i,i)] ((s,e):ns) `ff` i = if i == e+1 then (s,i):ns else (i,i):(s,e):ns A right fold? It's easier, at least: Prelude let foo k [] = [(k,k)]; foo k xs@((l,h):t) = if l == k+1 then (k,h):t else (k,k):xs Prelude foldr foo [] [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof in Haskell
Fair enough :) that'll teach me to hypothesize something without thinking about it! I guess I could amend my coinductive proof: http://hpaste.org/paste/42516/mirrormirror_with_bottom#p42517 does that cover bottom-ness adequately? I can't say I've thought through it terribly carefully. On Thu, Dec 23, 2010 at 12:30 PM, Ryan Ingram ryani.s...@gmail.com wrote: On Thu, Dec 23, 2010 at 8:19 AM, Daniel Peebles pumpkin...@gmail.com wrote: Simulating bottoms wouldn't be too hard, but I don't think the statement is even true in the presence of bottoms, is it? Isn't it? data Tree a = Tip | Node (Tree a) a (Tree a) mirror :: Tree a - Tree a mirror Tip = Tip mirror (Node x y z) = Node (mirror z) y (mirror x) -- -- base cases mirror (mirror _|_) = mirror _|_ = _|_ mirror (mirror Tip) = mirror Tip = Tip -- inductive case mirror (mirror (Node x y z)) = mirror (Node (mirror z) y (mirror x)) = Node (mirror (mirror x)) y (mirror (mirror z)) -- induction = Node x y z -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On Thu, 23 Dec 2010, C K Kashyap wrote: Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] That's an interesting problem! My first attempt: List.unfoldr (\xs - case xs of [] - Nothing; y:ys - case span (uncurry (==)) $ zip xs [y..] of (matching, remainder) - Just ((y, fst $ last matching), map fst remainder)) [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] However, the use of 'last' will course a memory leak for long ranges, and the (map fst remainder) reconstructs the remainder of the list, and thus needs linear time instead of constant one. Here is my second attempt, developed in GHCi and variable names that should be improved ... List.unfoldr (\xs - case xs of [] - Nothing; y:ys - case dropWhile (\(a,b,t) - case t of [] - False; h:_ - a==h) $ zip3 [y+1..] xs (List.tails ys) of ~((_, end, remainder):_) - Just ((y, end), remainder)) [1,2,3,6,8,9,10] Using zip3 I have bundled all information that I need after 'dropWhile' in order to proceed: The end of the current range and the remaining numbers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On Thu, 23 Dec 2010, Daniel Fischer wrote: On Thursday 23 December 2010 18:27:43, C K Kashyap wrote: Hi all, Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] My attempt using foldl yields me the output in reverse. I can ofcourse reverse the result, but what would be a better way? f xs = foldl ff [] xs where [] `ff` i = [(i,i)] ((s,e):ns) `ff` i = if i == e+1 then (s,i):ns else (i,i):(s,e):ns A right fold? It's easier, at least: Prelude let foo k [] = [(k,k)]; foo k xs@((l,h):t) = if l == k+1 then (k,h):t else (k,k):xs Prelude foldr foo [] [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] I admit your solution is much more comprehensible than my one. However, my second complicated solution should be more efficient and especially works as good as possible on infinite lists: Prelude List.unfoldr (...) [1..] [(1, I try other ones (using Data.List.HT from utility-ht): Prelude map (\xs - (head xs, last xs)) $ Data.List.HT.groupBy (\a b - a+1==b) [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] Prelude map (\xs@(x:_) - (x, x + length xs - 1)) $ Data.List.HT.groupBy (\a b - a+1==b) [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] The second one should not have a memory leak, like the first one. If you prefer an explicit recursive solution, how about this one: Prelude let ranges xs = (case xs of [] - []; y:ys - aux0 y ys); aux0 y ys = let (end,remainder) = aux1 y ys in (y,end) : remainder; aux1 predec xs = case xs of [] - (predec, []); y:ys - if predec+1 == y then aux1 y ys else (predec, aux0 y ys) Prelude ranges [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On Thursday 23 December 2010 18:27:43, C K Kashyap wrote: Hi all, Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] My attempt using foldl yields me the output in reverse. I can ofcourse reverse the result, but what would be a better way? f xs = foldl ff [] xs where [] `ff` i = [(i,i)] ((s,e):ns) `ff` i = if i == e+1 then (s,i):ns else (i,i):(s,e):ns Regards, Kashyap I suggested: Prelude let foo k [] = [(k,k)]; foo k xs@((l,h):t) = if l == k+1 then (k,h):t else (k,k):xs Prelude foldr foo [] [1,2,3,6,8,9,10] [(1,3),(6,6),(8,10)] Lazier is better: bar k xs = (k,m):t where (m,t) = case xs of [] - (k,[]) (l,h):u | l == k+1 - (h,u) | otherwise - (k,xs) Prelude foldr foo [] [1 .. 100] [(1,100)] (15.46 secs, 226229904 bytes) Prelude foldr bar [] [1 .. 100] [(1,100)] (3.47 secs, 242992364 bytes) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof in Haskell
On Thursday 23 December 2010 12:52:07 pm Daniel Peebles wrote:
Fair enough :) that'll teach me to hypothesize something without thinking
about it! I guess I could amend my coinductive proof:
http://hpaste.org/paste/42516/mirrormirror_with_bottom#p42517
does that cover bottom-ness adequately? I can't say I've thought through it
terribly carefully.
That isn't the usual way to model partially defined values. For instance, you
can write functions with that datatype that would not be monotone:
pdefined :: {A : Set} - Tree A - Bool
pdefined ⊥ = false
pdefined _ = true
It's somewhat more accurate to take the partiality monad:
data D (A : Set) : Set where
now : A - D A
later : ∞ (D A) - D A
⊥ : {A : Set} - D A
⊥ = later (♯ ⊥)
Then we're interested in an equivalence relation on D As where two values are
equal if they either both diverge, or both converge to equal inhabitants of A
(not worrying about how many steps each takes to do so).
Then, the partially defined trees are given by:
mutual {A}
Tree = D Tree'
data Tree' : Set where
node : Tree - A - Tree - Tree'
tip : Tree'
And equivalence of these trees makes use of the above equivalence for D-
wrapped things. (It's actually a little weird that this works, I think, if you
expect Tree' to be a least fixed point; but Agda does not work that way).
If you're just interested in proving mirror (mirror x) = x, though, this is
probably overkill. Your original type should be isomorphic to the Haskell type
in a set theoretic way of thinking, and the definition of mirror does what the
Haskell function would do at all the values. So the fact that you can write
functions on that Agda type that would have no corresponding implementation in
Haskell is kind of irrelevant.
-- Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On Thu, Dec 23, 2010 at 10:57:43PM +0530, C K Kashyap wrote: Here's my attempt to convert a list of integers to a list of range tuples - Given [1,2,3,6,8,9,10], I need [(1,3),(6,6),8,10)] import Data.Function import Data.List ranges ns = [(head gp, last gp) | gp - map (map fst) $ groupBy ((==) `on` snd) $ zip ns (zipWith (-) ns [1..])] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
I'd go with direct recursion for this one - the pattern of consumption and production that generates the answer doesn't seem to neatly match any of the standard recursion combinators (map, unfold, fold, mapAccum, ...) nor exotic ones (skipping streams c.f. the Stream fusion paper, apomorphisms, ...). Direct recursion might be prosaic, but it is pleasantly obvious: ranges :: (Num a, Eq a) = [a] - [(a,a)] ranges [] = [] ranges (a:as) = step (a,a) as where step (i,j) []= [(i,j)] step (i,j) (x:xs) | j+1 == x = step (i,x) xs step (i,j) (x:xs)= (i,j) : step (x,x) xs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite lists in real world programs
fromList :: [a] - SignalGen (Signal a) fromList xs = stateful xs tail = memo . fmap head 1) It does what I want, but is it the good way to do it? Yes, I'd do it the same way, assuming that the input is always an infinite list (so this version should probably be called unsafeFromList...). But you can always make a list infinite, just add a Maybe layer or pad with a default value. 2) Since the returned signal may be used in several places and since I obtain it through the generic fmap (and not through an Elerea primitive), I guessed I had to memo it instead of simply using return. Did I guess right? That's exactly what memo is needed for, yes. However, whether it is worth the overhead in such a simple case (after all, head is essentially just a single dereferencing step) should be determined by profiling. 3) Concerning the functionnality added by the Param implementation, I have the impression that the same can be achieved through the use of an external signal in Simple (*). Am I right? Yes, the two are equally expressive. The difference is the way you access the signals. In the case of Param, you get a globally accessible signal that you don't need to pass around explicitly, just retrieve with 'input' wherever you want. This might be useful when there's some ubiquitous piece of information that you need practically everywhere, e.g. real time for a simulation. Gergely -- http://www.fastmail.fm - Does exactly what it says on the tin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (Co/Contra)Functor and Comonad
Why are Cofunctor and Comonad classes not a part of the base library? I recently defined a data type (Control.Cofunctor.Ticker in monad-coroutine on Hackage) that happens to be a co-functor, or contra-functor if you prefer. In other words, it can implement the following function: cofmap :: (a - b) - cf b - cf a I wanted to define a proper instance for it, but to my surprise I discovered that I couldn't. Not only is the class not defined in base, the only package I could find on Hackage that defines it is category-extras. This is a huge package I'd rather not have as a dependency, so I opted not to declare any instance. Later on I found that this question has been raised before by *Conal Elliott*, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html The result was the TypeCompose package, which presents a decent solution. I still can't think of any harm in having a proper class declaration in the base library: if you don't need it, you don't need to know it. But without the class declaration in the base library (or in some other obvious package) every other released library must either lack the instance declarations or declare the class itself and risk clashes. This is not some obscure class you've never encountered, by the way: any consumer of data is a cofunctor. All regexp data types, for example, are cofunctor instances - or would be if there was a class to declare them instances of. The same question extends to Comonad. I am not too familiar with this area so there may be fewer potential instances of the class, but I remember there was quite a bit of buzz around comonads a few years ago. Judging by a cursory Hayoo search, if anything the situation is worse than with Cofunctor: there are multiple incompatible declarations of the class scattered in various libraries that need it: ad, category-extras, data-category, rope. There is also evidence of undeclared Comonad instances: see the ListZipper and value-supply libraries. So, is it time to add these two classes to the base library? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On 23 December 2010 21:12, Stephen Tetley stephen.tet...@gmail.com wrote: I'd go with direct recursion for this one - the pattern of consumption and production that generates the answer doesn't seem to neatly match any of the standard recursion combinators (map, unfold, fold, mapAccum, ...) nor exotic ones (skipping streams c.f. the Stream fusion paper, apomorphisms, ...). Here's a synthesized functional that matches the needed behaviour. It takes from: a) apomorphism - has a final flush operation b) skipping streams (the Stream fusion paper) - a skipping Next case, though in this case there is no Done c) unfoldMap - itself a synthetic combination of unfold and map, which is unfolding against a list as well as state (the unfold equivalent of mapAccumL). Unimaginatively I've called it lessproductive as it can produce less than it consumes, though as it has no Done it must consume everything... data Step st a = Yield a !st | Next !st lessproductive :: (st - a - Step st b) - (st - b) - st - [a] - [b] lessproductive phi flush = step where step st [] = [flush st] step st (x:xs) = case phi st x of Next st' - step st' xs Yield b st' - b : step st' xs ranges :: (Num a, Eq a) = [a] - [(a,a)] ranges [] = [] ranges (x:xs) = lessproductive phi id (x,x) xs where phi (i,j) n | j+1 == n = Next (i,n) phi ans n= Yield ans (n,n) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On Thu, 23 Dec 2010, Stephen Tetley wrote: On 23 December 2010 21:12, Stephen Tetley stephen.tet...@gmail.com wrote: I'd go with direct recursion for this one - the pattern of consumption and production that generates the answer doesn't seem to neatly match any of the standard recursion combinators (map, unfold, fold, mapAccum, ...) nor exotic ones (skipping streams c.f. the Stream fusion paper, apomorphisms, ...). Here's a synthesized functional that matches the needed behaviour. It takes from: a) apomorphism - has a final flush operation b) skipping streams (the Stream fusion paper) - a skipping Next case, though in this case there is no Done c) unfoldMap - itself a synthetic combination of unfold and map, which is unfolding against a list as well as state (the unfold equivalent of mapAccumL). Unimaginatively I've called it lessproductive as it can produce less than it consumes, though as it has no Done it must consume everything... data Step st a = Yield a !st | Next !st This could be seen as type Step st a = (Maybe a, st). I have thought about mapping from [Int] to [Maybe (Int, Int)] by mapAccumL, then compressing the result with catMaybes. However we need to append a final pair when the end of the list is reached, which risks a memory leak. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
On 23 December 2010 22:01, Henning Thielemann lemm...@henning-thielemann.de wrote: This could be seen as type Step st a = (Maybe a, st). I have thought about mapping from [Int] to [Maybe (Int, Int)] by mapAccumL, then compressing the result with catMaybes. However we need to append a final pair when the end of the list is reached, which risks a memory leak. Hi Henning Thanks - that's an extra nesting of constructors though. Note the flush in the original was always doomed to be productive - this revision might be better, the flush now has the option of producing nothing or many: lessproductive :: (st - a - Step st b) - (st - [b]) - st - [a] - [b] lessproductive phi flush = step where step st [] = flush st step st (x:xs) = case phi st x of Next st' - step st' xs Yield b st' - b : step st' xs ranges2 :: (Num a, Eq a) = [a] - [(a,a)] ranges2 [] = [] ranges2 (x:xs) = lessproductive phi (\a - [a]) (x,x) xs where phi (i,j) n | j+1 == n = Next (i,n) phi ans n= Yield ans (n,n) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
On 23 December 2010 21:43, Mario Blažević mblaze...@stilo.com wrote: Why are Cofunctor and Comonad classes not a part of the base library? [SNIP] Later on I found that this question has been raised before by Conal Elliott, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html From a somewhat philistine persepective, that Conal's question went unanswered says something: Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Infinite lists in real world programs
Thanks for your answers. In fact I tried to use Simple with a clock signal and it's painful to pass it wherever you need it. Param is much more practical. I like Elerea, I tried Reactive and Yampa, and I found them (especially Yampa) heavy and not very practical. The fact that Elerea is minimalistic makes it easier to learn/use and more flexible. 2010/12/23 Patai Gergely patai_gerg...@fastmail.fm fromList :: [a] - SignalGen (Signal a) fromList xs = stateful xs tail = memo . fmap head 1) It does what I want, but is it the good way to do it? Yes, I'd do it the same way, assuming that the input is always an infinite list (so this version should probably be called unsafeFromList...). But you can always make a list infinite, just add a Maybe layer or pad with a default value. 2) Since the returned signal may be used in several places and since I obtain it through the generic fmap (and not through an Elerea primitive), I guessed I had to memo it instead of simply using return. Did I guess right? That's exactly what memo is needed for, yes. However, whether it is worth the overhead in such a simple case (after all, head is essentially just a single dereferencing step) should be determined by profiling. 3) Concerning the functionnality added by the Param implementation, I have the impression that the same can be achieved through the use of an external signal in Simple (*). Am I right? Yes, the two are equally expressive. The difference is the way you access the signals. In the case of Param, you get a globally accessible signal that you don't need to pass around explicitly, just retrieve with 'input' wherever you want. This might be useful when there's some ubiquitous piece of information that you need practically everywhere, e.g. real time for a simulation. Gergely -- http://www.fastmail.fm - Does exactly what it says on the tin ___ 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
[Haskell-cafe] The Bay Area Haskell Hackathon is coming up: Feb 11-13, 2011
Mark Lentczner and I are organizing, and it will be held at Hacker Dojo in Mountain Viewhttp://maps.google.com/maps/place?cid=2122486601784397611q=hacker+dojogl=us . If you plan to attend, please fill in our sign-up formhttps://spreadsheets.google.com/viewform?formkey=dEc5cW1fa3hjQ3JheVF5dHAwdTk0eGc6MQso we know we'll have room. Also, please consider joining the Hackathon's Google grouphttp://groups.google.com/group/bayhac . We look forward to seeing you! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
This one looks somewhat symmetrical: f xs = let xys = filter ( \ (x,y) - y - x 1 ) $ zip xs ( tail xs ) in zip ( [ head xs ] ++ map snd xys ) ( map fst xys ++ [ last xs ] ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List of numbers to list of ranges
All the previous solutions seem to assume that the list of numbers is already sorted. In cases where this assumption cannot be made, an alternative solution is to simply insert the numbers into a diet. eecs.oregonstate.edu/~erwig/papers/abstracts.html#JFP98 eecs.oregonstate.edu/~erwig/diet -- Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley stephen.tet...@gmail.comwrote: On 23 December 2010 21:43, Mario Blažević mblaze...@stilo.com wrote: Why are Cofunctor and Comonad classes not a part of the base library? [SNIP] Later on I found that this question has been raised before by Conal Elliott, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html From a somewhat philistine persepective, that Conal's question went unanswered says something: Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling. There are plenty of potential Cofunctor instances on Hackage, as I've pointed out. The other side of the proof of the utility of the class would be to find existing libraries that could be parameterized by an arbitrary functor: in other words, some examples in Hackage of class Cofunctor c = ... instance Cofunctor c = ... f :: Cofunctor c = ... This would be rather difficult to prove - such signatures cannot be declared today, and deciding if existing declarations could be generalized in this way would require a pretty deep analysis. The only thing I can say is build it and they will come. To turn the proof obligation around, what could possibly be the downside of adding a puny Cofunctor class to the base library? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: xmobar 0.12 released
I'm happy to announce a new relase of xmobar, the text-based monitor bar. You can read everything about xmobar and this release at our new web address (http://projects.haskell.org/xmobar/), or see below for a summary of what's new (cf. http://projects.haskell.org/xmobar/releases.html). ## Version 0.12 xmobar has a new [maintainer], a new [website], a new [mailing list] and uses a new [source code repository]. Many thanks to Andrea Rossato, xombar's author and maintainer so far, for creating xmobar in the first place, and for giving me the chance to become its maintainer. And a big thanks to Ben Boeckel, Petr Rockai and Norbert Zeh for their patches. [website]: http://projects.haskell.org/xmobar/ [mailing list]: http://projects.haskell.org/cgi-bin/mailman/listinfo/xmobar [source code repository]: https://github.com/jaor/xmobar [maintainer]: http://hacks-galore.org/jao/ _New features_ - Window borders: configuration options `border` and `borderColor` allow drawing borders around xmobar's window. - New monitor, `Uptime`, showing the system uptime. - New monitor argument (`-S`) to enable displaying the `%` symbol in percentages or other suffixes (e.g., units in Uptime and Network); the symbol is now never included by default. - New 'run once' commands, by specifying a 0 refresh rate in `Run Com` ([issue 26]). - MPD monitor: updated to libmpd 1.5. New fields `ppos` (playlist position) and `remaining` (remaining time). New configuration options to specify MPD's host, user name and password. - Battery monitor: new `watts` and `timeleft` fields (Petr Rockai), and specific arguments to control coloring and thresholds of the former. - MultiCPU monitor: new `auto*` fields that automatically detect all present CPUs (Ben Boeckel). - CpuFreq monitor uses just one decimal digit for GHz values (Petr Rockai). - Mail plugin expands paths starting with ~/ (Ben Boeckel). Ditto MBox. - Weather monitor now skips not retrieved fields, instead of displaying a long error message. - New compilation flag, `all_extensions`. - Documentation and website updates. _Bug fixes_ - [issue 23]: Wireless monitor is now compatible with iwlib 29. - [issue 24]: Swap monitor's used ratio display fixed. - [issue 25]: Percentages only include `%` if requested using `-P`. - [issue 31]: MPD monitor now respects `-W` argument. - Fixes in CPU frequency formatting, string alignment and colour boxes in monitors (Norbert Zeh). - TopMem and TopProc now use the `-L` and `-H` options correctly for memory template fields. - MBox skips non-existent mbox paths instead of hanging. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
For me, mostly naming. Cofunctor isn't the right name for it, and comap, while short, feels wrong. Contrafunctor feels better but is also cumbersome. No problems with Comonad, though. On Thu, Dec 23, 2010 at 9:16 PM, Mario Blažević mblaze...@stilo.com wrote: On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley stephen.tet...@gmail.comwrote: On 23 December 2010 21:43, Mario Blažević mblaze...@stilo.com wrote: Why are Cofunctor and Comonad classes not a part of the base library? [SNIP] Later on I found that this question has been raised before by Conal Elliott, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html From a somewhat philistine persepective, that Conal's question went unanswered says something: Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling. There are plenty of potential Cofunctor instances on Hackage, as I've pointed out. The other side of the proof of the utility of the class would be to find existing libraries that could be parameterized by an arbitrary functor: in other words, some examples in Hackage of class Cofunctor c = ... instance Cofunctor c = ... f :: Cofunctor c = ... This would be rather difficult to prove - such signatures cannot be declared today, and deciding if existing declarations could be generalized in this way would require a pretty deep analysis. The only thing I can say is build it and they will come. To turn the proof obligation around, what could possibly be the downside of adding a puny Cofunctor class to the base library? ___ 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] (Co/Contra)Functor and Comonad
On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley stephen.tet...@gmail.com wrote: On 23 December 2010 21:43, Mario Blažević mblaze...@stilo.com wrote: Why are Cofunctor and Comonad classes not a part of the base library? [SNIP] Later on I found that this question has been raised before by Conal Elliott, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html From a somewhat philistine persepective, that Conal's question went unanswered says something: Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling. As it happens, there actually is a significant programming style to go with cofunctors. There's also a reason why it may not seem compelling to Haskell programmers, which I will illustrate with an analogy to other programming languages: Consider the problem of variance in a language with a subtyping relation and optionally mutable references. A subtype relationship A : B can be viewed as an implicit conversion operator from A to B. Therefore, if you have a read-only reference to something of type A, you can create a read-only reference to something of type B. This can be seen as analogous to mapping the implicit conversion function over the identity functor applied to type A. On the other hand, what if you have a mutable reference to something of type A? You can't assign something of type B to it, because anything reading from the reference will receive a B, and there's no implicit conversion from B to A. However, if you instead have a mutable reference to something of type B, you can indeed assign something of type A to it using the implicit conversion. This is likewise analogous to mapping the conversion over an identity cofunctor. In other words, contravariant functors naturally describe concepts like destructive assignment, pushing values into a data sink of some sort, etc. The simplest example of a potential contravariant functor in Haskell would be (- r), i.e., a flipped version of the basic Reader functor (e -). Similarly, assigning to an IORef, partially applied to the reference itself, gives the type (a - IO ()), which is a special case of the flipped Reader. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...regardless of the utility of a contravariant functor type-class, I strongly advocate for calling it Contrafunctor and not Cofunctor. I have seen numerous examples of confusion over this, particularly in other languages. On 24/12/10 12:16, Mario Blažević wrote: On Thu, Dec 23, 2010 at 5:25 PM, Stephen Tetley stephen.tet...@gmail.com mailto:stephen.tet...@gmail.com wrote: On 23 December 2010 21:43, Mario Blažević mblaze...@stilo.com mailto:mblaze...@stilo.com wrote: Why are Cofunctor and Comonad classes not a part of the base library? [SNIP] Later on I found that this question has been raised before by Conal Elliott, nearly four years ago. http://www.haskell.org/pipermail/libraries/2007-January/006740.html - From a somewhat philistine persepective, that Conal's question went unanswered says something: Does anyone have useful functionality to go into a Cofunctor module (beyond the class declaration)? Successful post-H98 additions to Base (Applicative, Arrows, ...) brought a compelling programming style with them. For Comonads, Category-extras does define some extra combinators but otherwise they have perhaps seemed uncompelling. There are plenty of potential Cofunctor instances on Hackage, as I've pointed out. The other side of the proof of the utility of the class would be to find existing libraries that could be parameterized by an arbitrary functor: in other words, some examples in Hackage of class Cofunctor c = ... instance Cofunctor c = ... f :: Cofunctor c = ... This would be rather difficult to prove - such signatures cannot be declared today, and deciding if existing declarations could be generalized in this way would require a pretty deep analysis. The only thing I can say is build it and they will come. To turn the proof obligation around, what could possibly be the downside of adding a puny Cofunctor class to the base library? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - -- Tony Morris http://tmorris.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0UIJ0ACgkQmnpgrYe6r62kWgCeNwZnYLetOFevK6bpCBE/joKO 2QQAniaX4IGzAmdjEC8kdDV27upUTsBw =NP27 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
On Thu, Dec 23, 2010 at 11:25 PM, Tony Morris tonymor...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ...regardless of the utility of a contravariant functor type-class, I strongly advocate for calling it Contrafunctor and not Cofunctor. I have seen numerous examples of confusion over this, particularly in other languages. I don't personally care what's it called, as long as it's available. Can anybody point to an authoritative source for the terminology, though? Wikipedia claims that cofunctor is a contravariant functor. Also, is there anything in category theory equivalent to the Functor - Applicative - Monad hierarchy , but with a Cofunctor/Contrafunctor at the base? I'm just curious, I'm not advocating adding the entire hierarchy to the base library. ;) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
On 12/23/10 16:43, Mario Blažević wrote: Cofunctor and Comonad IMHO, as you say, there is only one design of cofunctor. class Cofunctor cf where cofmap :: (a - b) - cf b - cf a The only question is capitalization and spelling.* Since there are multiple designs of Comonad floating around, it'll take slightly more design work to make sure a standard design works for everyone. -Isaac *(CoFunctor or Cofunctor, cofmap or comap etc. IMHO your choices are fine. And to choose a module to put it in.). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (Co/Contra)Functor and Comonad
On Thu, Dec 23, 2010 at 11:46 PM, Mario Blažević mblaze...@stilo.com wrote: I don't personally care what's it called, as long as it's available. Can anybody point to an authoritative source for the terminology, though? Wikipedia claims that cofunctor is a contravariant functor. Does nLab count as sufficiently authoritative? As far as I can tell it just uses contravariant functor if anything, and never uses cofunctor. c.f. http://ncatlab.org/nlab/show/contravariant+functor Also, is there anything in category theory equivalent to the Functor - Applicative - Monad hierarchy , but with a Cofunctor/Contrafunctor at the base? I'm just curious, I'm not advocating adding the entire hierarchy to the base library. ;) As far as I understand (which may not actually be all that far), contravariant functors just go to or from an opposite category, a distinction that is purely a matter of definition, not anything intrinsic. On the other hand, Applicative and Monad are based on endofunctors specifically, i.e. functors from a category to itself, which would seem to necessarily exclude functors from a category to its opposite. There may exist constructs specifically based on such contravariant endofunctors but I doubt they'd be *equivalent* to things like Applicative/Monad in any particular way. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: storable-endian
...I mean, storable-endian 0.2.1 actually - 0.2.0 had a stupid bug.
2010/12/24 Eugene Kirpichov ekirpic...@gmail.com:
Hello Hennig,
Thanks for the suggestions!
I've released storable-endian 0.2.0, which does not use TH and bases
on your suggestion (though it has a bit of boilerplate because of
abandoning TH, but I don't think that's critical).
Here's the new source:
https://github.com/jkff/storable-endian/blob/master/Data/Storable/Endian.hs
2010/12/23 Henning Thielemann lemm...@henning-thielemann.de:
On Thu, 23 Dec 2010, Henning Thielemann wrote:
On Wed, 22 Dec 2010, Eugene Kirpichov wrote:
It defines types like {{Int,Word}{16,32,64},Double,Float}{LE,BE} (for
example Int32BE) etc. with a corresponding Storable instance.
How about type constructors LittleEndian and BigEndian?
newtype LittleEndian a = LittleEndian a
Maybe using some type classes you can even get rid of Template Haskell and
get plain Haskell 98?
Yes, I think you could have (given a module Data.Storable.LittleEndian as
LE)
instance LE.Storable a = Storable (LittleEndian a) where
sizeOf (LittleEndian a) = sizeOf a
alignment (LittleEndian a) = alignment a
peek p = fmap LittleEndian $ LE.peek p
poke p (LittleEndian a) = LE.poke p a
class LE.Storable a where
LE.peek :: Ptr a - IO a
LE.poke :: Ptr a - a - IO ()
instance LE.Storable Word16 where
LE.peek p = getWord16le (castPtr p)
LE.poke p = putWord16le (castPtr p)
...
I find this much cleaner and simpler to extend to other types.
--
Eugene Kirpichov
Senior Software Engineer,
Grid Dynamics http://www.griddynamics.com/
--
Eugene Kirpichov
Senior Software Engineer,
Grid Dynamics http://www.griddynamics.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: storable-endian
Hello Hennig,
Thanks for the suggestions!
I've released storable-endian 0.2.0, which does not use TH and bases
on your suggestion (though it has a bit of boilerplate because of
abandoning TH, but I don't think that's critical).
Here's the new source:
https://github.com/jkff/storable-endian/blob/master/Data/Storable/Endian.hs
2010/12/23 Henning Thielemann lemm...@henning-thielemann.de:
On Thu, 23 Dec 2010, Henning Thielemann wrote:
On Wed, 22 Dec 2010, Eugene Kirpichov wrote:
It defines types like {{Int,Word}{16,32,64},Double,Float}{LE,BE} (for
example Int32BE) etc. with a corresponding Storable instance.
How about type constructors LittleEndian and BigEndian?
newtype LittleEndian a = LittleEndian a
Maybe using some type classes you can even get rid of Template Haskell and
get plain Haskell 98?
Yes, I think you could have (given a module Data.Storable.LittleEndian as
LE)
instance LE.Storable a = Storable (LittleEndian a) where
sizeOf (LittleEndian a) = sizeOf a
alignment (LittleEndian a) = alignment a
peek p = fmap LittleEndian $ LE.peek p
poke p (LittleEndian a) = LE.poke p a
class LE.Storable a where
LE.peek :: Ptr a - IO a
LE.poke :: Ptr a - a - IO ()
instance LE.Storable Word16 where
LE.peek p = getWord16le (castPtr p)
LE.poke p = putWord16le (castPtr p)
...
I find this much cleaner and simpler to extend to other types.
--
Eugene Kirpichov
Senior Software Engineer,
Grid Dynamics http://www.griddynamics.com/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
