- Haskell-Cafe - Haskell.org

Efficient Sets for Small Enumerations
by David F. Place 03 Apr '06

03 Apr '06

Often when writing algorithms which involve set operations on small enumerations, I start off using Data.Set. I soon find performance requires rewriting that code to use bitwise operations. I miss the nice interface of Data.Set and the type checking of using a proper data type. So, as an exercise in writing a library, I wrote out an implementation of bitwise set operations using the interface of Data.Set with a couple of extensions. It provides an abstract interface and type checking. Using GHC -O3, code compiles right down to the primitive bit-twiddling operators. My example program (a sudoku solver) runs several times faster. I'll be grateful for any feedback on this. Perhaps something like it would be useful included in the standard libraries. Cheers, David -------------------------------- David F. Place mailto:d@vidplace.com

3 6

Distributing monadic(?) functions across dyadic functions
by tpledger＠ihug.co.nz 03 Apr '06

03 Apr '06

Nils Anders Danielsson wrote: > A function like this has been suggested for the > standard libraries a couple of times before. > Someone suggested the name "on", which I quite > like: > > (*) `on` f = \x y -> f x * f y Thanks! I always wanted to be someone. :-) Here's the link. http://www.haskell.org//pipermail/haskell-cafe/2004-December/007917.html - Tom

1 0

RE: [Haskell-cafe] generics question, logical variables
by Ralf Lammel 03 Apr '06

03 Apr '06

Frederik, > As for your code example, it looks very interesting, but are you > saying that this could turn into an extension of the Data.Generics > library, or that this is something I could be implementing in terms of > what's already there? The posted code works with GHC 6.4 (SYB2) intentionally and actually. I have attached another attempt (again GHC 6.4, based on SYB2) which might be more useful for your purposes, and it may be useful in general, in fact. What I defined this time is a "certainty-improving" function: idify :: (Typeable1 f, Monad m, Data (a f), Data (a Id)) => (forall a. f a -> m a) -> a f -> m (a Id) That is, the function "idify get" takes a value whose type is parameterized in a type constructor f (such as Maybe or IORef), and the function attempts to establish Id instead of f on the basis of the function argument "get". > What is the 'a' parameter for in "force"? > > force :: ( Data (t Maybe a) > , Data (t Id a) > , Term t Maybe a > , Term t Id a > ) => t Maybe a -> t Id a The previous attempt was a more parameterized blow than required in your case. (I was guessing about what "typed logical variables" could mean. I was assuming that you would need some extra layer of embedding types on top of the Haskell term types. Looking at your code, this was not the case.) > For the part which I asked for help with, to get around my trouble > with generics, I defined a class GenFunctor and an example instance. > The intent is that generics should be able to provide this > functionality automatically later on, but you can see what the > functionality is. Let's look at the type of your GenFunctor: class GenFunctor f where gfmapM :: (Monad m, FunctorM b) => (forall x . a x -> m (b x)) -> f a -> m (f b) This type can be seen as a more relaxed version of the idify operation above. That is, idify fixes GenFunctor's b to Id. The particular encoding of idify (attached) takes advantage of this restriction. I wonder whether I should bother. (Exercise for reader :-)) > However, I am stuck on something else, the program doesn't typecheck > because of use of another function I defined, 'cast1'. Maybe you can > take a look. I had thought that I would be able to write a generic > 'unify' but I get the error: > > GenLogVar.hs:82:19: > Ambiguous type variable `a' in the constraint: > `Data a' arising from use of `cast1' at GenLogVar.hs:82:19-23 > Probable fix: add a type signature that fixes these type variable(s) > > This is because I need to do something special when I encounter a > "Var" variable in unification, but the compiler seems to not like the > fact that the type argument of the Var data type is not known. Please try to avoid new cast operations at all costs. :-) Your code can be arranged as follows: (i) Use extQ1 to dispatch to a special case for "Var x" for the first argument. (ii) In this special case, use again ext1Q to dispatch to a special case for "Var y" for the second argument. (iii) At this point, *cast* the variable value of *one* variable to the type of the other. So the problem with your code, as it stands, is that the target type of cast is ambiguous because you cast *both* arguments. The insight is to make the cast asymmetric. Then, not even polymorphism is in our way. Interesting stuff! Ralf

2 2

Haskell on Pocket PC?
by Dmitri O.Kondratiev 03 Apr '06

03 Apr '06

