- Haskell-Cafe - Haskell.org

LINQ
by Niklas Broberg 28 Oct '05

28 Oct '05

Why is it that everything that OO "steals" from the functional paradigm is always marketed as something new that will revolution the way we program? Can't they at least give some credit where credit is due? :-p http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/libra… /Niklas

3 2

Quickcheck examples and Data.Word32
by Joel Reymont 28 Oct '05

28 Oct '05

Folks, Does anyone have QuickCheck examples they could send me? Also, how can I check Word32, Word64, etc. properties? It looks like the built-in random generator only works with Int values and for the life of me I cannot figure out how to extend it. Last but not least, I'm trying to figure out how I can use QuickCheck with tests against a network server. I would want to make sure that a certain packet sequence always produces a particular packet sequence in response. Is this a good area to apply QC? Thanks, Joel -- http://wagerlabs.com/

6 20

hugs type inference
by Christian Maeder 27 Oct '05

27 Oct '05

Hi, Hugs leaves an odd context when showing the type of the following expression. Is this a bug or just a harmless flaw? Christian Hugs.Base> :t toRational 1 / 2 toRational 1 / 2 :: Real a => Ratio Integer ghci yields: Prelude> :t toRational 1 / 2 <interactive>:1:0: Warning: Defaulting the following constraint(s) to type `Integer' `Real a' arising from use of `toRational' at <interactive>:1:0-9 In the first argument of `(/)', namely `toRational 1' toRational 1 / 2 :: Rational

2 1

Nice way to calculate character frequency in a string
by Scherrer, Chad 27 Oct '05

27 Oct '05

Sorry to drag this thread out, but here's one more thing you might try... I was thinking, if we just wanted something like intTable :: [Int] -> [(Int, Int)] we could just replace Map with IntMap in the previous solution: intTable xs = IntMap.assocs $! foldl' f IntMap.empty xs where f m x = let m' = IntMap.insertWith (+) x 1 m Just v = IntMap.lookup x m' in v `seq` m' To get another polymorphic version, we could just write this wrapper: freq :: (Enum a) => [a] -> [(a,Int)] freq = map fstToEnum . intTable . map fromEnum where fstToEnum (x,y) = (toEnum x, y) This seems to run faster than the other polymorphic version on my machine. Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

3 2

Monads as control structures?
by Creighton Hogg 27 Oct '05

27 Oct '05

Hi, so I'm a newbie getting used to Haskell. I'm writing some simple things like genetic algorithms in it for practice, and I keep coming across something that really bugs me: are there any standard libraries that allow you to do imperative style for or while loops using monads to keep track of state? I know there's things like "until", but honestly that's not quite what I'm looking for. I just think there should be a simple way to say "execute this block of code 10 times" without having to wrap it up in recursion. Haskell seems to me to be a very powerful language, and it looks like it should be possible to define control structures such as for loops using monads.

6 5

Re: [Haskell-cafe] Monads as control structures?
by Creighton Hogg 27 Oct '05

27 Oct '05

On Thu, 27 Oct 2005, Creighton Hogg wrote: > On Thu, 27 Oct 2005, Robert Dockins wrote: > > > > > On Oct 27, 2005, at 11:54 AM, Creighton Hogg wrote: > > > > > Hi, > > > so I'm a newbie getting used to Haskell. I'm writing some > > > simple things like genetic algorithms in it for practice, > > > and I keep coming across something that really bugs me: > > > are there any standard libraries that allow you to > > > do imperative style for or while loops using monads to keep > > > track of state? > > > One way is to create a list of the actions you want to execute, and > > then use one of the sequence family of functions. > > The actions can share state with an IORef or STRef or whatever. > > Another option is to use a fold with >>= to allow > > actions to pass their results directly to the next action. This > > works even in "stateless" monads like the list monad. > > > > Some examples using sequence: > > > > > > forMonad :: Monad m => a -> (a -> Bool) -> (a -> a) -> (a -> m ()) -> > > m () > > forMonad init cond inc f = sequence_ $ map f $ takeWhile cond $ > > iterate inc init > > > > xTimes :: Monad m => Int -> (Int -> m ()) -> m () > > xTimes x f = sequence_ $ map f [0..(x-1)] > > > > main = do { forMonad 0 (<10) (+1) (putStrLn . show); xTimes 10 (\_ -> > > putStrLn "hi") } > > Thanks to all who answered, this gives me a lot to chew on. > I especially like these examples, because it makes me > realize that I've been thinking about monads and evaluation > wrong. > I think doing genetic programming in Haskell is going to be > easier than I thought. >

