September 2006 - Haskell-Cafe

Re: Curious Functor Class
by Ashley Yakeley 27 Sep '06

27 Sep '06

Jeremy Gibbons wrote: > I haven't assimilated the forall here, but datatypes with only one shape > of data have been called "Naperian" by Peter Hancock (because they > support a notion of logarithm), and they're instances of McBride and > Paterson's "idioms" or "applicative functors". > > http://sneezy.cs.nott.ac.uk/containers/blog/?p=14 > http://www.cs.nott.ac.uk/~ctm/Idiom.pdf > > As for uses: Bruno Oliveira and I claim an application via The Essence > of the Iterator Pattern: > > > http://www.comlab.ox.ac.uk/jeremy.gibbons/publications/index.html#iterator Perhaps the key is that there exist types P and Q s.t. there's an isomorphism F a <=> (P -> a,Q) This seems to be intuitively Napierian: ln (P -> a,Q) = (P,ln a) | ln Q I can believe that Hoistables are in fact Idioms, though I know there are Idioms that are not Hoistables (Maybe and Either, for instance). (Also I think "Idiom" is a better class name than "Applicative".) -- Ashley Yakeley Seattle WA

1 1

Re: [Haskell] Re: compiler-independent core libraries infrastructure
by Neil Mitchell 27 Sep '06

27 Sep '06

[Moving to cafe for follow up discussions] Hi Bulat, So, just to confirm in my mind what you are proposing: Compiler/Version specific Core: Yhc.Core, Hugs.Core, GHC.Core .... With a different version for each compiler version. Tied intimately to the compiler. The leveler: Core - which abstracts each version/variant of *.Core into one big pile. Contains versions of STM/Arrays in Pure Haskell which might not give the expected performance, but at least keep the semantics as best they can. Base: Pure Haskell which depends on Core, but NOT on *.Core. (Then after you split up base - useful, but personally not of massive importance to me ;) ) I think this is a great plan! Now you have a concrete idea of what you want to achieve in the end, how are you going to get there? It seems a rather ambitious project. Perhaps you might be best suited by getting base to compile with Cabal (and maybe even natively on Windows - without MingW), then you can go from there to the splitting in a Cabal friendly manner without hacking through makefiles? Anyway, once you have decided what you want, I'm sure the Yhc team will do their best to help you get to where you want with regards to that specific compiler. Just to try and keep your work more generally applicable, it would be nice if you kept the Hat project in the back of your mind, so that this work can be reused by them to get full haskell.org libraries. Thanks Neil

3 2

Creating DLLs with GHC
by Jason Dagit 27 Sep '06

27 Sep '06

On 9/27/06, SevenThunders <mattcbro(a)earthlink.net> wrote: > Does cabal really work on windows? I've never had a problem with cabal on windows. I use it instead of makefiles and I'm reasonably happy with it. > Although it's installed I notice that > when I try to build my library using it, it dies on the first foreign import > statement in the first .hs source it tries to compile. It is reminiscent of > trying to import a foreign C module directly ghci. ghc.exe, on the other > hand has no problem with it. Perhaps your .cabal file is not correct or your cabal version is too old? It's very hard to say without detailed error messages and a clear description of what you're doing (with sample code). > Does this scheme address the problem of being unable to link external C > libraries (a DLL) into the Haskell DLL? Are there any other workarounds > here? I only create a DLL from haskell and link that in a C++ application. I haven't tried the other way. Probably over the next month or so the DLL I'm creating in Haskell will need to access an existing DLL. Hopefully this will work fine. > Is it possible to create static link libraries compatible with MS > VC++? Ultimately I'm trying to link my C code with Matlab. The C code stub > will then call a bunch of Haskell routines. I have no idea. I'm fairly new to using Haskell in windows. Jason

2 1

Duplicate Instance problem
by Jason Dagit 27 Sep '06

27 Sep '06