Any ideas on how much work needs to be done for using Haskell on PPC Windows Mobile platform? It would be interesting to use PPC as: 1) Haskell learning tool, so small code snipets could be entered and run directly on hand-held (REPL). How hard is it to port Hugs to PPC for this? Do any other (then Hugs) implementations exist that are easier to port? 2) Running on PPC Haskell applications cross-compiled on host PC. How much work must be done for GHC to support this? 3) There are several ways both for porting Haskell to PPC as well as cross-compiling Haskell code. Which one makes more sense to implement and will take less effort: a) Porting/compiling to VM byte code (Java, Parrot)? b) Porting/compiling to .NET CLR? c) Porting/compiling source code 4) And finally, do any projects already exist in this area? It would be great to get ideas how such port can be done in reasonable amount of time, in other words to find the most easy way to start with some Haskell implementation on PPC. Thanks for any info!

3 5

Breaking up long lines
by miketerrance 03 Apr '06

03 Apr '06

What is a good technique for breaking up long lines of code (for easier readability)? I have been inserting {- -} comments but there must be a better way. Something like \ in Python? Lycos email has 300 Megabytes of free storage... Get it now at mail.lycos.co.uk

4 3

Distributing monadic(?) functions across dyadic functions
by Jared Updike 03 Apr '06

03 Apr '06

Is there a common way (standard libs, higher order) to express the lambda part below? It's not particulary complicated but I think it is not higher-order enough > unionBy (\x y -> fst x == fst y) listOfPairs1 listOfPairs2 Something like "distribute fst (==)" where > distribute f op x y = f x `op` f y would leave > unionBy (distribute fst (==)) listOfPairs1 listOfPairs2 I imagine something involving Arrows and/or zip/curry/uncurry but I just can't see it. Is this a case of trying to make something more complicated than it is? Jared. -- http://www.updike.org/~jared/ reverse ")-:"

5 4

casting numerical types
by Matthias Fischmann 02 Apr '06

02 Apr '06

