May 2013 - Haskell-Cafe

Re: [Haskell-cafe] using a win32 dll
by Kees Bleijenberg 29 May '13

29 May '13

Thank you Krzystof! This did the trick. Now I also have a better understanding what is going on. Great. Kees Van: Krzysztof Skrzętnicki [mailto:gtener@gmail.com] Verzonden: woensdag 29 mei 2013 11:58 Aan: Kees Bleijenberg Onderwerp: Re: [Haskell-cafe] using a win32 dll Oh, I didn't mean kernel32. And -L provides search path not the actual library. The idea was to use -l<yourLibrary.dll> , so it would be -lpngDLL.dll, provided it is in library search path. If not use -Ldirectory-with-dll -lpngDLL.dll On Wed, May 29, 2013 at 11:49 AM, Kees Bleijenberg <k.bleijenberg(a)lijbrandt.nl> wrote: I’ve tried to compile it with –l kernel32, but nothing changed. I’ve also tried -LpngDll.dll but that didn’t work either. Kees My first guess would be missing -l parameter. The examples you have linked read: ghc --make compname.hs -lkernel32 Best regards, Krzysztof Skrzętnicki On Wed, May 29, 2013 at 9:13 AM, Kees Bleijenberg <k.bleijenberg(a)lijbrandt.nl> wrote: I made a Delphi dll (32 bits windows). This dll exports a function named getPngVersion. This is a function with no arguments that returns a pointer to a array of chars. If I examine the dll with a tools like tdump, I can see the function getPngVersion on index 1. Now I want to use this dll in Haskell: {-# LANGUAGE ForeignFunctionInterface #-} module Main( main ) where import Control.Monad import Foreign.C import Foreign.Marshal.Alloc import Foreign.Marshal.Array import System.Win32.Types foreign import stdcall "glasPng getPngVersion" getPngDllVersion :: IO CString main :: IO () main = do s <- getPngDllVersion putStrLn (show s) Compiling this with ghc --make glasPng.hs gives: GlasPng.o: fake: (.text +0x82): undefined reference to ‘getPngVersion@0’ collect2 : Id returned 1 exit status I wonder what went wrong. In the foreign import line I use “glasPng…. “ to tell ghc, it has to searh in glasPng.dll (changing glasPng to glasPng.dll doesn’t help). I’ve changed the name of the function in the dll to getPngVersion@0 but no luck. I’ve read and tested the last example at http://stackoverflow.com/questions/1027246/haskell-foreign-import-stdcall-o… (win32_getComputername, this works!). I wonder how haskell knows which dll to use in this example?) Probably I’am doing something wrong with the way I tell ghc which dll to link or…. Any ideas? Kees _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Install wx on Windows XP
by Eric Wong 29 May '13

29 May '13