Hello, I tried to create a type class for making instances of Show display a custom way. After using my class for a while I found that sometimes RealFloats would display as 'NaN' and this is unacceptable. So at this point I had something like: {-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances #-} class Show a => StringValue a where -- | Convert a showable value to a string toString :: a -> String instance Num a => StringValue a where toString = show and I added an instance for RealFloat: instance RealFloat a => StringValue a where toString x | isNaN x = "" -- as an example | otherwise = show x Now, I get the error: Duplicate instance declarations: instance [overlap ok] (Num a) => StringValue a -- Defined at ... instance [overlap ok] (RealFloat a) => StringValue a -- Defined at ... I've also tried spliting Num into an instance for Integral and RealFloat but that doesn't work either (same error). For now I'm using an instance for RealFloat and an instance for Int and Integer (which are identical) and that seems to be okay but suboptimal. Why does the error say they are duplicates? I would have expected something about them overlapping but not duplicates. Is there a way to still do this without duplicates? Thanks, Jason

1 0

Getting the latest
by Lyle Kopnicky 27 Sep '06

27 Sep '06

Hi folks, I am running GHC 6.4.1 on my Linux box at work, which is the latest packaged version for Ubuntu Dapper Drake. (They have a 6.4.2 package for Edgy, but I don't know how to install that. The Synaptic Package Manager seems to only want to install packages specifically labeled for Dapper Drake.) I tried downloading the latest binary snapshot. But when I try to unpack the archive, bzip2 tells me it's a bad archive. So, I downloaded the latest source version. That unpacked just fine, and I'm currently building it. My question is, when I do 'make install', will it just overwrite the version (6.4.1) I already have? Or will they go in separate places? I have no idea how it decides where to go. Right now ghc 6.4.1 is in /usr/local/bin/ghc. After I 'make install', will it be ghc 6.5? I don't want to screw up the installed package so it can't be updated later. Thanks, Lyle

2 2

Re: [Haskell-cafe] Optimizing a title matcher
by Lyle Kopnicky 27 Sep '06

27 Sep '06

Hi folks, It turns out Haskell is vindicated. It's my algorithm that was slow. As Robert Dockins pointed out, the double nested loop is just going to take a long time. As evidence, it turns out my C++ version is just as slow as the Haskell version. So, I'm going to go back to Haskell, but be more selective about which titles from the reference table I choose to match against, for any given import title. Thanks, Lyle

2 2

Computing lazy and strict list operations at the same time
by C Rodrigues 27 Sep '06

27 Sep '06

Here's a puzzle I haven't been able to solve. Is it possible to write the initlast function? There are functions "init" and "last" that take constant stack space and traverse the list at most once. You can think of traversing the list as deconstructing all the (:) [] constructors in list. init (x:xs) = init' x xs where init' x (y:ys) = x:init' y ys init' _ [] = [] last (x:xs) = last' x xs where last' _ (y:ys) = last' y ys last' x [] = x Now, is there a way to write initlast :: [a] -> ([a], a) that returns the result of init and the result of last, takes constant stack space, and traverses the list only once? Calling reverse traverses the list again. I couldn't think of a way to do it, but I couldn't figure out why it would be impossible.

10 14

Re: [Haskell-cafe] Unable to profile program using Data.ByteString.Lazy
by dons＠cse.unsw.edu.au 27 Sep '06

27 Sep '06

lists: > Donald Bruce Stewart wrote: > >Probably you didn't build fps with profiling as well? You can rebuild > >fps with: > > runhaskell Setup.hs configure -p > >as the first step. > > > That worked on my Windows box at home, but on my Linux box at work, I > got "unrecognized flag -p". You're cabal version is too old then. Try updating either Cabal or GHC. -- Don

4 4

Re: Creating DLLs with GHC
by Cyril Schmidt 27 Sep '06

27 Sep '06

Matthew, As regards the symbols that end with _closure, I believe you can resolve them by adding -package parsec to the ghc command line (as far as I can see, all the symbols you list come from the parsec package). I don't know, though, what to do with the undefined symbols from matrixstack. You can try to check two things: 1) That the options you specify with -optl really reach the linker (e.g. try to give a non-existent library in -optl option and see if it complains). 2) That matrixstack.lib is understood by the linker (that is, it must be created with dlltool) 3) That the symbols it is looking for do exist in matrixstack.lib (you can check it with objdump, for instance). Cheers, Cyril ___ Matthew Bromberg wrote: >ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o >src1_stub.o src2.o -optl-lmatrixstack -optl-L"." >My external C library is in matrixstack.dll and it has a corresponding >static link stub library matrixstack.lib in the same directory as all >the sources. It has references in one of the sources (say src1.hs). >Unfortunately I get a host of undefined references to basically all the >functions in matrixstack.dll and also some undefined references of the form >Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to >`TextziParserCombinatorsziParsecziError_show_closure'

1 0

Re: [Haskell] MR details (was: Implicit type of numeric constants)
by Bernie Pope 27 Sep '06

27 Sep '06

On 23/09/2006, at 4:33 AM, Christian Sievers wrote: > Hello, > > I don't take my advice to go to haskell-cafe :-) I will take your advice :) > > The discussion continued outside the mailing list, and now I have > two questions myself: > > 1. Why do the rules of the monomorphism restriction explicitly mention > *simple* pattern bindings? > Where is the difference, especially as there is a translation to > simple pattern bindings? > Why should > > p | "a"=="b" = 2 > | otherwise = 3 > > be treated different than > > p = if "a"=="b" then 2 else 3 They are the same (both are simple pattern bindings). The report says in section 4.4.3.2 that the first can be translated into the second. A simple pattern binding is one where the lhs is a variable only. If a pattern binding is not simple, it must have a data constructor on the lhs, therefore it cannot be overloaded. So the (dreaded) MR only applies to simple pattern bindings. Cheers, Bernie.

3 5