hi all, this should be a quick one (for now I would be happy with a "that's impossible", just want to make sure I don't miss anything). I want to compute the average from a list of arbitrary numerical element type. I wanted to do this: avg :: (Num a) => [a] -> a avg xs = sum (map fromNum xs) / (fromIntegral (length xs)) but it doesn't compile. All I could get to work is this: avg :: (Fractional a) => [a] -> a avg xs = sum xs / (fromIntegral (length xs)) avgI :: (Integral a) => [a] -> Float avgI = avg . map fromIntegral The two function names for the same thing are tolerable, but not very elegant. Is there another option? Thanks, Matthias

3 4

Parsec operator with letter problem
by Reto Kramer 31 Mar '06

31 Mar '06

I ran into the following problem with parsec's handling of operators. I hope someone on the list can show me a trick that resolve my current issue. At the end of this message is the full code for the reproducer. The language I'm parsing has infix operators of two forms. Some are special characters (e.g. a dot) and some are LaTeX like (e.g. \in). The letters that appear in the e.g. \in lead to problems with expression parsing. The following is what I expect: $ cat input1 a.b $ ./test input1 InfixExpr OP_Dot (Ident "a") (Ident "b") Good! Then I try (change the b to an n) $ cat input2 a.n $ ./test input2 Ident "a" OUTSCH! Changing the name of an identifier changed the expression! Then I try (add a space right after the dot) $ cat input3 a. n $ ./test input2 InfixExpr OP_Dot (Ident "a") (Ident "n") Good! What is going on? The 'n' is part of the "\in" operator (see reservedOpNames in test.hs program at the end of message) and confuses the parsec expression parser's ability to determine the end of expressions/identifiers. Adding a space right after the '.' operator resolves the issue, but that's not a suitable option for my users. Unfortunately I cannot remove the "\in" operator from the reservedOpNames list since otherwise "\in" is not recognized as an infix operator itself anymore. QUESTION: how can I get parsec's expression parser to work with infix operators of the form "\in"? Thanks, - Reto -- complete reproducer (test.hs) -- compile with: ghc -o test -package parsec test.hs module Main where import List (nub) import System (getArgs) import Text.ParserCombinators.Parsec import Text.ParserCombinators.Parsec.Expr import Text.ParserCombinators.Parsec.Language( emptyDef ) import qualified Text.ParserCombinators.Parsec.Token as P main :: IO () main = do{ args <- getArgs ; let fname = args !! 0 ; input <- readFile fname ; case parse spec fname input of Left err -> do{ putStr "parse error at " ; print err } Right x -> print x } data Op = OP_Dot | OP_In deriving (Show, Eq, Ord) data Expr = InfixExpr Op Expr Expr | Ident String | Number Integer deriving (Show, Eq, Ord) spec :: Parser Expr spec = do { whiteSpace ; e <- expression ; return e } expression :: Parser Expr expression = buildExpressionParser table basicExpr <?> "expression" op_infix :: Op -> Expr -> Expr -> Expr op_infix op a b = InfixExpr op a b table :: OperatorTable Char () Expr table = [ [binary "." (op_infix OP_Dot) AssocLeft] , [binary "\\in" (op_infix OP_In) AssocLeft] ] binary name fun assoc = Infix (do{ reservedOp name; return fun }) assoc basicExpr :: Parser Expr basicExpr = choice [ do{ i <- identifier ; return $ Ident i } ] lexer = P.makeTokenParser testdef testdef = emptyDef { P.identStart = letter <|> char '_' , P.identLetter = alphaNum <|> char '_' , P.opStart = oneOf $ nub $ map (\s -> head s) $ P.reservedOpNames testdef , P.opLetter = oneOf (concat (P.reservedOpNames testdef)) , P.reservedOpNames = [ ".", "\\in" ] } dot = P.dot lexer parens = P.parens lexer braces = P.braces lexer squares = P.squares lexer semiSep = P.semiSep lexer semiSep1 = P.semiSep1 lexer commaSep = P.commaSep lexer commaSep1 = P.commaSep1 lexer brackets = P.brackets lexer whiteSpace = P.whiteSpace lexer symbol = P.symbol lexer identifier = P.identifier lexer reserved = P.reserved lexer reservedOp = P.reservedOp lexer integer = P.integer lexer natural = P.natural lexer charLiteral = P.charLiteral lexer stringLiteral = P.stringLiteral lexer

2 3

haskell-mode indentation
by Kirill Kuvaldin 31 Mar '06

31 Mar '06

Hello there. Being an emacs-addicted person, I'm using haskell-mode for editing haskell code. But its default indentation rule doesn't seem to be correct. I mean when i type something like the code below, i've got the following indentation: doSomeStuff a b c = do somefunc a anotherfunc b onemorefunc c Whereas the correct indentation (in my opinion) is as follows: doSomeStuff a b c = do somefunc a anotherfunc b onemorefunc c Thus I need hitting TAB key 2 or 3 times to make indentation as mentioned above. Cheers, Kirill

2 1

Haskell's market
by Arnaud Bailly 31 Mar '06

31 Mar '06

Hello haskellers, I have been following this list's debates for a while and I am very enthusiastic about functional programming in general and haskell in particular. I am on the verge of starting a new sofware development project for a customer and I wonder whether or not Haskell would be the right tool to do the job. The project is a Point-of-sale distributed management system with the following (non-exhaustive) list of features : - rich GUI clients (on windows platform) to allow optimizing users input speed. There will about 50-60 'screens' and half as many 'reports', - local database with possibility to replicate and aggregate data, - central repository for aggregated data, aggregation should be synchronous but may fail due to poor network connectivity, - ease of deployment/update for new versions or modules, - secured (authenticated and encrypted) communications between nodes, - ... All in all, this project is quite typical of a small to medium sized business information system which is commonplace in software services. There are no stringent performance requirements nor extraordinary functional features or tricky algorithms, but the allocated time-frame (and money :-)) is quite small and I would like to optimize design and coding time to concentrate on user acceptance, deployment and testing issues. Java and object-oriented 'paradigm' is nearly hardwired in my brain so I expect quite a painful learning process to shift towards thinking in functional terms: I know quite well the theory but never did I put it to use on a significant scale. More profoundly, I am asking myself whether this investment will be really worthwhile for this kind of software. I have read with joy and amazement S.P.Jones "Composing contracts: an adventure in financial engineering" and P.Hudak's "An experiment in software prototyping productivity", but I have also followed the discussions with J.Reymont about its poker server tester and read "Haskell vs. Erlang, Reloaded". I am not asking anyone to 'sell' me Haskell, that would be like selling ice to a penguin as I am already convinced Haskell is really interesting in itself. And I am willing to do some investment in time and money to use Haskell at the expense of another simpler but less elegant solution (read Java :-)). I would be very happy to have some feedback about these issues, regards, -- Arnaud Bailly, Dr. - Ingénieur de Recherche NORSYS 1, rue de la Cense des Raines ZAC du Moulin 59710 ENNEVELIN Tel : (33) 3 28 76 56 76 Mob : (33) 6 17 12 19 78 Fax : (33) 3 28 76 57 00 Web : http://www.norsys.fr

6 8