Hi Haskellers, I'm trying to install wxHaskell on Windows XP. I have already installed Haskell Platform 2012.04.0.0, MinGW and wxWidgets. When I try to install wx, I got the following error when cabal is installing wxcore: $ cabal install wx Resolving dependencies... [1 of 1] Compiling Main ( C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\wxcore- 0.90.0.3-896\wxcore-0.90.0.3\Setup.hs, C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\wxcore -0.90.0.3-896\wxcore-0.90.0.3\dist\setup\Main.o ) Linking C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\wxcore-0.90.0.3-896\wxcore-0.90.0.3\d ist\setup\setup.exe ... Configuring wxcore-0.90.0.3... Generating class type definitions from .h files generating: src/haskell/Graphics/UI/WXCore/WxcClassTypes.hs reading class definitions: parsing: C:\Documents/include/wxc.h wxdirect: C:\Documents/include/wxc.h: openFile: does not exist (No such file or directory) Generating class info definitions generating: src/haskell/Graphics/UI/WXCore/WxcClassInfo.hs reading class definitions: parsing: C:\Documents/include/wxc.h wxdirect: C:\Documents/include/wxc.h: openFile: does not exist (No such file or directory) Generating class method definitions from .h files parsing: Data\cabal\wxc-0.90.0.4\ghc-7.4.2\include/wxc.h wxdirect: Data\cabal\wxc-0.90.0.4\ghc-7.4.2\include/wxc.h: openFile: does not ex ist (No such file or directory) Building wxcore-0.90.0.3... Preprocessing library wxcore-0.90.0.3... src\haskell\Graphics\UI\WXCore\WxcClassTypes.hs:1:1: File name does not match module name: Saw: `Main' Expected: `Graphics.UI.WXCore.WxcClassTypes' cabal.exe: Error: some packages failed to install: wx-0.90.0.1 depends on wxcore-0.90.0.3 which failed to install. wxcore-0.90.0.3 failed during the building phase. The exception was: ExitFailure 1 It looks like it's confused by the spaces in the path and can't find the wxc.h file. I tried to configure cabal to install all user packages into a simpler directory. But cabal always install to the C:\Documents and Settings\Administrator\Application Data\cabal directory no matter how I change the config file there. Anyone knows how to fix this problem or change cabal directory on Windows? Thanks. p.s. I'm using the user Administrator.

3 2

Re: [Haskell-cafe] using a win32 dll
by Robert Jakob 29 May '13

29 May '13

On Wed, 29 May 2013 09:13:09 +0200 "Kees Bleijenberg" <k.bleijenberg(a)lijbrandt.nl> wrote: > I made a Delphi dll (32 bits windows). This dll exports a function > named getPngVersion. This is a function with no arguments that > returns a pointer to a array of chars. Did you annotate the exported function with stdcall? The calling conventions of Delphi are different to that of C. I had problems with that sometimes (not with Haskell, but with C) R.

2 1

Re: [Haskell-cafe] using a win32 dll
by Krzysztof Skrzętnicki 29 May '13

29 May '13

My first guess would be missing -l parameter. The examples you have linked read: ghc --make compname.hs -lkernel32 Best regards, Krzysztof Skrzętnicki On Wed, May 29, 2013 at 9:13 AM, Kees Bleijenberg < k.bleijenberg(a)lijbrandt.nl> wrote: > I made a Delphi dll (32 bits windows). This dll exports a function named > getPngVersion. This is a function with no arguments that returns a pointer > to a array of chars.**** > > If I examine the dll with a tools like tdump, I can see the function > getPngVersion on index 1.**** > > Now I want to use this dll in Haskell:**** > > ** ** > > {-# LANGUAGE ForeignFunctionInterface #-}**** > > module Main(**** > > main**** > > )**** > > ** ** > > where**** > > import Control.Monad**** > > import Foreign.C**** > > import Foreign.Marshal.Alloc**** > > import Foreign.Marshal.Array**** > > import System.Win32.Types**** > > ** ** > > foreign import stdcall "glasPng getPngVersion" getPngDllVersion :: IO > CString**** > > ** ** > > main :: IO ()**** > > main = do **** > > s <- getPngDllVersion**** > > putStrLn (show s)**** > > ** ** > > Compiling this with ghc --make glasPng.hs gives:**** > > GlasPng.o: fake: (.text +0x82): undefined reference to ‘getPngVersion@0’ > collect2 : Id returned 1 exit status **** > > ** ** > > I wonder what went wrong. In the foreign import line I use “glasPng…. “ to > tell ghc, it has to searh in glasPng.dll (changing glasPng to glasPng.dll > doesn’t help). I’ve changed the name of the function in the dll to > getPngVersion@0 but no luck. I’ve read and tested the last example at > http://stackoverflow.com/questions/1027246/haskell-foreign-import-stdcall-o… > (win32_getComputername, this works!). I wonder how haskell knows which > dll to use in this example?)**** > > Probably I’am doing something wrong with the way I tell ghc which dll to > link or….**** > > ** ** > > Any ideas?**** > > ** ** > > Kees**** > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

using a win32 dll
by Kees Bleijenberg 29 May '13

29 May '13

I made a Delphi dll (32 bits windows). This dll exports a function named getPngVersion. This is a function with no arguments that returns a pointer to a array of chars. If I examine the dll with a tools like tdump, I can see the function getPngVersion on index 1. Now I want to use this dll in Haskell: {-# LANGUAGE ForeignFunctionInterface #-} module Main( main ) where import Control.Monad import Foreign.C import Foreign.Marshal.Alloc import Foreign.Marshal.Array import System.Win32.Types foreign import stdcall "glasPng getPngVersion" getPngDllVersion :: IO CString main :: IO () main = do s <- getPngDllVersion putStrLn (show s) Compiling this with ghc --make glasPng.hs gives: GlasPng.o: fake: (.text +0x82): undefined reference to 'getPngVersion@0' collect2 : Id returned 1 exit status I wonder what went wrong. In the foreign import line I use "glasPng.. " to tell ghc, it has to searh in glasPng.dll (changing glasPng to glasPng.dll doesn't help). I've changed the name of the function in the dll to getPngVersion@0 but no luck. I've read and tested the last example at http://stackoverflow.com/questions/1027246/haskell-foreign-import-stdcall-on -dll-function (win32_getComputername, this works!). I wonder how haskell knows which dll to use in this example?) Probably I'am doing something wrong with the way I tell ghc which dll to link or.. Any ideas? Kees

1 0

Lista dos aprovados em concurso Rodrigues Alves
by Edson 29 May '13

29 May '13

Lista dos aprovados em concurso Rodrigues Alves: Novo São Joaquim: ANA ANGELICA PEREIRA ALVES, LETICIA BAIRLE, FRANCISCO ANDERSON VALE DO NASCIMENTO, PAULO DE SIQUEIRA SILVA, JOÃO CARLOS MOREIRA DE CARVALHO, DAMIANA PEREIRA DE OLIVERIA, MARIA DO SOCORRO DE ALBURQUERQUE ARRUDA BARBOSA, JAIME CUSTODIO DA SILVA FILHO. SEBASTIANA MÁRCIA GOMES DE MELO, ÉRICA FRANCISCA BATISTA DE MELO, MAYRES RAQUEL DA SILVA PINHEIRO, JUCIMARA VICENTE DOS SANTOS, WEULLER TEIXEIRA DE MAGALHAES. Governador Nunes Freire. Rodrigues Alves, ADISSON SOUZA TAVARES, JULIO CESAR DA SILVA MOURA FILHO, ERIDAN FERREIRA LEITE, MICHAEL LIMA SILVA, JOÃO CARLOS MOREIRA DE CARVALHO, CARLOS EDNAELTON DE MELO FERREIRA, MANOEL MARQUES DA CUNHA FILHO, IEDA BENTO BARROSO. ROBERTO FERREIRA LOPES FILHO, DOMINGOS SAVIO VIDAL DE LIMA FILHO, MARIANA ISABEL E SILVA, JOSE ALDER BRAGA JUNIOR, THAYS RAQUEL DA SILVA. Brás Pires. Morpará e ANNA JESSYCA ANDRADE LACERDA, LUCAS DE PAULA OLIVEIRA, GEORGE FACUNDO RICARDO, RAFAEL WESLEY MENESES MAIA, JOÃO CARLOS MOREIRA DE CARVALHO, DEBORAH LIMA BRAGA, MARIA MARIANA RIBEIRO VIEIRA, JOÃO VICTOR RODRIGUES DE C. MEDEIROS. TATIANA RODRIGUES DE CASTRO MELO, CAIO URBANO CAMURCA, MAIARA FRANKLIN DE AZEVEDO, IAGO TELES GARCIA, RITA PAULA SEVERO PATU. Hidrolândia.

1 0

Re: [Haskell-cafe] Hackage Update Brigade
by wren ng thornton 29 May '13

29 May '13

On 5/27/13 5:29 PM, Alexander Solla wrote: > As per recent discussions, I'm making a list of volunteers who are willing > to pick up some slack in Hackage package maintenance, so that we can submit > an amendment to the Haskell Prime Committee's ticket 113 ( > http://hackage.haskell.org/trac/haskell-prime/ticket/113) I'd much prefer sticking with the names (<*>), (<*), (*>), and deprecating `ap` and (>>). There's no good name for (<*) since we already have (<<) = flip (>>) which means something different entirely. Plus "`ap`" is longer than "<*>" and loses the suggestive relationship between the operator names. Not to mention the fact that these name changes would cause immense breakage for all users of Applicative, rather than relatively minor breakage for those who define Monad instances. -- Live well, ~wren

1 0

Hackage Update Brigade
by Alexander Solla 29 May '13

29 May '13

As per recent discussions, I'm making a list of volunteers who are willing to pick up some slack in Hackage package maintenance, so that we can submit an amendment to the Haskell Prime Committee's ticket 113 ( http://hackage.haskell.org/trac/haskell-prime/ticket/113) I think that showing that people are willing to pick up missing package maintainer's slack will alleviate the concern of breaking lots of code by refactoring the monad/applicative/functor hierarchy. Code will be broken, but publicly available packages can be fixed by the community during a "staging" period. To that end, I have made a Google Form to collect some volunteer information. If you are interested in helping, please visit: https://docs.google.com/forms/d/1o4B8CEE_42u9f-sgmu2t5iSEvm0cq6-um6g_fHJt6G…

5 6

Design of extremely usable programming language libraries
by Andrey Chudnov 29 May '13

29 May '13

Dear Cafe, I'm exploring the design space of programming language libraries with enhanced usability and I'd your help and comments. I'll start with a few short questions, but offer a detailed discussion of the motivations and the problems I'm facing below. So, if you have interest in the subject or feel you can offer some insight, please, do read on. * Does any generic traversal/transformation (uniplate-style) library support GADTs? * What is the best choice, performance- and memory-wise, for a parser combinator library with support for arbitrary look-ahead? Parsec is considered slow by some [1], but is it only in comparison with attoparsec (which, unfortunately, doesn't support arbitrary look-ahead)? Is there any parser library that performs better than Parsec while still supporting arbitrary look-ahead. * Any multi-mode pretty printer libraries? By multi-mode I mean writing code once and being able to generate, say, both "pretty" and "minified" text representations of a program by changing just one parameter. Also, what's the most efficient pretty-printing library nowadays? Blaze? I've been using Haskell for quite a while now, primarily, for programming-language applications: program analysis, transformation and compilation. I'm sure many would agree that PL work is where Haskell shines. In the recent years new language features and libraries --namely, GADTs, Template Haskell, quasi-quotation and generic programming--- have appeared that could make working with languages even easier than before. That's why it's sad to see that none of the PL libraries seem to make good use of these features (however, I might be starting to understand why). So, I'm currently exploring the design space for a library that uses these advanced Haskell features for delivering better usability, and I'm having problems with implementing some of them. I welcome comments on both the motivations, overall design and the more technical aspects. I've omitted a few details because it's a long e-mail as is. If something is not clear or doesn't make sense, please, let me know. I'll start by listing the features that an "ideal" PL library should have, and that I've come to cherish as both a heavy user and a developer of such. The basic features (pretty much every library has them) include a parser (text->AST (abstract syntax tree)) and a pretty-printer (AST->text), as well as a Haskell representation of the AST that is somewhat easy to use. Pretty much every library has that --- although some might debate the ease of use of the AST representations. However, there are other features that, in my opinion, are essential to a PL library. The features are motivated by three requirements: static safety (as few run-time errors as possible), minimal code duplication (DRY) and ease of use and inspection of the code. 1) the pretty-printer should be multi-mode. One should be able to write code once and be able to generate different textual representations of the AST: - the "pretty" which is nice to the eye with white spaces, indentations etc. - minified, with minimum white space (while still being valid) - debuggable which inserts comments based on AST annotations - source-map generation - being able to generate colored LaTeX/HTML code would be nice, but non-essential 2) ASTs should be statically safe: you should only be able construct values that represent valid programs, or get a typechecker/compiler error otherwise. Languages that have syntactic productions that can appear in one context but not in another need GADTs with type witnesses to achieve that. In fact, such languages are often used to motivate GADTs in the first place [2]. And while the problem in [2] could have been solved by splitting the Expr datatype into two (IntExpr and BoolExpr), in some languages this can't be done (or produces awkward syntax trees). 3) a quasi-quoter with support for anti-quotation and quoted patterns. This also saves a lot of typing *and* makes your code less error-prone and easier to read. What is better (to both write and read)? > [js|#x# = (function (a, b) {return {t1: a + b, t2: a*b};})(#x#, #y#);|] or > ExprStmt def $ AssignExpr def x (CallExpr def (FuncExpr def Nothing > [Id def "a", Id def "b"] $ ReturnStmt def $ ObjectLit [(PropId def $ > Id def "t1", InfixExpr def OpAdd (VarRef def $ Id def "a") (VarRef def $ > Id def "b")), PropId def $ > Id def "t2", InfixExpr def OpMul (VarRef def $ Id def "a") (VarRef def $ > Id def "b")])) [x, y] The caveat here is that, to help ensure correctness, the quasi-quoter and the parser should share code as much code as possible. Ideally, there should be just one parser that has a switch for recognizing normal and quasi-quoted programs. However, that would require adding additional constructors representing anti-quotations to our AST. And with that the user might be able to generate invalid AST's and cause a run-time error. The solution to the last problem is to statically constrain all the values that are passed to, say, the pretty-printer so that they are guaranteed to be free of anti-quotes (see an example definition below). However, that, again, requires GADTs (e.g. have all the AST datatypes have an extra type parameter). > data EType = Complete | HasHoles > type family Quoted a b :: * > canHaveHolesT :: a -> b -> Quoted a b > canHaveHolesT _ _ = undefined > type instance Quoted HasHoles Complete = HasHoles > type instance Quoted Complete HasHoles = HasHoles > type instance Quoted HasHoles HasHoles = HasHoles > type instance Quoted Complete Complete = HasHoles > data Expr t where > EInt :: Int -> Expr Complete > EAdd :: Expr t1 -> Expr c2 -> Expr (Holes t1 t2) > ... > EQuote :: String -> Expr HasHoles And then we could have a normal parser return a value 'Expr Complete' and a quasi-quotation parser retunr a value 'Expr HasHoles'. Similarly, the pretty printer function could have type 'Expr Complete -> Doc'. 4) We should be able to annotate ASTs with arbitrary values, and change the types of those values as we go. The most user friendly way, IMO, is to have the AST datatypes be polymorphic and have that type parameter as an extra field in every constructor. E.g., > data Expr t a where > EInt :: a -> Int -> Expr Complete a > EAdd :: a -> Expr t1 a -> Expr c2 a -> Expr (Holes t1 t2) a > ... > EQuote :: a -> String -> Expr HasHoles a Then we can use the functions in Traverseable to change types of annotations, and inspect the values by pattern-matching on constructors. 5) support for generic operations on syntax trees. Uniplate, which has been designed to work with ASTs, and is awesome for that purpose because it saves a lot of time. I use transform(Bi) and universe(Bi) all the time and it saves *a lot* of typing. Pretty much all my analysis/transformation code uses those four small-but-powerful function calls -- and, dare I say, it's quite elegant. Other useful, but not crucial features include: 1) diffs for ASTs (in the spirit of the 'gdiff' library, which, alas, doesn't work with polymorphic datatypes) 2) QuickCheck arbitrary instances for ASTs. No technical difficulty there, but writing instances that generate interesting programs and don't run out of memory is quite hard :) I wish 'Agata' was still supported, or there was some library that helps writing Arbitrary instances for ASTs. If you think there's another feature in mind that is missing from the list, please, let me know. The (perceived) challenges in implementing the functionality outlined above are as follows: 1) No multi-mode pretty-printing library. I think that the mutli-mode functionality could be implemented on top of an existing library by definining new combinators, but it would be nice to have a library that supports them out of the box. The particular features that I'm missing are: - "non-essential space/(soft-)line break" combinators that are interpreted as spaces/line-breaks in the "pretty" mode and as empty docs in the "minified" mode. - "comment" combinator which inserts the text in a comment only if the "debug" mode is on - being able to record the positions of AST nodes in the resulting text (for generating source maps). Not sure what would be a convenient interface for that. Note: I know that mainland-pretty has position information, but I don't think it's helpful for generating source maps. 2) The biggest problem is that there are two good reasons to use GADTs when specifying AST datatypes. However, uniplate doesn't work with GADTs and, as far as I know, no currently supported generic programming library does (to be precise, I need support for families of mutually recursive polymorphic GADTs). Am I missing some library, or is my understanding correct? If it's the latter, is there any fundamental limitation that prevents creating such a library? Maybe there are other (but still elegant) ways to satisfy my requirements without using GADTs? 3) 'gdiff' doesn't support polymorphic datatypes. Is there any other library that does? [1] http://www.serpentine.com/blog/2010/03/03/whats-in-a-parsing-library-1/ [2] http://en.wikibooks.org/wiki/Haskell/GADT PS: My attempts so far are in https://github.com/achudnov/language-nextgen/blob/master/Language/Nextgen/S… Regards, Andrey Chudnov

3 4

Type classes
by Johannes Gerer 28 May '13

28 May '13

Dear Haskellers, While trying to understand the interconnection and hierarchy behind the important typeclasses, I stumbled upon the following question that I am not able to answer: There seems to be a hierachy of the type classes, in the sense, that the more powerfull a class is, the more fleixblility you have for combining them to complex programs. (Functor -> Applicative -> Arrow[Choice,Plus,Apply,..] -> Monad). It was nice to read in the Typeclassopedia, that ArrowApply and Monad are equivalent, which is shown by deriving two instances from each other: instance Monad m => ArrowApply (Kleisli m) instance ArrowApply a => Monad (a anyType) The logic seems to be, that if I can derive from every instance of class A an instance of class B, then A is more powerfull than B and (in general) it is easier to be of class B than of class A (e.g. more types can be made Applicatives, than Monads) So far, I think I can follow. But what really hit me was the Cokleisli type. Using it and the logic from above, I can show that ANY type class is more (or equally) powerfull than the Monad: instance AnyClass m => Monad (Cokleilsi m anyType) I know this makes no sense, but where is the fallacy? Why even bother with the above derivation, if any type class can be made into a monad? I can see, that the Monad instance from above does not really transform the type "a", but instead simply fix its first argument. But then on the other hand, the ArrowApply Instance does transform the "m" type (in a way similar to Cokleisli). If attention needs to be paid to the details, then what are they and why did they not matter above? Thanks, Johannes

3 10