Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, 11 Oct 2010 05:50:32 +0200, Michael Snoyman mich...@snoyman.com wrote: Sorry to everyone for not getting back so quickly, I kept getting errors from postfix when I tried sending mail to the cafe. Hopefully this one will go through. As I see it, two open issues are flagging and real Haskellers. Flagging: this was simply a mistake in terminology on my part. I've replaced it with Report this user. It should be used for either inappropriate content, spam, or someone who's just clearly not part of the community (eg, Lol, I don't know Haskell, I had Cocoa Puffs for breakfast). I'm purposely being vague about this; if a user *thinks* there's a problem, it shouldn't take an admin more than a few seconds to investigate it. Now the more important question about real Haskellers: I think I mentioned before implementing the feature that I was a little bit nervous about doing so. The main reason I went ahead and did it anyway was we were getting some... strange gravatars showing up on the homepage. This problem was solved automatically when I added sorting by years of experience (no one can object to Simon PJ and Lennart being on the homepage of course), but the problem with that system is *anyone* can just set their start year to 1990 and get homepage status until an admin blocks him/her. So for the moment, real Haskeller is a minimal whitelisting system, simply intended to prevent people from gaming the system. I've probably chosen bad terminology, and by not explaining this upset a lot of people, my apologies. The point here is not to make the real Haskeller status exclusive, but just to give an extra level of protection. If people really think this is a bad idea, we can take it out. However, keep in mind that the community already seems to favor whitelists (the wiki requires admin intervention for an account, same on HackageDB). I think that Verified accounts sounds more appropriate than Real Haskellers, then. Regards, -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re-order type (flip map)
On 11 October 2010 00:00, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: My point was: you need to find/define two operators, not just one. Sure, I need flip ($) and flip (.) Since the Prelude forgot to define these (and flip map), the question was: are there established names for these two operators? (#) was quite established for flip ($) around 2000 - its in a couple of papers that appeared at the PADL conferences - one written by Erik Meijer, Daan Leijen and (I think) James Hook on scripting Microsoft Agents with COM. The authors noted reverse application with (#) gave code a nice OO-like reading. The other was Peter Thiemann's Wash - (#) is again flip ($) and (##) is flipped compose. Typographically I think these are a good fit, unfortunately they now might play badly with GHC's magic hash operator. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, Oct 11, 2010 at 9:06 AM, Nicolas Pouillard nicolas.pouill...@gmail.com wrote: On Mon, 11 Oct 2010 05:50:32 +0200, Michael Snoyman mich...@snoyman.com wrote: Sorry to everyone for not getting back so quickly, I kept getting errors from postfix when I tried sending mail to the cafe. Hopefully this one will go through. As I see it, two open issues are flagging and real Haskellers. Flagging: this was simply a mistake in terminology on my part. I've replaced it with Report this user. It should be used for either inappropriate content, spam, or someone who's just clearly not part of the community (eg, Lol, I don't know Haskell, I had Cocoa Puffs for breakfast). I'm purposely being vague about this; if a user *thinks* there's a problem, it shouldn't take an admin more than a few seconds to investigate it. Now the more important question about real Haskellers: I think I mentioned before implementing the feature that I was a little bit nervous about doing so. The main reason I went ahead and did it anyway was we were getting some... strange gravatars showing up on the homepage. This problem was solved automatically when I added sorting by years of experience (no one can object to Simon PJ and Lennart being on the homepage of course), but the problem with that system is *anyone* can just set their start year to 1990 and get homepage status until an admin blocks him/her. So for the moment, real Haskeller is a minimal whitelisting system, simply intended to prevent people from gaming the system. I've probably chosen bad terminology, and by not explaining this upset a lot of people, my apologies. The point here is not to make the real Haskeller status exclusive, but just to give an extra level of protection. If people really think this is a bad idea, we can take it out. However, keep in mind that the community already seems to favor whitelists (the wiki requires admin intervention for an account, same on HackageDB). I think that Verified accounts sounds more appropriate than Real Haskellers, then. Cool, consider it done ;). Actually, it really is done, I just have to push the code to the server. Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Polyvariadic functions operating with a monoid
Hi Oleg,
I've found that if I also add two other slightly scary sounding
extensions: OverlappingInstances and IncoherentInstances, then I can
eliminate the unwrap function *and* use your type families trick to
avoid the outer type annotation.
My latest code is here:
{-# LANGUAGE TypeSynonymInstances, FlexibleInstances,
MultiParamTypeClasses, TypeFamilies #-}
{-# LANGUAGE OverlappingInstances, IncoherentInstances #-}
module PolyTest where
import Data.Monoid
class Monoid m = Monoidable a m where
toMonoid :: a - m
squish :: Monoidable a m = m - a - m
squish m a = (m `mappend` (toMonoid a))
class Monoid m = PolyVariadic m r where
polyToMonoid :: m - r
instance (Monoid m', m' ~ m) = PolyVariadic m m' where
polyToMonoid acc = acc
instance (Monoidable a m, PolyVariadic m r) = PolyVariadic m (a-r)
where
polyToMonoid acc = \a - polyToMonoid (squish acc a)
Here are three examples. The resulting notation is short enough now
that I am no longer tempted to use CPP.
All you need to do is to specify the type for mempty. And even this
can be skipped if you want to put in the specific mempty value
(although I think that the type annotation is often better if slightly
longer as it documents clearly what monoid the result is being mapped
into).
-- [String] example
instance Show a = Monoidable a [String] where
toMonoid a = [show a]
testStringList = putStrLn $ show $ polyToMonoid (mempty :: [String])
True () (Just (5::Int))
-- String example
instance Show a = Monoidable a String where
toMonoid a = show a
testString = putStrLn $ polyToMonoid (mempty :: String) True () (Just
(5::Int))
-- product example
instance Monoid Double where
mappend = (*)
mempty = (1.0) :: Double
instance Monoidable Int Double where
toMonoid = fromIntegral
instance Monoidable Double Double where
toMonoid = id
testProduct = putStrLn $ show $ polyToMonoid (mempty :: Double) (5 ::
Int) (2.3 :: Double) (3 :: Int) (8 :: Int)
main = do
testStringList
testString
testProduct
$ runhaskell PolyTest.hs
[True,(),Just 5]
True()Just 5
276.0
Kevin
On Oct 11, 2:39 am, o...@okmij.org wrote:
Sorry, I'm still catching up. I'm replying to first few messages.
instance Show a = Monoidable a [String] where
toMonoid a = [show a]
main = putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int))
fails to compile.
The error message points to the first problem:
No instances for (Monoidable Bool [a],
Monoidable () [a],
...
The presence of the type variable 'a' means that the type checker
doesn't know list of what elements you want (in other words, the
context is not specific enough to instantiate the type variable
a). Thus, we need to explicitly tell that we wish a list of strings:
test3 = putStrLn $ unwrap $polyToMonoid ([]::[String]) True () (Just
(5::Int))
Now we get a different error, which points to the real problem this
time: the expression `unwrap ' appears as an argument to
putStrLn. That means that we are required to produce a String as a
monoid. Yet we specified ([]::[String]) as mempty, which is unsuitable
as mempty for the String monoid. If we desire the [String] monoid as
the result, we need to change the context. For example,
test3 = mapM_ putStrLn $ unwrap $
polyToMonoid ([]::[String]) True () (Just (5::Int))
Another example that also fails to compile (but I cannot see why):
main = putStrLn $ show $ unwrap $ polyToMonoid (0::Int) (1::Int)
(2::Int) (3::Int)
No instance for (PolyVariadic Int (WMonoid m))
arising from a use of `polyToMonoid'
The error message is informative, mentioning the type variable,
m. Whenever that happens, we know that we put a bounded polymorphic
expression in the context that is not specific enough. We need some
type annotations. In our case, the function 'show' can show values of
many types. The type checker does not know that we wish an Int monoid
specifically. So, we have to specialize the show function:
test4 = putStrLn $ (show :: Int - String) $
unwrap $ polyToMonoid (0::Int) (1::Int) (2::Int) (3::Int)
At this point one may wonder if this is all worth it. There are too
many annotations. Fortunately, if you are not afraid of one more
extension, the annotations can be avoided. Your example would be
accepted as it was written, see test3 and test4 below.
{-# LANGUAGE TypeSynonymInstances #-}
{-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, TypeFamilies #-}
module M where
import Data.Monoid
newtype WMonoid m = WMonoid{unwrap :: m}
class Monoid m = Monoidable a m where
toMonoid :: a - m
class Monoid m = PolyVariadic m p where
polyToMonoid :: m - p
instance (Monoid m', m' ~ m) = PolyVariadic m (WMonoid m') where
polyToMonoid acc = WMonoid acc
instance (Monoidable a m, PolyVariadic m r) = PolyVariadic m (a-r) where
polyToMonoid acc = \a - polyToMonoid (acc
RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
Vincent Hanquez wrote: On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote: What's the motivation for this? Well, I wanted to have a tls/ssl module that integrate nicely with haskell. until then the 2 solutions were: - shelling out to curl: that's not great, usually works until you have an error, and then you're greeted with a curl command line error. the control is pretty poor, what if you want a fancy certificate control ? Also you have absolutely no server support in this case, this is client only. - using either gnutls or openssl bindings: there's multiples reasons this is not great. depending on huge C libraries (security wise, platform wise), massive usage of IO even in place where it shouldn't, low hacking potential (adding ciphers/hash, etc). Apart from that, we all know here why programming in haskell is better than doing the same thing in says, C or python. I think it apply even more when the focus of this is a secure library. While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Anyway, it's just a feeling. Please do prove me wrong :-) Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Anyway, it's just a feeling. Please do prove me wrong :-) This certainly isn't a proof by a long shot, but my feeling on at least low-level libraries is exactly the reverse of this. C libraries are usually designed to be extremely stateful (this certainly includes openssl), and because of that any Haskell wrapper for them ends up being heavily IO based. The result of this is that any code that incorporates it ends up being trapped in an IO mess to do essentially pure (yes, I know the arguments about IO being pure, you know what I mean) things. It's precisely these libraries that we need not just implemented in a native way, but designed in a pure, beautiful, simple way for Haskell. While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. Tom Davie___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. I agree in general, for code like servers and file formats, but I worry in particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Polyvariadic functions operating with a monoid
It also appears that we need type families to reconstruct the original
Haskell list system using polyToMonoid.
instance (a ~ a') = Monoidable a [a'] where
toMonoid a = [a]
testList = putStrLn $ show $ polyToMonoid (mempty :: [a]) a b c
Given this instance of Monoidable, you can put any number of values
after
polyToMonoid (mempty :: [a]) as long as they are exactly the same
type.
In other words, this acts exactly like the usual Haskell list, going
back to my original point that polyToMonoid is a sort of generalised
list or a function that takes a bunch of values that can be stuck
together in some way.
I am a bit surprised that the (a ~ a') is needed, but Haskell will
not compile this code with the more usual
instance Monoidable a [a] where
toMonoid a = [a]
Kevin
On Oct 11, 9:54 am, Kevin Jardine kevinjard...@gmail.com wrote:
Hi Oleg,
I've found that if I also add two other slightly scary sounding
extensions: OverlappingInstances and IncoherentInstances, then I can
eliminate the unwrap function *and* use your type families trick to
avoid the outer type annotation.
My latest code is here:
{-# LANGUAGE TypeSynonymInstances, FlexibleInstances,
MultiParamTypeClasses, TypeFamilies #-}
{-# LANGUAGE OverlappingInstances, IncoherentInstances #-}
module PolyTest where
import Data.Monoid
class Monoid m = Monoidable a m where
toMonoid :: a - m
squish :: Monoidable a m = m - a - m
squish m a = (m `mappend` (toMonoid a))
class Monoid m = PolyVariadic m r where
polyToMonoid :: m - r
instance (Monoid m', m' ~ m) = PolyVariadic m m' where
polyToMonoid acc = acc
instance (Monoidable a m, PolyVariadic m r) = PolyVariadic m (a-r)
where
polyToMonoid acc = \a - polyToMonoid (squish acc a)
Here are three examples. The resulting notation is short enough now
that I am no longer tempted to use CPP.
All you need to do is to specify the type for mempty. And even this
can be skipped if you want to put in the specific mempty value
(although I think that the type annotation is often better if slightly
longer as it documents clearly what monoid the result is being mapped
into).
-- [String] example
instance Show a = Monoidable a [String] where
toMonoid a = [show a]
testStringList = putStrLn $ show $ polyToMonoid (mempty :: [String])
True () (Just (5::Int))
-- String example
instance Show a = Monoidable a String where
toMonoid a = show a
testString = putStrLn $ polyToMonoid (mempty :: String) True () (Just
(5::Int))
-- product example
instance Monoid Double where
mappend = (*)
mempty = (1.0) :: Double
instance Monoidable Int Double where
toMonoid = fromIntegral
instance Monoidable Double Double where
toMonoid = id
testProduct = putStrLn $ show $ polyToMonoid (mempty :: Double) (5 ::
Int) (2.3 :: Double) (3 :: Int) (8 :: Int)
main = do
testStringList
testString
testProduct
$ runhaskell PolyTest.hs
[True,(),Just 5]
True()Just 5
276.0
Kevin
On Oct 11, 2:39 am, o...@okmij.org wrote:
Sorry, I'm still catching up. I'm replying to first few messages.
instance Show a = Monoidable a [String] where
toMonoid a = [show a]
main = putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int))
fails to compile.
The error message points to the first problem:
No instances for (Monoidable Bool [a],
Monoidable () [a],
...
The presence of the type variable 'a' means that the type checker
doesn't know list of what elements you want (in other words, the
context is not specific enough to instantiate the type variable
a). Thus, we need to explicitly tell that we wish a list of strings:
test3 = putStrLn $ unwrap $polyToMonoid ([]::[String]) True () (Just
(5::Int))
Now we get a different error, which points to the real problem this
time: the expression `unwrap ' appears as an argument to
putStrLn. That means that we are required to produce a String as a
monoid. Yet we specified ([]::[String]) as mempty, which is unsuitable
as mempty for the String monoid. If we desire the [String] monoid as
the result, we need to change the context. For example,
test3 = mapM_ putStrLn $ unwrap $
polyToMonoid ([]::[String]) True () (Just (5::Int))
Another example that also fails to compile (but I cannot see why):
main = putStrLn $ show $ unwrap $ polyToMonoid (0::Int) (1::Int)
(2::Int) (3::Int)
No instance for (PolyVariadic Int (WMonoid m))
arising from a use of `polyToMonoid'
The error message is informative, mentioning the type variable,
m. Whenever that happens, we know that we put a bounded polymorphic
expression in the context that is not specific enough. We need some
type annotations. In our case, the function 'show' can show values of
many types. The type checker does not know that we wish an Int monoid
specifically. So, we have to specialize the show
Re: [Haskell-cafe] Re: Re-order type
djinn[1] can derive some glue functions for you. you tell it something like glue :: (x - y - z - (b,(c,a)) - (c - a - d) - x - y - z - d and it tells you something like glue f g x y z = let (b,(c,a)) = f x y z in g c a I changed the type of f slightly to avoid the trivial answer glue _ g a _ c = g c a [1] http://hackage.haskell.org/package/djinn 2010/10/9 André Batista Martins andre...@netcabo.pt: Might have not been clear, but i will try illustrate . f:: a- b - c - (b,(c,a)) f1 :: c - a - d input type: A B C -- | f | | _ | output (B,(C,A)) C A -- | f1 | | _ | output D If i want compose f and f1, i need to do a correct input to f1 from the output of f. So i want one function to convert the output of f to input off f!. In this case, we do f1 fst (snd (t,(t1,t2))) snd (snd (t,(t1,t2))) But i want do this automaticaly, for type of any two function. I search for the glue. I don't have any concern about what the function does, i only have interess on input and output types. Cheers, André No dia 9 de Outubro de 2010 22:38, André Batista Martins andre...@netcabo.pt escreveu: Hello, exists any algorithm to determine how terms can be changed to safisty the type of one function? example: f:: a- b - c - (b,c,a) f1 :: c - a - d In my first function f i want assign the output c and a for to input of function f1. I searched for any solution, but i didn't find any anything. One clue i have found is minimal edit distance algorithm for 2 strings. Perhaps if i convert de output type of f to one string, and de input of f1 to another string and then use this algorithm , i will get one dirty solution... I'm open to any sugestion. ___ 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] Re: Round benchmarks
On Monday 11 October 2010 07:05:20 you wrote: Hi, These results seem different from the samples. Thanks. The numbers are quite impressive. Although the quotients (hence speedups) are generally much larger, the ranking doesn't differ much. For round :: x - Int, via C is a big win. For round :: x - Integer and properFraction :: Double - (Integer, Double), going via C doesn't seem to make much difference on 64 bits, but they do on 32. That's probably because a Double mantissa is a smallInteger on 64 bits. Overall, your timings support going via C for round and properFraction :: Double - (Integer, Double). In two cases, it makes not much difference on 64 bits but is a big gain on 32, for round :: x - Int, it's a big win on both. I was surprised that the via Integer results appear faster than the Int results. No, the numbers are (Prelude time / new time), so the larger the number, the better. Sorry for not making that clear in the README. Vivian Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pointers for EDSL design
On Fri, Oct 8, 2010 at 10:29 PM, o...@okmij.org wrote: John Lato wrote: So here's a very simple expression: t1 = let v = sigGen (cnst 1) in outs v v which is what led to my question. I'm binding the sigGen to 'v' to introduce sharing at the meta-level. Would it be better to introduce support for this in the dsl? Often this is not a question of preference but that of necessity. Sharing at the meta-level may help the generator, but it does _not_ translate into the sharing at the object level. In the generated code, the code for 'sigGen (cnst 1)' shall be duplicated. It could be that two csound blocks must share the same signal source, to receive samples in parallel. Meta-level sharing (Haskell's let) would not do. We need a construct for an object-level let, for example This was a problem, but I did arrive at a solution. When my interpreter evaluates an expression, it creates a named variable to store the result and memoizes it. Future evaluations of the expression with the same arguments become a reference to the named variable. This works well for functions. However, there may be some operations that should not be memoized. These can be handled by simply having the interpreter re-evaluate the expression. I've found that including a user-supplied label to control memoization creates consistency within the embedded language, and thus a more natural programming style. When targeting csound, the generated code is nearly exactly what I would have written directly, except for auto-generated variable names. I don't yet know how feasible it will be for other interpreters though. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: tls, native TLS/SSL protocol implementation
On Sat, Oct 09, 2010 at 12:53:17PM +0100, Maciej Piechotka wrote: I don't think I quite follow. Could you explain? sorry for beeing confusing. I meant something like a pure iteratee interface, so that you get the marshalled data to send in a bytestring format, and then you can decide yourself what to do with this bytestring (send it to a handle, discard it, process it as the other side) Maybe serverStartTLS? ok, I'll think about it; I'm not thrilled by that though ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Mon, Oct 11, 2010 at 09:06:45AM +0100, Sittampalam, Ganesh wrote: While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. Hi Ganesh, You're absolutely right in the fact there's risk involved. Cryptography related things are hard to get right, I won't be denying it. However I'm really not a big fan of the alternative. Having to rely forever on blessed black boxes coded in low level languages, doesn't sound appealing to me. There's the risk that cryptography becomes even more voodoo magic by doing that. This is certainly true for TLS/SSL. a lots of people have no idea how it works, what it does and doesn't do. So hopefully having a clean haskell library will make more people interested, in changing this black-box state; an even bigger hope, is to vulgarize cryptography, instead of making it more opaque ;) Anyway, it's just a feeling. Please do prove me wrong :-) I'll certainly try ;) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RealFrac methods for Double and Float
On Monday 11 October 2010 04:44:24, Antoine Latter wrote: I have results from my Intel-based MacBook, 64-bits, GHC 7 rc. The quickchecks failed to run: QuickChecking Double properFraction/Int qcDouble: qcDouble.hs:(10,10)-(15,5): Missing field in record construction Test.QuickCheck.Test.chatty QuickChecking Float properFraction/Int qcFloat: qcFloat.hs:(10,10)-(15,5): Missing field in record construction Test.QuickCheck.Test.chatty This is with QuickCheck 2.3.0.2. Oops, I didn't even notice that QC-2.3.* was out, let alone that they added a field to Args. Sorry again. Take care, Antoine Thanks for benchmarking. Your numbers come as an unpleasant surprise. The factors are generally lower than anywhere else I've so far got feedback from, but what's really disconcerting is that the Float - Integer conversions are actually slower than the current, apparently. I have no idea yet how that can be. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to fix undefined reference error with getDataDir?
Hi all, I have two package A and B, and B depend A. I use below code snippets in package A: -- code start -- ... import Paths_manatee_ircclient import System.FilePath ... dir - getDataDir let imagePath imageName = dir / icons / (imageName ++ .png) ... -- code end -- Anyway, package A compile fine, but when i compile package B, i got below error: -- error start -- Linking dist/build/manatee/manatee ... /home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o): In function `s6sP_info': (.text+0x3bea): undefined reference to `manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir3_closure' /home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o): In function `s6sP_info': (.text+0x3bf0): undefined reference to `manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir2_closure' /home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o): In function `s6Uf_info': (.text+0x560f): undefined reference to `__stginit_manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_' /home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o): In function `r5Mp_closure': (.data+0x9d8): undefined reference to `manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir3_closure' /home/andy/.cabal/lib/manatee-ircclient-0.0.1/ghc-6.12.3/libHSmanatee-ircclient-0.0.1.a(Smile.o): In function `r5Mp_closure': (.data+0x9e0): undefined reference to `manateezmircclientzm0zi0zi1_Pathszumanateezuircclient_getDataDir2_closure' collect2: ld returned 1 exit status cabal: Error: some packages failed to install: manatee-0.0.1 failed during the building phase. The exception was: ExitFailure 1 -- error end -- How to fix above error? Thanks! -- Andy Below is .cabal file for package A: -- A.cabal start -- name: manatee-ircclient version:0.0.1 Cabal-Version: = 1.6 license:GPL-3 license-file: LICENSE copyright: (c) 2009 ~ 2010 Andy Stewart synopsis: IRC client extension for Manatee. description:manatee-ircclient is IRC client extension for Manatee (Haskell/Gtk+ Integrated Live Environment) author: Andy Stewart maintainer: Andy Stewart lazycat.mana...@gmail.com stability: provisional category: Development, Other tested-with:GHC==6.12.3 build-type: Simple extra-source-files: Setup.lhs data-dir: icons data-files: angry.png confused.png crying.png embarrassed.png inlove.png kiss.png sleepy.png sad.png laugh.png smile.png surprised.png tired.png tongue.png whistling.png wink.png Library build-depends: base = 4 5, manatee-core = 0.0.1, dbus-client = 0.3 0.4, stm = 2.1.2.0, containers = 0.3.0.0, gtk-serialized-event = 0.11.0, gtk = 0.11.0, text = 0.7.1.0, bytestring = 0.9.1.5, dbus-core, template-haskell, gtksourceview2 = 0.11.0, unix = 2.4.0.0, network, groom, fastirc = 0.2.0, split = 0.1.2, nano-md5 = 0.1.2, filepath, regex-posix = 0.94.1, array = 0.3.0.0, GoogleTranslate = 0.0.3, utf8-string, mtl, Cabal exposed-modules: Manatee.Extension.IrcClient Manatee.Extension.IrcClient.Types Manatee.Extension.IrcClient.DBus Manatee.Extension.IrcClient.Daemon Manatee.Extension.IrcClient.HighlightNick Manatee.Extension.IrcClient.IrcBuffer Manatee.Extension.IrcClient.IrcView Manatee.Extension.IrcClient.Smile other-modules: extensions: ghc-options: -O -fwarn-unused-matches -fwarn-unused-binds -fwarn-unused-imports -fwarn-overlapping-patterns -fwarn-duplicate-exports -threaded -fwarn-unrecognised-pragmas -fwarn-hi-shadowing Executable manatee-irc-daemon main-is: Main.hs ghc-options: -threaded -- A.cabal end -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pointers for EDSL design
John, Oleg, 2010/10/9 o...@okmij.org: So here's a very simple expression: t1 = let v = sigGen (cnst 1) in outs v v which is what led to my question. I'm binding the sigGen to 'v' to introduce sharing at the meta-level. Would it be better to introduce support for this in the dsl? Often this is not a question of preference but that of necessity. Sharing at the meta-level may help the generator, but it does _not_ translate into the sharing at the object level. In the generated code, the code for 'sigGen (cnst 1)' shall be duplicated. It could be that two csound blocks must share the same signal source, to receive samples in parallel. Meta-level sharing (Haskell's let) would not do. We need a construct for an object-level let, for example t1 = let_ (SigGen (cnst 1)) (\v - outs v v) An alternative approach to model sharing at the object level is the technique I use for modelling context-free grammars in my PADL 2011 paper Explicitly Recursive Grammar Combinators [1] (just got acceptance notification this morning!). The idea is basically that you make the sharing in the object-level expression explicit by modelling all your terms as the results of one big recursive function and then opening up the recursion. Using ideas from the Multirec generic programming library and some recent Haskell type system extensions (most importantly GADTs and type families), you can do this in a well-typed way for sets of mutually recursive object-level expressions. In this case, you would get something like the following (written without any understanding of your problem domain, so sorry if I interpret stuff wrong here ;) ): data I1 data T1 data CircuitNode ix where I1 :: CircuitNode I1 T1 :: CircuitNode T1 myCircuit self I1 = sigGen (cnst 1) myCircuit self T1 = outs (self I1) (self I1) With a type class such as RecProductionRule in my paper, you can then even get rid of the self argument and get something like this: myCircuit I1 = sigGen (cnst 1) myCircuit T1 = outs (ref I1) (ref I1) The main advantage is that this approach extends to circuits with mutually recursive nodes, but contrary to simple meta-level sharing, allows you to observe and manipulate the recursive structure of the circuit. Oh, and it stays properly typed. More info in the paper and the accompanying technical report [2]. cheers Dominique Footnotes: [1] http://people.cs.kuleuven.be/~dominique.devriese/permanent/cfgc-submitted-PADL.pdf [2] http://www.cs.kuleuven.be/publicaties/rapporten/cw/CW594.abs.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static computation/inlining
On Sun, Oct 10, 2010 at 10:51 PM, Alexander Solla a...@2piix.com wrote:
Is there anyway to instruct GHC (and maybe other compilers) to compute these
maps statically? Are GHC and the other compilers smart enough to do it
automatically? Although the list isn't huge, I would still rather get rid of
the O(2*n) operation of turning it into maps at run-time. (Especially since
some later list encodings like these might be enormous) What should I be
looking into?
You may use Template Haskell and forget about the 'Data.Map's entirely =).
I've attached a proof-of-concept code that turns
list :: [(a,b)]
list = [(x1,y1), (x2, y2), ..., (xn, yn)]
into two functions (you can choose the names)
fromAtoB :: a - b
fromAtoB x1 = y1
fromAtoB x2 = y2
...
fromAtoB xn = yn
fromBtoA :: b - a
fromBtoA y1 = x1
...
fromBtoA yn = xn
but with the arguments tranformed to patterns.
Compiling a test module:
$ ghc -ddump-splices -c ModuleWithFunctions.hs
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading package array-0.3.0.1 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
ModuleWithFunctions.hs:1:0:
ModuleWithFunctions.hs:1:0: Splicing declarations
bimap
map_country_to_country_code
map_country_code_to_country
countries_and_iso_country_codes
==
ModuleWithFunctions.hs:8:2-98
map_country_to_country_code Afghanistan
= ISOCountryCode AF AFG (NC 4)
map_country_to_country_code AlandIslands
= ISOCountryCode AX ALA (NC 248)
map_country_to_country_code Albania = ISOCountryCode AL ALB (NC 8)
map_country_to_country_code Zimbabwe
= ISOCountryCode ZW ZWE (NC 716)
map_country_code_to_country ISOCountryCode AF AFG NC 4
= Afghanistan
map_country_code_to_country ISOCountryCode AX ALA NC 248
= AlandIslands
map_country_code_to_country ISOCountryCode AL ALB NC 8 = Albania
map_country_code_to_country ISOCountryCode ZW ZWE NC 716 = Zimbabwe
So two functions were spliced into your code with explicit pattern
matches. I don't know how efficient is the code that GHC generates
for functions with many patterns. Now, testing them:
$ ghci
GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
:Prelude :l Module
[4 of 4] Compiling Module ( Module.hs, interpreted )
Ok, modules loaded: Module, ModuleWithData, ModuleWithFunctions, Template.
*Module :bro Module
data Country = Afghanistan | AlandIslands | Albania | Zimbabwe
data ISOCountryCode = ISOCountryCode TwoCode ThreeCode NumCode
data NumCode = NC Int
data ThreeCode = AFG | ALA | ALB | ZWE
data TwoCode = AF | AX | AL | ZW
countries_and_iso_country_codes :: [(Country, ISOCountryCode)]
isoNumericCode :: Int - NumCode
map_country_code_to_country :: ISOCountryCode - Country
map_country_to_country_code :: Country - ISOCountryCode
*Module map_country_to_country_code Albania
Loading package array-0.3.0.1 ... linking ... done.
Loading package containers-0.3.0.0 ... linking ... done.
Loading package pretty-1.0.1.1 ... linking ... done.
Loading package template-haskell ... linking ... done.
ISOCountryCode AL ALB (NC 8)
*Module map_country_code_to_country $ ISOCountryCode AL ALB (NC 8)
Albania
Cheers! =)
--
Felipe.
{-# LANGUAGE DeriveDataTypeable #-}
module ModuleWithData where
import Data.Data
import Data.Typeable
data Country = Afghanistan | AlandIslands | Albania | Zimbabwe
deriving (Data, Eq, Ord, Show, Typeable)
data ISOCountryCode = ISOCountryCode TwoCode ThreeCode NumCode
deriving (Data, Eq, Ord, Show, Typeable)
data TwoCode = AF | AX | AL | ZW
deriving (Data, Eq, Ord, Show, Typeable)
data ThreeCode = AFG | ALA | ALB | ZWE
deriving (Data, Eq, Ord, Show, Typeable)
data NumCode = NC Int
deriving (Data, Eq, Ord, Show, Typeable)
isoNumericCode :: Int - NumCode
isoNumericCode = NC
countries_and_iso_country_codes :: [ (Country, ISOCountryCode) ]
countries_and_iso_country_codes =
[ (Afghanistan, ISOCountryCode AF AFG (isoNumericCode 004))
, (AlandIslands, ISOCountryCode AX ALA (isoNumericCode 248))
, (Albania, ISOCountryCode AL ALB (isoNumericCode 008))
, (Zimbabwe, ISOCountryCode ZW ZWE (isoNumericCode 716))
]
{-# LANGUAGE TemplateHaskell #-}
module
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, Oct 11, 2010 at 08:37, Michael Snoyman mich...@snoyman.com wrote: [...] Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I'd be weary of making that a requirement, there are good reasons for not putting your picture on the web, just like there are good reasons to not use your real name :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning mag...@therning.org wrote: On Mon, Oct 11, 2010 at 08:37, Michael Snoyman mich...@snoyman.com wrote: [...] Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I'd be weary of making that a requirement, there are good reasons for not putting your picture on the web, just like there are good reasons to not use your real name :-) ... just like there are good reasons not to publish yourself in a public catalogue (such as haskellers.com) at all. I have nothing against anonymity. I voted against requirement of real names on hackage. But in this particular case, the whole point to be in the listing is to present yourself. So I find the above proposal very reasonable. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
On Mon, Oct 11, 2010 at 09:41, Brandon Moore brandon_m_mo...@yahoo.com wrote: While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this. Especially when we have nice things like the type system, which can be used to alleviate many of the security worries. I agree in general, for code like servers and file formats, but I worry in particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key. I personally think we have to draw the line somewhere regarding what we care about when it comes to security. (Provable) correctness, maintainability through well-structured code are things we are more likely to gain through using high-level languages like Haskell. That is actually a lot of security bundled up in those things. What we lose is low-level control, which would be required to thwart side-channel attacks. On the other hand, I'm not convinced openssl or gnutls deal with side-channel attacks very effectively either. In any case, there is nothing that says we must have only *one* SSL library, based on this discussion there seems to be people in the community who still would prefer a binding to openssl/gnutls. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
2010/10/11 Roman Cheplyaka r...@ro-che.info: On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning mag...@therning.org wrote: On Mon, Oct 11, 2010 at 08:37, Michael Snoyman mich...@snoyman.com wrote: [...] Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I'd be weary of making that a requirement, there are good reasons for not putting your picture on the web, just like there are good reasons to not use your real name :-) ... just like there are good reasons not to publish yourself in a public catalogue (such as haskellers.com) at all. I have nothing against anonymity. I voted against requirement of real names on hackage. But in this particular case, the whole point to be in the listing is to present yourself. So I find the above proposal very reasonable. Hi, In the belgian law, an employer can (of course) request a faithful resume, but cannot request the resume to contain a picture of you. This is a clear example where you wish to advertise yourself, but not necessarily with a picture. Anyway, I don't think it is difficult to imagine situations where one doesn't wish to show a picture of his/her face. Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, 11 Oct 2010 13:09:00 +0200, Vo Minh Thu not...@gmail.com wrote: 2010/10/11 Roman Cheplyaka r...@ro-che.info: On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning mag...@therning.org wrote: On Mon, Oct 11, 2010 at 08:37, Michael Snoyman mich...@snoyman.com wrote: [...] Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I'd be weary of making that a requirement, there are good reasons for not putting your picture on the web, just like there are good reasons to not use your real name :-) ... just like there are good reasons not to publish yourself in a public catalogue (such as haskellers.com) at all. I have nothing against anonymity. I voted against requirement of real names on hackage. But in this particular case, the whole point to be in the listing is to present yourself. So I find the above proposal very reasonable. Hi, In the belgian law, an employer can (of course) request a faithful resume, but cannot request the resume to contain a picture of you. This is a clear example where you wish to advertise yourself, but not necessarily with a picture. Anyway, I don't think it is difficult to imagine situations where one doesn't wish to show a picture of his/her face. Agree. But then there should be no picture at all for a given person. As Michael said -- no cartoons, no identicons. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
From: Michael Snoyman mich...@snoyman.com Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I agree that it would be nice to use only real pictures, however I wouldn't want to leave out those who choose not to use any image at all. What about a site policy that user images must be real pictures (if they exist), and violations can be flagged/blocked? Although, I don't know how this would interact with using OpenID, which appears to be most of the users currently displaying an identicon. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, 11 Oct 2010 13:14:21 +0100, John Lato jwl...@gmail.com wrote: From: Michael Snoyman mich...@snoyman.com Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I agree that it would be nice to use only real pictures, however I wouldn't want to leave out those who choose not to use any image at all. What about a site policy that user images must be real pictures (if they exist), and violations can be flagged/blocked? Although, I don't know how this would interact with using OpenID, which appears to be most of the users currently displaying an identicon. This is Gravatar's issue, which has little to do with OpenID, as far as I understand. -- Roman I. Cheplyaka :: http://ro-che.info/ Don't let school get in the way of your education. - Mark Twain ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Hello Henning, hxt-filter does not seem to be updated to hxt-9.0. How about providing hxt-filter with DEPRECATED pragmas for the functions that tell me how to rewrite functions from hxt-filter to arrows? Or is there another guide about how to move from hxt-filter to arrows? Sorry, but there is no complete guide for rewriting filter code into code working with arrows because of lack of time. Besides developing and documenting hxt, there are a few other things, that have to be done. It's rather easy to convert to the arrow style. All the functionality of hxt-filter is available in hxt. Most of the names and operators remain as they are. Declare type XmlFilter = LA XmlTree XmlTree That's the equivalent arrow type. When evaluating a filter expression, use runLA filter input When switching to the arrow style, some of the operators had to be renamed to the standard arrow operators, e.g. (.) to () and (+++) == (+) For the monadic filters, mainly used for filters with IO use the Type IOSArrow XmlTree XmlTree and start a computation with runX, as described in the examples of the wiki page about hxt: http://www.haskell.org/haskellwiki/HXT#copyXML Just compile your sources with these changes, and use the Haskell compiler for finding ALL points, where you have to modify or rename something. If the code compiles, it will run. Please trust in strong typing, Uwe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, Oct 11, 2010 at 13:14, John Lato jwl...@gmail.com wrote: From: Michael Snoyman mich...@snoyman.com Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I agree that it would be nice to use only real pictures, however I wouldn't want to leave out those who choose not to use any image at all. What about a site policy that user images must be real pictures (if they exist), and violations can be flagged/blocked? Although, I don't know how this would interact with using OpenID, which appears to be most of the users currently displaying an identicon. I think it would be wrong to have haskellers.com impose restrictions on what image I put on gravatar. My image on gravatar pops up in numerous other sites (I believe stackoverflow, ohloh, flickr, etc) and I'm not necessarily happy with putting my photo everywhere, even though I'd be fine with putting it on haskellers.com. So, instead I'd like to see the use of gravatar become optional. Then if haskellers.org could require a photo, and I could simply choose not to get my cartoon image from gravatar. An obvious extension would be to allow me to get the image from other sources in the future, maybe an option to grab a picture out of an album on Facebook, or Flickr? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Hi Gregory, Could you explain to me why HXT uses arrows? I have never been able to figure out what advantage this gives your library over monads. Since your arrows in practice implement ArrowApply, they are really just monads anyway, so it seems to me that using arrows instead of monads only serves to add complexity to the library without adding any benefit. Furthermore, by using arrows instead of monads people cannot use the many standard monad libraries out there, but have to instead write their own generalizations of them to arrows. Is there some benefit that your library gets out of using arrows that I missed which makes these costs worth it? Hi Heinrich, I have the same question. It looks like the arrows in HXT are typed version of CFilter from Malcolm Wallace, Colin Runciman. Haskell and XML: Generic Combinators or Type-Based Translation? http://www.haskell.org/HaXml/icfp99.html but it appears to me that representing them as type Filter a b = a - [b] allows the use of the list monad, which would highlight the similarity between list comprehensions and working with XML trees. I thing, this is not a question of functionality, it's a question of style. Of course everything in hxt could have been done with monads, but does this also mean: Everything must have been done with monads? We all have learned the elegant style of point free programming as described in IFPH and Richard Birds new book gives a lot more valuable examples of this. When these elegant algorithms have to be generalized, e.g. to do some IO, we have to rewrite the whole algorithms in a monadic style. I don't like this. Arrows are a generalisation of functions, so if you know all about working with functions you know (almost) all about working with arrows. When generalizing a pure algorithm, something like f3 . f2 . f1, or in Unix pipe style f1 f2 f3, you don't have to rewrite the code, you just generalize function composition. When constructing code, it is of course sometimes simpler to start with a point wise version and then refactor and rewrite it into a more compact point free version. The problem with arrows seems, that the arrow style forces to start with the point free style. And that may be the main hurdle in mind. What we should have done in hxt, is to combine the arrows with arbitrary monads, at the moment the monadic arrows work with a combination of a state and IO. The list gives us the nondeterminism and the exception (empty list). You can do a lot of things with this, but it can be generalized. And perhaps we'll do this in the future. I hope this shows a bit of the motivation for taking the arrow approach, Uwe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Static computation/inlining
On Sun, 10 Oct 2010 18:51:59 -0700, Alexander Solla a...@2piix.com wrote: Although the list isn't huge, I would still rather get rid of the O(2*n) operation of turning it into maps at run-time. I usually handle this as follows: 1) I create my data file in some human-friendly format (such as your list of tuples), so that I can easily edit it later, as required. 2) I write a program, a sort of preprocessor, that (a) loads the data from the human-friendly format into a processing-friendly structure, and then (b) serializes that structure into a file that's efficient to load at run time. (So, for example, lookups from the name of a country to its ISO codes can be handled via a Patricia structure; a Patricia structure is tedious to construct, but once constructed, is easy to serialize and de-serialize.) 3) The file containing the serialized structure is then linked into the rest of the real program as a source unit, where the serialized structure is represented as a constant (usually a string, but sometimes an array of numbers, etc.). If your build environment has a reasonable make-like tool, then the whole process is pretty automatic; you just modify the human-friendly file as often as you want, and the preprocessor is invoked automatically, as needed. -Steve Schafer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, Oct 11, 2010 at 2:44 PM, Magnus Therning mag...@therning.org wrote: On Mon, Oct 11, 2010 at 13:14, John Lato jwl...@gmail.com wrote: From: Michael Snoyman mich...@snoyman.com Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I agree that it would be nice to use only real pictures, however I wouldn't want to leave out those who choose not to use any image at all. What about a site policy that user images must be real pictures (if they exist), and violations can be flagged/blocked? Although, I don't know how this would interact with using OpenID, which appears to be most of the users currently displaying an identicon. I think it would be wrong to have haskellers.com impose restrictions on what image I put on gravatar. My image on gravatar pops up in numerous other sites (I believe stackoverflow, ohloh, flickr, etc) and I'm not necessarily happy with putting my photo everywhere, even though I'd be fine with putting it on haskellers.com. So, instead I'd like to see the use of gravatar become optional. Then if haskellers.org could require a photo, and I could simply choose not to get my cartoon image from gravatar. An obvious extension would be to allow me to get the image from other sources in the future, maybe an option to grab a picture out of an album on Facebook, or Flickr? So firstly, just to clarify, I was never recommending we make real photos a requirement to have an account on Haskellers. I was simply talking about the 10 random profiles that get shown on the homepage: I think it gives a more professional feel to the site if we see 10 real people and not Bart Simpson. That was my question. Now, the idea of using something besides gravatar is a fair point. I know personally I *like* it when sites use gravatar, as it's one less site I have to upload my image to. Otherwise, I need to search around for my preferred profile image, crop it to whatever that site wants, hope they'll scale it nicely, etc. From the site maintainer standpoint, gravatar also means there's less moving parts on Haskellers, and it decreases our bandwidth significantly, which is definitely something to consider. I'll definitely put some thought into providing an alternative to gravatar. In the meanwhile, an option you have is to add a second gravatar email address. This works especially well with Gmail accounts, where you can just use a + sign (eg, michael+haskell...@snoyman.com). I'm not saying this is ideal, but if you want to have your real photo up, it will work today. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings
No immediate plans but thanks for pointing that out - I hadn't seen it yet. Similar functionality exists in the haskelldb-th package, without the special type operators. On Fri, Oct 8, 2010 at 5:19 PM, Bas van Dijk v.dijk@gmail.com wrote: Great work! I think I'm going to use it. Any plan on packaging up Christopher Done's HaskellDB's type operators: http://chrisdone.com/posts/2010-10-07-haskelldb-and-typeoperator-madness.html Which allows you to write something like: type PersonTable = Table :$: Expr :%: Id ::: Integer :+: Age ::: Integer :+: Email ::: String :+: Blurb ::: Maybe String :+: End Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings
On 11 October 2010 16:45, Justin Bailey jgbai...@gmail.com wrote: No immediate plans but thanks for pointing that out - I hadn't seen it yet. Similar functionality exists in the haskelldb-th package, without the special type operators. Hey that's cool, I hadn't seen that. This'll reduce my code significantly, especially mkFieldWithName. Cheers! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings
On Mon, Oct 11, 2010 at 7:56 AM, Christopher Done chrisd...@googlemail.com wrote: Hey that's cool, I hadn't seen that. This'll reduce my code significantly, especially mkFieldWithName. Cheers! I'm not sure if it supports the parameterization of records that you detailed in your post - let me know how it works for you. Patches always welcome as well :) Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskelldb-users] ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings
Hooray for collaboration! I think this emphasizes the need for some sort of social aspect on Hackage... On Mon, Oct 11, 2010 at 10:58 AM, Justin Bailey jgbai...@gmail.com wrote: On Mon, Oct 11, 2010 at 7:56 AM, Christopher Done chrisd...@googlemail.com wrote: Hey that's cool, I hadn't seen that. This'll reduce my code significantly, especially mkFieldWithName. Cheers! I'm not sure if it supports the parameterization of records that you detailed in your post - let me know how it works for you. Patches always welcome as well :) Justin ___ 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: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Uwe, Thank you for your reply. On 10/11/10 6:20 AM, Uwe Schmidt wrote: I thing, this is not a question of functionality, it's a question of style. Of course everything in hxt could have been done with monads, but does this also mean: Everything must have been done with monads? No, but there is no point in using a formalism that adds complexity without adding functionality. Arrows are more awkward to use than monads because they were intentionally designed to be less powerful than monads in order to cover situations in which one could not use a monad. When your problem is solved by a monad there is no point in using arrows since an arrow require you to jump through extra hoops to accomplish the same goal. Arrows are a generalisation of functions, so if you know all about working with functions you know (almost) all about working with arrows. When generalizing a pure algorithm, something like f3 . f2 . f1, or in Unix pipe style f1 f2 f3, you don't have to rewrite the code, you just generalize function composition. Yes, but the = operator lets you do the same thing with monads, and in fact I use it all the time to do point-free programming with monads, so this isn't at all an advantage that arrows have over monads. When constructing code, it is of course sometimes simpler to start with a point wise version and then refactor and rewrite it into a more compact point free version. The problem with arrows seems, that the arrow style forces to start with the point free style. And that may be the main hurdle in mind. No, that is not at all the problem with arrows. The problem with arrows is that they are more restrictive than monads in two respects. First, unlike monads, in general they do not let you perform an arbitrary action in response to an input. Second, they place restrictions on how you define the input arguments of the arrow because you can't feed the output of one arrow into to input of the next unless said input is captured in the arrows type. To be more concrete about my second point, suppose you have some monadic action f :: a - b - m c How would you structure this same action as an arrow? One thing that you could do is take one of the arguments and turn it into the input of the arrow: f' :: a - Arrow b c But now you can't feed the output of an arrow into the first argument. Alternatively, you could pack both arguments into the input of the arrow: f'' :: Arrow (a,b) c Great, but now you have made it more awkward to use f'' because you have to always pack the arguments into a tuple, so that for example if one of the arguments is a constant then you can no longer easily use currying. The advantage of f over both alternatives is that you don't have to waste any of your time fitting multiple input arguments into the input type of an arrow. In fact, if the first argument to f'' is usually a constant, then f'' is arguably more awkward to use in a point-free setting than f, because instead of being able to write a = f 42 = b You have to write something like a (const 42 id) f'' b Of course, if the first argument were *always* a constant then you could use f', but then you lose the ability to ever feed in the output of an arrow into the first argument. So in short, arrows force you to make choices and trade-offs that never come up when using monads. In conclusion, while I greatly appreciate you taking the time to explain your reasoning, it still looks to me like there is nothing you have gained by using arrows except adding extra unnecessary complexity in your library. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RealFrac methods for Double and Float
On Monday 11 October 2010 04:44:24, Antoine Latter wrote: I have results from my Intel-based MacBook, 64-bits, GHC 7 rc. Results from ncgFloat: Relations for properFraction: Prelude 1.00 C via Integer0.333999 Hs via Integer 0.499852 C Int4.417461 Hs Int 4.558648 Puzzle solved. I have run the benchmarks with the latest HEAD and got broadly similar results. GHC's new code generator does some incredible stuff with the code for Float's RealFrac instance, properFraction has become about _seven times_ faster, floor and ceiling about _thirteen times_ and round about _10.5 times_ (values for my box, the exact numbers will differ, but the tendency will be the same). Just Wow! My code for properFraction :: Float - (Integer, Float) has become 1.7 times slower when calling out to C, everything else has either changed hardly at all or become slightly faster (5-10%). The overall result is that for Float, in the general case, the current implementation is faster and overall the speedups are less impressive than they were for 6.12. So I'll have to re-learn what GHC does with which kind of code. Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Gregory Crosswhite schrieb: In conclusion, while I greatly appreciate you taking the time to explain your reasoning, it still looks to me like there is nothing you have gained by using arrows except adding extra unnecessary complexity in your library. As a pragmatic question: Would it be possible to split hxt even further into hxt (core) and hxt-arrow, and resurrect hxt-filter? This way people could choose the way they like to process XML. Or is it too tedious to maintain both hxt-arrow and hxt-filter? Is it possible to implement one interface in terms of the other one? It seems that the filter interface is the more general one, such that the arrow interface may be implemented in terms of filters. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Hi, Am Montag, den 11.10.2010, 21:29 +0200 schrieb Henning Thielemann: Gregory Crosswhite schrieb: In conclusion, while I greatly appreciate you taking the time to explain your reasoning, it still looks to me like there is nothing you have gained by using arrows except adding extra unnecessary complexity in your library. As a pragmatic question: Would it be possible to split hxt even further into hxt (core) and hxt-arrow, and resurrect hxt-filter? This way people could choose the way they like to process XML. Or is it too tedious to maintain both hxt-arrow and hxt-filter? Is it possible to implement one interface in terms of the other one? It seems that the filter interface is the more general one, such that the arrow interface may be implemented in terms of filters. without having something to add about arrows to the discussion, a little side note from your distribution package maintainer: Before you split up stuff even more into little packages, consider keeping one package but offering different modules If it is just about offering alternative APIs (and not really avoiding additional dependencies), this should be sufficient and is less work for us. Thanks, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org 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] Re: A question regarding cmdargs package
Hi Ben, How can I disable the standard arguments 'help' and 'version'? In general I suggest you email the author of the cmdargs package directly, as well as cc'ing the mailing list (otherwise the author might miss this message, as I did!) In CmdArgs there is currently no way to suppress either --help or --version, but I am currently reviewing a patch (from you!) and expect that the next version will have both these features. The hard part is making sure the defaults match what people expect and that the options to modify the behaviour are discoverable and natural, but I'm sure I'll find something. Thanks, Neil If you're not fully committed to the cmdargs package, you might try my package 'console-program' instead http://hackage.haskell.org/package/console-program. It does not have built-in --help or --version functionality. (There is a function 'showUsage' that takes the description of the command/option structure of your program, and prints --help style usage information, but you use this at your own discretion.) Thanks, looks good. I will certainly try it out. Cheers Ben ___ 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] Re: A question regarding cmdargs package
On 11/10/10 22:04, Neil Mitchell wrote: Hi Ben, How can I disable the standard arguments 'help' and 'version'? In general I suggest you email the author of the cmdargs package directly, as well as cc'ing the mailing list (otherwise the author might miss this message, as I did!) In CmdArgs there is currently no way to suppress either --help or --version, but I am currently reviewing a patch (from you!) and expect that the next version will have both these features. The hard part is making sure the defaults match what people expect and that the options to modify the behaviour are discoverable and natural, but I'm sure I'll find something. This makes me curious. What's the use case where you want to allow the user to pass arguments on the command line, but you don't want that user to be able to use '--help' to find out what arguments may be passed? /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A question regarding cmdargs package
On 12 October 2010 16:32, Magnus Therning mag...@therning.org wrote: This makes me curious. What's the use case where you want to allow the user to pass arguments on the command line, but you don't want that user to be able to use '--help' to find out what arguments may be passed? When you don't want to bother defining the help options/descriptions? :p (alternatively, you may wish to provide a more full-featured version like what darcs does by using a pager) -- 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
