- Haskell-Cafe - Haskell.org

Conflicting bindings legal?!
by Andreas Abel 27 Feb '13

27 Feb '13

To your amusement, I found the following in the Agda source: abstractToConcreteCtx :: ToConcrete a c => Precedence -> a -> TCM c abstractToConcreteCtx ctx x = do scope <- getScope let scope' = scope { scopePrecedence = ctx } return $ abstractToConcrete (makeEnv scope') x where scope = (currentScope defaultEnv) { scopePrecedence = ctx } I am surprised this is a legal form of shadowing. To understand which definition of 'scope' shadows the other, I have to consult the formal definition of Haskell. But I studied computer science to *not* become a lawyer!! -- Andreas Abel <>< Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich Oettingenstr. 67, D-80538 Munich, GERMANY andreas.abel(a)ifi.lmu.de http://www2.tcs.ifi.lmu.de/~abel/

3 4

Running out of space while concatinating a list of bytestring
by C K Kashyap 27 Feb '13

27 Feb '13

Hi, I have the following code - It looks like things go okay until concatination is attempted. I get the following output There are 2258 ByteStrings *** Exception: <stdout>: hPutBuf: resource exhausted (Not enough space) I am thinking that I should do strict concatination at each point in the support function - how can I go about doing so? (BS is the lazy.char8 bytestring) connectionGetNBytes :: NC.Connection -> Int -> IO ByteString connectionGetNBytes c n = do bs <- connectionGetNBytes' c n putStrLn ("There are " ++ (show (length bs)) ++ " ByteStrings") return (BS.concat bs) connectionGetNBytes' :: NC.Connection -> Int -> IO [ByteString] connectionGetNBytes' _ 0 = return [] connectionGetNBytes' c n = do l <- NC.connectionGet c n let ll = BS.length l remaining <- connectionGetNBytes' c (n - ll) return (l:crlfStr:remaining) Regards, Kashyap

1 1

Help to write type-level function
by oleg＠okmij.org 27 Feb '13

27 Feb '13

Dmitry Kulagin wrote: > I try to implement typed C-like structures in my little dsl. HList essentially had those http://code.haskell.org/HList/ > I was unable to implement required type function: > type family Find (s :: Symbol) (xs :: [(Symbol,Ty)]) :: Ty > Which just finds a type in a associative list. HList also implemented records with named fields. Indeed, you need a type-level lookup in an associative list, and for that you need type equality. (The ordinary List.lookup has the Eq constraint, doesn't it?) Type equality can be implemented with type functions, right now. http://okmij.org/ftp/Haskell/typeEQ.html#TTypeable (That page also defined a type-level list membership function).

2 1

tplot (out of memory)
by Manish Trivedi 27 Feb '13

27 Feb '13

Hi, I am running into a weird out of memory issue. While running timeplot over an input file having ~800 rows. From below provided info, seems like machine has enough ram (1849MB). Please let me know if anyone has pointers. * # free -m * total used free shared buffers cached Mem: 3825 1975 1849 0 13 71 -/+ buffers/cache: 1891 1934 Swap: 4031 111 3920 *#time tplot -o out.png -or 1024x768 -k 'CurrentPerHour' 'lines' -k 'RequiredPerHour' 'lines' -if adgroup_delivery_chart.input -tf 'date %Y-%m-%d %H:%M:%OS' * tplot: user error (out of memory) real 0m0.026s user 0m0.018s sys 0m0.008s -Manish

5 7

GHC API wiki update
by satvik chauhan 27 Feb '13

27 Feb '13

I was playing with the GHC api and found that examples on the GHC wiki don't seem to work with GHC 7.6.1. Does anybody have the updated examples of the same? Regards, Satvik

1 0

derivatives and integrals
by Christopher Howard 27 Feb '13

27 Feb '13

