October 2010 - Haskell-Cafe

PatternSignatures (rant)
by Johannes Waldmann 06 Apr '18

06 Apr '18

Dear all, (this is a rant - please ignore) why has "PatternSignatures" been renamed to "ScopedTypeVariables" (in ghc-6.10)? show me the alleged "type variable" in this code: do x :: Int <- [ 1 .. 10 ] ; return $ x^2 and why on earth do I need to use a language extension at all to get to the most basic thing of declarative programming: to declare the type of an identifier? This seriously hurts (me, at least) when teaching Haskell. Thanks - J.W.

4 4

Commutative monads vs Applicative functors
by Ronald Guida 09 Jul '16

09 Jul '16

I have a few questions about commutative monads and applicative functors. >From what I have read about applicative functors, they are weaker than monads because with a monad, I can use the results of a computation to select between alternative future computations and their side effects, whereas with an applicative functor, I can only select between the results of computations, while the structure of those computations and their side effects are fixed in advance. But then there are commutative monads. I'm not exactly sure what a commutative monad is, but my understanding is that in a commutative monad the order of side effects does not matter. This leads me to wonder, are commutative monads still stronger than applicative functors, or are they equivalent? And by the way, what exactly is a commutative monad?

6 6

ANNOUNCE: ioctl 0.0.1
by Maciej Piechotka 13 Sep '15

13 Sep '15

A package for type-safe I/O control. Currently only ioctl is supported. Currently simply a extract from my tuntap fork TODO: - Return the integer as well as structure (will break the API) - Port for Windows Network.Socket.IOCtl (as soon as I manage to setup some sane environment on this platform) - Wrapping around DeviceIoControl Example (in hsc): data NotRead = NotRead instance NotRead Int where ioctlReq _ = #const FIONREAD notRead s = ioctlsocket' s NotRead Regards

2 1

Proposal: TypeDirectedNameResolution
by Johannes Waldmann 03 Mar '13

03 Mar '13

While browsing Haskell-Prime I found this: http://hackage.haskell.org/trac/haskell-prime/wiki/TypeDirectedNameResoluti… This is not some April Fool's day hoax? Because, it might actually turn Haskell into a somewhat usable (and marketable) language ... well, you know what I mean. Is there 'ghc -XTypeDirectedNameResolution' yet? - J.W.

23 35