1 0

Haskell scripting system (please help me simplify the design)
by Joel Reymont 27 Oct '05

27 Oct '05

Folks, With lots of help from #haskell and haskell-cafe I came up with the following setup. It's working fine but requires quite a bit of boilerplate code. Could you please help me simplify it? I apologize for the very long message and will describe any parts that are unclear. Please ask away. This is my first Haskell code, written over the course of 3 weeks (1 week to learn Haskell) so I'm bound to get some things wrong or unoptimal. Still, I'm quite amazed that I have been able to get this to work and to work correctly in such a short time span. The system is basically a scripting engine to test a poker server that lets you write simple scripts. I went out of my way to enable QA techs to use as little Haskell as possible, thus I'm treating all poker commands/packets as a list of properties. What I found is that I'm writing a lot of boiler-plate code to handle the convertion of property values into "storables". I think this dovetails into the recent GADT discussion. I wonder if my design and interaction between Packet, Convertible, Prop and Attr can be simplified. These are a couple of sample scripts (incomplete): --- module Test where import Script import Handshake as H script env = do setDebugLevel 100 dotimes 1 $ launch $ H.script [] waitForChildren --- module Handshake where import Script script env = -- connect to server do world <- connect env "192.168.0.197" 15667 -- setup callbacks world <- add world [ [ onCmd := CmdHandshake Server, call := onServerHandshake ], [ onCmd := CmdConnectGame Server, call := onConnectGame ], [ onCmd := CmdServerInfo Server, call := onServerInfo ], [ onCmd := CmdLogon Server, call := onLogon ], [ onCmd := CmdGameInfo Server, call := onGameInfo ], [ onCmd := CmdMoney Server, call := onMoney ] ] -- start handshake send world $ make (CmdHandshake Invalid) [] run world onServerHandshake cmd world = do send world $ make (CmdConnectGame Client) [ localIP := "10.0.0.2", affiliateID := [28] ] return world onServerInfo cmd world = do send world $ make (CmdLogon Client) [ name := "foo", password := "bar", affiliateID := [28] ] -- retrieve table id tables' <- get tables cmd debug 99 $ "Tables: " ++ show tables' tableID' <- get tableID $ head tables' debug 99 $ "TableID: " ++ show tableID' debug 99 $ "World: " ++ show world -- save it for later use world <- set (tableID := tableID') world -- return updated info return world onGameInfo cmd world = do debug 99 "Got game!" stop world --- I'm describing binary packets using properties (from WxHaskell) with the added twist that when you say attr := value you can specify what value will be converted to for storage. This is how I would use the system... This describes the properties for the admin message and wait list init commands. I would use the properties to serialize the commmands. cmdProps (CmdAdminMessage Server) = [ title := "", message := "", postAction := 0 ] cmdProps (CmdSrvWaitListInit Server) = [ waitListTables := [] ] I also have a "dictionary" that describes the attributes such as title, message, postAction, etc. I'm allowing deeply nested lists of properties. title :: Attr String WString = makeAttr "title" message :: Attr String WString = makeAttr "message" postAction :: Attr Word8 Word8 = makeAttr "postAction" waitListTables :: Attr [TableID] (FixedList Word8 (LE TableID)) = makeAttr "waitListTables" Attr String WString means that a String is accepted on the right-hand side and the string will be converted into a wide string for storage. Same thing with a list of table ids that is converted into a list of little-endian table ids (word32s) prefixed by a Word8 length for storage. The conversion/casting is done with code like this: class Convertible a b where convert_AB :: a -> b convert_BA :: b -> a instance Convertible [Word8] FastString where convert_AB a = packWords a convert_BA b = unpackWords b instance Convertible Bool Bool where convert_AB a = a convert_BA b = b instance Convertible Bool Word8 where convert_AB True = 1 convert_AB False = 0 convert_BA 1 = True convert_BA 0 = False instance Convertible String WString where convert_AB a = WString $ FS.pack a convert_BA (WString b) = FS.unpack b instance Convertible (String, String) (WString, WString) where convert_AB (a1, a2) = (convert_AB a1, convert_AB a2) convert_BA (b1, b2) = (convert_BA b1, convert_BA b2) instance Convertible [String] (FixedList (LE Word32) WString) where convert_AB a = FixedList $ map convert_AB a convert_BA (FixedList b) = map convert_BA b My concern is mostly with a lot of similar boilerplate code required for casting, specially in very alike cases like the following: data Pot = Pot [Prop] deriving (Eq, Show, Typeable) data BaseTableState = BaseTableState [Prop] deriving (Eq, Show, Typeable) instance Packet Pot where unstuff xs = case props of Just props -> (Just $ Pot props, xs') Nothing -> (Nothing, xs) where (props, xs') = unstuffprops xs potProps <<< this is the only difference stuff (Pot a) = stuffprops a size (Pot a) = sizeprops a instance Convertible [Prop] Pot where convert_AB a = Pot $ mergeprops a potProps convert_BA (Pot b) = b instance Packet BaseTableState where unstuff xs = case props of Just props -> (Just $ BaseTableState props, xs') Nothing -> (Nothing, xs) where (props, xs') = unstuffprops xs baseTableStateProps stuff (BaseTableState a) = stuffprops a size (BaseTableState a) = sizeprops a instance Convertible [Prop] BaseTableState where convert_AB a = BaseTableState $ mergeprops a baseTableStateProps convert_BA (BaseTableState b) = b Notice that the differences are only in the list of properties required for conversion. I'm wondering if this can be simplified somehow. This is how I describe serialization: class (Eq a) => Packet a where unstuff :: P.FastString -> (Maybe a, P.FastString) stuff :: a -> P.FastString size :: a -> Int instance Packet Word8 where unstuff xs | P.null xs = (Nothing, xs) | otherwise = let (ys, zs) = P.splitAt 1 xs in (Just $ concatBits ys, zs) stuff a = P.packWords $ unpackBits a size a = 1 instance Packet Bool where unstuff xs | P.null xs = (Nothing, xs) | otherwise = (b, xs') where (a :: Maybe Word8, xs') = unstuff xs b = case a of Just a -> if a == 0 then Just False else Just True Nothing -> Nothing stuff True = stuff (1 :: Word8) stuff False = stuff (0 :: Word8) size a = 1 This is the foundation for properties, with the idea taken from WxHaskell and the Convertible twist added on top: infixr 0 := data Prop = forall a b. (Eq a, Eq b, Show a, Packet b, Convertible a b) => Attr a b := a deriving (Typeable) instance Show Prop where show (Attr name _ _ := x) = name ++ " := " ++ show x instance Eq Prop where (Attr name1 (todyn1, fromdyn1) _ := x1) == (Attr name2 (todyn2, fromdyn2) _ := x2) | name1 == name1 = case fromdyn1 $ todyn2 x2 of Just x2 -> x2 == x1 Nothing -> False | otherwise = False data Attr a b = Attr String (a -> Dynamic, Dynamic -> Maybe a) (a -> b, b -> a) instance Show (Attr a b) where show (Attr name _ _) = name makeAttr :: (Typeable a, Convertible a b) => String -> Attr a b makeAttr name = Attr name (toDyn, fromDynamic) (convert_AB, convert_BA) setprop :: Prop -> [Prop] -> [Prop] setprop _ [] = [] setprop (Attr name (todyn, fromdyn) _ := x) props = map setprop' props where setprop' prop@(attr@(Attr name' (todyn', fromdyn') _) := x') | name == name' = case fromdyn' $ todyn x of Just y -> attr := y Nothing -> prop | otherwise = prop mergeprops :: [Prop] -> [Prop] -> [Prop] mergeprops [] props = props mergeprops (x:xs) props = mergeprops xs (setprop x props) get :: Typeable a => Attr a b -> [Prop] -> IO a get a b = return $ getprop a b getprop :: Typeable a => Attr a b -> [Prop] -> a getprop attr props = case findprop attr props of Just x -> x Nothing -> error $ "Could not retrieve " ++ show attr ++ " from " ++ show props -- http://wagerlabs.com/