Hi. The scope of this question is likely bigger that Haskell, but this seems like the right crowd to ask. I'm in Calc II right now, and I'm looking for a FOSS desktop application (I use Gnu/Linux) to replace the functionality of my TI-98 in finding derivatives and integrals. (It's very convenient for double checking my own solutions.) I've heard of some software like Octave, but the manuals are usually very large, and I'm not sure what is the best one to start with. I was wondering if there is anyone on this list who uses free software to do that sort of simpler Calc stuff, and what it is that they use. -- frigidcode.com

2 1

package dependencies should distinguish between API and implementation?
by Johannes Waldmann 27 Feb '13

27 Feb '13

Package dependencies are modelled by a relation "A depends-on B". Shouldn't this in fact be two relations: API-depends-on and implementation-depends-on? (meaning that A API-depends-on B iff some type of B is visible to the user of A) So what we currently have is implementation-depends-on and API-depends-on is a sub-relation of that. The point being the following: assume * A implementation-depends-on B.1 * not (A API-depends-on B.1), * U implementation-depends-on A * U implementation-depends-on B >= 2 Then U (indirectly) implementation-depends on two versions of B but it should still be safe? (e.g., I can install B.3, re-compile U, but keep A) Example: A = template-haskell, B = containers (at least I don't see any mention of Data.Map/Set in th's API, I think the only dependency is in the implementation of PprM http://hackage.haskell.org/packages/archive/template-haskell/2.8.0.0/doc/ht… ) or in general, A (and B.1) are baked into ghc, but there is some B.2/B.3 out there which U wants to use. Or is this what already happens? (ghc would notice that B.1.foo is different from B.2.foo. cabal-install would warn, but proceed? Then the effect of the proposal would just be to switch off these warnings in some cases?) - J.W.

3 3

Thunks and GHC pessimisation
by oleg＠okmij.org 26 Feb '13

26 Feb '13

Tom Ellis wrote: > To avoid retaining a large lazy data structure in memory it is useful to > hide it behind a function call. Below, "many" is used twice. It is hidden > behind a function call so it can be garbage collected between uses. As you discovered, it is quite challenging to ``go against the grain'' and force recomputation. GHC is quite good at avoiding recomputation. This is a trade-off, of time vs space. For large search tree, it is space that is a premium, and laziness and similar strategies are exactly the wrong trade-off. The solution (which I've seen in some of the internal library code) is to confuse GHC with extra functions: http://okmij.org/ftp/Haskell/misc.html#memo-off So, eventually it is possible to force recomputation. But the solution leaves a poor taste -- fighting a compiler is never a good idea. So, this is a bug of sort -- not the bug of GHC, but of lazy evaluation. Lazy evaluation is not the best evaluation strategy. It is a trade-off, which suits a large class of problems and punishes another large class of problems.

2 1

Parser left recursion
by Martin Drautzburg 26 Feb '13

26 Feb '13

Hello all, this was previously asked on haskell-beginners, but only partially answered. As an exercise I am writing a parser roughly following the expamples in Graham Hutton's book. The language contains things like: data Exp = Lit Int -- literal integer | Plus Exp Exp My naive parser enters an infinite recursion, when I try to parse "1+2". I do understand why: "hmm, this expression could be a plus, but then it must start with an expression, lets check". and it tries to parse expression again and again considers Plus. Twan van Laarhoven told me that: > Left-recursion is always a problem for recursive-descend parsers. and suggested to do something like: > parseExp = do > lit <- parseLit > pluses <- many (parsePlusToken *> parseLit) > return (combinePlusesWithLit lit pluses) > > combinePlusesWithLit = foldr Plus -- or foldl This indeed does the trick, but only when the first token is a Lit (literal integer). I then added the possibility to optionally put things in parentheses. But then I cannot parse "(1+2)+3". The original code fails, because "(1+2)" is not a Lit and when I allow an expression as the first argument to "+" I get infinite recursion again. I am generally confused, that saying "a plus expression is an integer followed by many "plus somethings" is not what the language says. So this requires a lot of "paying attention" to get right. I'd much rather say "a plus expression is two expressions with a '+' in between". I do know for sure, that it is possible to parse "(1+2)+3" (ghci does it just fine). But I seem to be missing a trick. Can anyone shed some light on this? -- Martin

9 24

Status of GHC type-nats branch
by Takayuki Muranushi 26 Feb '13

26 Feb '13

Hi, everyone, In order to merge two type-level key-value pairs (More specifically, to use TypeNats branch of unittyped: https://bitbucket.org/xnyhps/haskell-unittyped/commits/all/tip/branch%28%22… ) I'd like to use overlapping type families and the type level Naturals at the same time. However, I couldn't build the type-nats branch of ghc, as I've been trying this week. I could build that in late 2012, so maybe this is due to updates in the git submodules. Do you reproduce this? Is there anyone else trying to build the type-nats branch? Any advice is helpful, including negative ones, if it's temporally broken or no more supported. And, I'm particularly glad if anyone has a x86-64 linux tarball of type-nats branch, and share it with me :) Best regards, -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html

2 2