Could not find module `Text.Regex'
by zaxis 16 Sep '12

16 Sep '12

import Text.Regex date_by_ntday dateStr ntday = do let [y,m,d] = map (\x -> read x::Int) $ splitRegex (mkRegex "-") dateStr .... %ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 Which package(s) do i need to use Text.Regex ? Sincerely! ----- fac n = foldr (*) 1 [1..n] -- View this message in context: http://old.nabble.com/Could-not-find-module-%60Text.Regex%27-tp27366745p273… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 5

Fundeps and overlapping instances
by Simon Peyton-Jones 09 Jun '12

09 Jun '12

Oleg points out, and Martin also mentions, that functional dependencies appear to interact OK with overlapping instances, but type families do not. I this impression is mistaken, and I'll try to explain why in this message, in the hope of exposing any flaws in my reasoning. We can't permit overlap for type families because it is unsound to do so (ie you can break "well typed programs don't go wrong"). But if it's unsound for type families, it would not be surprising if it was unsound for fundeps too. (I don't think anyone has done a soundness proof for fundeps + local constraints + overlapping instances, have they?) And indeed I think it is. So the short summary of this message is: if it works for fundeps it works for type families, and vice versa. (NB this equivalence is not true about GHC's current implementation, however. GHC doesn't support the combination of fundeps and local constraints at all.) Such an equivalence doesn't argue against fundeps; I'm only suggesting the that the two really are very closely equivalent. I much prefer type families from a programming-style point of view, but that's a subjective opinion. Simon Imagine a system "FDL" that has functional dependencies and local type constraints. The big deal about this is that you get to exploit type equalities in *given* constraints. Consider Oleg's example, cut down a bit: class C a b | a -> b instance C Int Bool newtype N2 a = N2 (forall b. C a b => b) t2 :: N2 Int t2 = N2 True We end up type-checking (True :: forall b. C Int b => b). From the functional dependency we know that (b~Bool), so the function should typecheck. GHC rejects this program; FDL would not. But making use of these extra equalities in "given" constraints is quite tricky. To see why look first at Example 1: module X where class C a b | a -> b data T a where MkT :: C a b => b -> T a module M1 where import X instance C Int Char where ... f :: Char -> T Int f c = MkT c module M2 where import X instance C Int Bool g :: T Int -> Bool g (MkT x) = x module Bad where import M1 import M2 bad :: Char -> Bool bad = g . f This program is unsound: it lets you cast an Int to a Bool; result is a seg-fault. You may say that the problem is the inconsistent functional dependencies in M1 and M2. But GHC won't spot that. For type families, to avoid this we "eagerly" check for conflicts in type-family instances. In this case the conflict would be reported when compiling module Bad, because that is the first time when both instances are visible together. So any FDL system should also make this eager check for conflicts. What about overlap? Here's Example 2: {-# LANGUAGE IncoherentInstances #-} module Bad where import X -- Overlapping instances instance C Int Bool -- Instance 1 instance C a [a] -- Instance 2 f :: Char -> T Int f c = MkT c -- Uses Instance 1 g :: T a -> a g (MkT x) = x -- Uses Instance 2 bad :: Char -> Int bad = g . f Again, a seg fault if it typechecks. But will it? When typechecking 'g', we get a constraint (C a ?), where 'a' is a skolem constant. Without IncoherentInstances GHC would reject the program on the grounds that it does not know what instance to choose. But *with* IncoherentInstances it would probably go through, which is unsound. So IncoherentInstances has moved from causing varying dynamic behaviour to causing seg faults. Very well, so FDL must get rid of IncoherentInstances altogether, at least for classes that have functional dependencies (or that have superclasses that do). But at the moment GHC makes an exception for *existentials*. Consider Example 3: class C a b | a -> b -- Overlapping instances instance C Int Bool -- Instance 1 instance C a [a] -- Instance 2 data T where MkT :: C a b => a -> b -> T f :: Bool -> T f x = MkT (3::Int) x -- Uses Instance 1 g :: T -> T g (MkT n x) = MkT n (reverse x) -- Uses Instance 2 bad :: Bool -> T bad = g . f In the pattern match for MkT in g we have the constraint (C a b), where 'a' is existentially bound. So under GHC's current rules it'll choose the (C a [a]) instance, and conclude that (b ~ [a]). So it's ok to reverse x. But it isn't; see function bad! So to avoid unsoundness we must not choose a particular instance from an overlapping set unless we know, absolutely positively, that the other cases cannot match. (GHC's exception for existentials was introduced in response to user demand. Usually, overlapping instances are somehow semantically coherent, and with an existential we are *never* going to learn more about the instantiating type, so choosing the best available seems like a good thing to do.) But even nuking IncoherentInstances altogether is not enough. Consider this variant of Example 3, call it Example 4: module M where class C a b | a -> b instance C a [a] -- Instance 2 data T where MkT :: C a b => a -> b -> T g :: T -> T g (MkT n x) = MkT n (reverse x) -- Uses Instance 2 module Bad where import M instance C Int Bool -- Instance 1 f :: Bool -> T f x = MkT (3::Int) x -- Uses Instance 1 bad :: Bool -> T bad = g . f This is nasty. In module M we have only one instance declaration for C, so there's no overlap, and function g typechecks fine. Now module Bad adds an overlapping instance declaration and 'f' uses it; moreover, it's clear that the new instance declaration is the right one to use. It's not clear how to fix this. The only way I can think of is to insist that all the instances appear in a single module, so that you cannot add more "later". But that loses part of the point of overlap in the first place, namely to provide a generic instance and then later override it. So FDL must * embody eager checking for inconsistent instances, across modules * never resolve overlap until only a unique instance can possibly match * put all overlapping instances in a single module Type families already implement the first of these. I believe that if we added the second and third, then overlap of type families would be fine. (I may live to eat my words here.) I'd be interested to know what Chameleon does on these examples.

6 18

ANNOUNCE: HaskellDB 2.0: Scrap your SQL strings
by Justin Bailey 22 Feb '12

22 Feb '12

What is it? ======== The HaskellDB library lets you generate SQL queries without writing any actual SQL. Unlike other query generating libraries, you choose the abstraction level. Queries can be built out of independent fragments, just like your programs. Leave hand-written, string-based, SQL libraries behind and check out HaskellDB. Where to get it? ============ You can get it from Hackage (http://hackage.haskell.org/package/haskelldb) or by using cabal (cabal install haskelldb). You also need drivers for your specific database. HaskellDB currently supports the HDBC family of drivers. First, download haskelldb-hdbc (http://hackage.haskell.org/package/haskelldb-hdbc) then get the appropriate package for your database: * ODBC: haskelldb-hdbc-odbc (http://hackage.haskell.org/package/haskelldb-hdbc-odbc) * Postgres: haskelldb-hdbc-postgresql (http://hackage.haskell.org/package/haskelldb-hdbc-postgresql) * Sqllite: haskelldb-hdbc-sqlite3 (http://hackage.haskell.org/package/haskelldb-hdbc-sqlite3) Documentation, Mailing List, Source, etc ======================= Go to http://trac.haskell.org/haskelldb for detailed information. What's New? ========= * New query capabilities: stored procedures, CASTs, query parameters, constants, and more. * Postgres SQL improvements. * Bug fixes around AND and OR associativity. * Query optimization improvements around aggregate expressions. * More tests. Details ===== Back in June 2009, Bjorn Bringert passed maintainership of HaskellDB to me. I've been working this summer to get a release out, which included: * Adding an examples/ directory to the source distribution. * Archiving and consolidating information to http://trac.haskell.org/haskelldb. * Accepting patches for various issues. I have used a lot of ORM & SQL-wrapper libraries during my career and HaskellDB is the first that I've found which does not require you to eventually break the abstraction. Learning to use the the library was a fun challenge but not one that many people are willing to take, when they can easily write SQL by hand. If the library was easier to get started with, I think it would be much more widely used. Help me get HaskellDB better documentation! If you are using HaskellDB and want to help: go to http://trac.haskell.org/haskelldb and write an article, write a blog post, get in touch with me, etc. When I saw that Rails 3.0 uses the "ARel" gem (based on the relational algebra) I groaned - Haskell has had that forever! We need to get the word out! Why 2.0? -------------- Last year Brian Bloniarz contributed an awesome patch which replaced HaskellDB's home-grown record system with the HList library by Oleg Kiselyov (and colleagues). I intended to work with the library for awhile and get a 1.0 release out. Unfortunately, HList proved too daunting for GHC and for me. Compile times went way up, and I could not isolate it enough to give GHC HQ a repro case. Even worse, HList required too many Oleg units for me to comprehend. I could usually fix compile errors, but found myself struggling to extend HaskellDB's functionality. In the end I felt I needed to back the patch out. I really hated to lose some of the functionality but in the end maintainability won out. At that point I had pushed a few patches with a v1.0 cabal file, so I thought it best to make this release 2.0. Who am I? --------------- I started using HaskellDB in early 2009. I use it more as a query-generating library than for executing SQL statements. I have written a largish system for generating a data-access layer in PHP from query descriptions in HaskellDB. Yes, I'm using Haskell to write PHP ... dirty! Unmaintained & Unrelated Packages ----------------------------------------------------- A couple of haskelldb related packages on Hackage are not maintained by me: * haskelldb-hdbc-mysql - This project was created and uploaded independent of me. Contact the author for specifics. However, the haskelldb-hdbc-odbc library is maintained by me and can be used to talk to MySQL. * HSQL (haskelldb-hsql, etc) - I cannot get this backend to compile on my platform. HSQL seems unmaintained so I have let the drivers decay. You'll notice I have not uploaded new packages or changed their version dependencies. * haskelldb-flat and haskelldb-dynamic - Both of these packages have suffered serious bitrot and are not maintained any longer.

5 7

Cannot understand liftM2
by Nicola Paolucci 13 Feb '12

13 Feb '12

Hi All, I'm loving learning Haskell quite a bit. It is stretching my brain but in a delightfull way. I've googled, I've hoogled but I haven't found a clear explanation for what exactly liftM2 does in the context below. Using the cool lambdabot "pointless" utility I found out that: > \x -> snd(x) - fst(x) is the same as: > liftM2 (-) snd fst I like the elegance of this but I cannot reconcile it with its type. I can't understand it. I check the signature of liftM2 and I get: Prelude> :t liftM2 Prelude> liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r Can someone help me understand what's happening here ? What does a Monad have to do with a simple subtraction ? What is actually the "m" of my example ? I am sure if I get this I'll be another step closer to illumination ... Thanks, Nick

15 18

Parsing workflow
by Nils Schweinsberg 21 Jan '12

21 Jan '12

Hi! I'm having a really hard time to write a correct parser for a small language I've developed. I have been trying to write a parser using parsec, but always get a lot of error messages like "unexpected "\n", expected ..., new-line or..." when trying to run the parser. Then I read about the happy parser and really liked the separation of lexing the text into tokens and parsing the actual logic behind those tokens. Since I couldn't get familiar with the lexer "alex" I gave up on the alex-happy-approach again and went back to parsec. But with that lexer->parser idea on my mind, my parser currently looks a lot like a lexer. So I came up with the idea of using a combination of parsec and happy, where I generate a list of tokens for my text via parsec and analyse it with happy. My questions would be: - Is this a valid approach? - What is your workflow on parsing complex data structures? - What about performance? Since my project is going to be an interpreted language parsing performance might be interesting aswell. I've read that happy is in general faster than parsec, but what if I combine both of them as I said above? I guess that parsing a simple list of tokens without any nested parser structures would be pretty fast? - Do you have any other ideas on how to improve my parser? - What are your general thoughts on happy vs. parsec? Thanks for any replies, Nils

10 17

Hexpat: Lazy I/O problem with huge input files
by Aleksandar Dimitrov 10 Dec '11

10 Dec '11

Hello Haskell Cafe, I really hope this is the right list for this sort of question. I've bugged the folks in #haskell, they say go here, so I'm turning to you. I want to use Hexpat to read in some humongous XML files (linguistic corpora,) since it's the only Haskell XML library (I could find) that takes ByteStrings as input. I stumbled on a problem when using one of the examples from the docs of Text.XML.Expat.Tree. The "cookbook recipe" there suggests *first* processing the data, and only then looking into the parser error to see if there has been an error. I understand this should prevent the parse tree from being fully evaluated before use. Unfortunately, that is not what happens on my system (ghc 6.12.1, if that's of importance.) This is the code from the docs, that I modified to read files: > import Text.XML.Expat.Tree > import System.Environment (getArgs) > import Control.Monad (liftM) > import qualified Data.ByteString.Lazy as C >· > -- This is the recommended way to handle errors in lazy parses > main = do > f <- liftM head getArgs >>= C.readFile > let (tree, mError) = parse defaultParseOptions f > print (tree :: UNode String) >· > -- Note: We check the error _after_ we have finished our processing > -- on the tree. > case mError of > Just err -> putStrLn $ "It failed : "++show err > Nothing -> putStrLn "Success!" Given a 42M test file, an invocation like this: % ghc --make -O2 Hexpat.hs % ./Hexpat input.xml > dump.xml will gobble up some 2Gigs of RAM (at least. I usually kill it before it starts thrashing the swap space, since that almost crashes my entire machine.) If I remove the last 3 lines: > import Text.XML.Expat.Tree > import System.Environment (getArgs) > import Control.Monad (liftM) > import qualified Data.ByteString.Lazy as C > > main = do > f <- liftM head getArgs >>= C.readFile > let (tree, mError) = parse defaultParseOptions f > print (tree :: UNode String) the same invocation and input file barely uses a megabyte or two of RAM and finishes really quickly. Why is that? Is this a mistake in the Hexpat docs, or am I doing something wrong? Lazy IO has always been a little bit of a mystery to me, and just when I thought I had it... Thanks for any help on the matter! Aleks

3 3