3 4

hs-plugins runtime loading issue
by Joel Reymont 27 Oct '05

27 Oct '05

Folks, I'm using hs-plugins to compile and load haskell code on Mac OSX. This works perfectly. Once I try this on Windows, though, I'm getting an error when it tries to load HSBase again. This happens when calling a function from within ghci. Any ideas? --- GHCi runtime linker: fatal error: I found a duplicate definition for symbol _GHCziWord_fromEnum1_closure whilst processing object file d ghc/ghc-6.4.1/HSbase1.o This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. -- Thanks, Joel -- http://wagerlabs.com/

2 2

RE: [Haskell-cafe] lockFile: fd out of range
by Simon Marlow 27 Oct '05

27 Oct '05

On 25 October 2005 17:02, Joel Reymont wrote: > Is there a set limit on the number of file descriptors that a Haskell > program can open? > > I'm using hs-plugins on FreeBSD to transparently compile, load and > launch scripts that establish a connection to a server. I'm getting > this error: > > internal error: lockFile: fd out of range > Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, > or http://www.sourceforge.net/projects/ghc/ lockFile uses FD_SETSIZE as its idea of the maximum value of a file descriptor. If you can get file descriptors outside this range, then the above error would ensue. Not sure if this is the case on FreeBSD... seems odd if it is. Can you try a truss/ktrace and see the values of your file descriptors? Cheers, Simon

2 1

RE: Instances That Ignore Type Constraints? (HList-related)
by Ralf Lammel 27 Oct '05

27 Oct '05

Yeah, I was also thinking of impredicative types and that they would make this problem go away. First of all, we may need to wait a while for such types to become available in Haskell, but Daan has good stuff at avail. Also, for clarity, let me just point out that this is really about an *interaction* of impredicativeness *and* type classes. Hence, I really think that an argument in favor of impredicative types is slightly overrated unless a Haskell approach to impredicativeness is fully conclusive for the type-class story. The following queries make it clear: Prelude> null [fromEnum] <interactive>:1:6: Ambiguous type variable `a' in the constraint: `Enum a' arising from use of `fromEnum' at <interactive>:1:6-13 Probable fix: add a type signature that fixes these type variable(s) Prelude> null [id] False More importantly, I need more input to fully endorse the appropriateness of impredicative types in this sort of context. That is, the question is ... what does it *mean* to wrap (or to box or to cartoon) an expression with non-escaping type variables that locally occur in type-class constraints? GHC/Haskell, as of today: - it means nothing; type error. Some sort of impredicative type: - it means universal quantification Potentially elsewhere: - it means existential quantification In Ghc with incoherent instances: - see above; except that the instance is actually selected. In addition to this scary diversity, all the three last choices are bogus in some sense because the quantified variables are totally inaccessible; so why would a type system honor such potentially accidental opaqueness. In summary, this makes me conclude that null [fromEnum] is just a really loose question to ask, which is perhaps just better rejected by a strong type system, no? Please, prove that I am wrong. :-) Ralf Oleg wrote: > When GHC does implement > MLF and start explicitly supporting impredicative types, the problem > would be fixed indeed... Currently, the only way to achieve the same > effect is to do this manually: > > newtype W = W (forall a. (Enum a) => a -> Int) > > *Main> null [W fromEnum] > False > > Perhaps indeed we should move to Cafe...

1 0