- Haskell-Cafe - Haskell.org

RE: [Haskell-cafe] Re: Non-technical Haskell question
by Simon Peyton-Jones 02 Dec '04

02 Dec '04

| I also have a very small start on a "haskell for hackers" ("hackers" in | the non-evil sense) sort of document. One this doesn't ignore I/O as | "hard" or "unimportant". I/O in Haskell doesn't suck. It's just that a | lot of people in the community don't have it as a high priority, I | think. As a shameless plug, have you tried "Tackling the awkward squad?". Indeed I/O in Haskell doesn't suck. http://research.microsoft.com/%7Esimonpj/papers/marktoberdorf Simon

2 1

Top-level state debate on the wiki
by Ben Rudiak-Gould 02 Dec '04

02 Dec '04

I put up a wiki page summarizing the main proposals for top-level mutable state. The type-dictionary approach isn't there yet, but there's a space for it; I'll probably fill it in within the next 24 hours unless someone else feels like doing it first. Please add more detail, objections, examples. Especially examples! Here's the page: http://haskell.org/hawiki/GlobalMutableState (It also includes an explanation of why I chose that title, though of course you're welcome to dispute that too.) -- Ben

6 10

memory leak in Random.randoms or makeList?
by S. Alexander Jacobson 01 Dec '04

01 Dec '04

Using ghci, I am getting this error message: *Main> timeOp $ print $ sizeFM bigFM' GHC's heap exhausted: current limit is 268435456 bytes; >From this code: makeList x = map ((\x->x `mod` range).abs) $ Random.randoms (Random.mkStdGen x)::[Int] range=100000 fmRecords' n = listToFM $ take n $ zip (makeList 100) (makeList 200) fmRecords n = listToFM $ take n $ zip [range..] [range..] fmSize=10^6 bigFM = fmRecords fmSize bigFM' = fmRecords' fmSize bigFM works fine so the leak is obviously within makeList. I just don't understand how makeList could produce this error... -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

Forcing type conversion - probably FAQ(?)
by Dusan Kolar 01 Dec '04

01 Dec '04

Hello, I'm trying to make work the following code (I'm using GHCi with flags -fglasgow-exts -fallow-undecidable-instances): infixl 6 :+, :- infixl 6 .+, .- data TMyExpr = TMyExpr :+ TMyExpr | TMyExpr :- TMyExpr | Val Int | Id String class MkExpr a b where (.+) :: a -> b -> TMyExpr (.-) :: a -> b -> TMyExpr instance MkExpr Int Int where (.+) a b = (Val a) :+ (Val b) (.-) a b = (Val a) :- (Val b) instance MkExpr Int TMyExpr where (.+) a b = (Val a) :+ b (.-) a b = (Val a) :- b instance MkExpr TMyExpr Int where (.+) a b = a :+ (Val b) (.-) a b = a :- (Val b) instance MkExpr TMyExpr TMyExpr where (.+) a b = a :+ b (.-) a b = a :- b It compiles fine, no problem. Nevertheless, writing (3::Int) .+ (4::Int) seems to me quite clumsy, but 3 .+ 4 does not work. :-( It says the 3 is from class Num and no variant is present for it, I know, it is not present, but how to force it to convert it to Int "automatically"? When I try to incorporate instance (Num a, Num b) => MkExpr a b where (.+) a b = (Val . round a) :+ (Val . round b) (.-) a b = (Val . round a) :- (Val . round b) the situation is even worse. :-( I tried several modifications, but they don't work either. :-\ I was trying to find the discussion (I wonder whether it went on the similar topic through the list recently), but failed. :-( If someone can just point me to any resource I could study the possible solutions - maybe I put wrong data to google. ;-) Or just to stop me, if I'm trying to do impossible... :-\ Thx, Dusan

2 1

Re: [Haskell-cafe] Re: ACIO versus Execution Contexts
by Adrian Hey 01 Dec '04

01 Dec '04

On Tuesday 30 Nov 2004 3:02 pm, Lennart Augustsson wrote: > I reiterate: not even device drivers written in C use TWIs. > (Well, at least not quality drivers. :)) A finite pool of N devices is still a unique resource. Ultimately you have to contain the problem locally with a modular solution, or all the unique state handle "buck passing" to higher levels (via who knows what intermediate modules) takes you all the way up to main. This is technically feasible, but highly un-modular and certainly not a desirable characteristic of any programming language (at least not one whose use I would advocate). Regards -- Adrian Hey

3 5

Rank-2 types and class constraints
by Stefan Holdermans 01 Dec '04

01 Dec '04

Hi, Just out of curiosity (I cannot come up with a practical example): Why doesn't the following piece of code type check in GHC (with extensions)? > foo :: (forall a . (Eq a) => a) -> Integer > foo = undefined It seems like the type-class constraint is playing a decisive rôle here, since the following does check. > bar :: (forall a . a) -> Integer > bar = undefined TIA, Stefan

2 1

Re: [Haskell-cafe] Re: ACIO versus Execution Contexts
by MR K P SCHUPKE 01 Dec '04

01 Dec '04

Actually I now think that not only are top level TWIs okay, I can get extra contexts by rewriting the MVar module. Here I can create a TWI in the new MVar module called context, and all mvar writes and reads would be parameterised by context. In this way I can change the context then call oneShot and get it to run a second (or as many times as I like)... So that gets round my last remaining objection to top level MVars. This also shows that top level TWIs and the Execution contexts are effectively the same thing... but I guess TWIs have a nicer syntax... Keean.

1 0

Re: ACIO versus Execution Contexts
by George Russell 01 Dec '04

01 Dec '04

Adrian wrote (snipped): > But if top level MVars are all that's on offer I'd settle for that :-) > I can still implement my "oneShot" examples just by passing the top > level MVar as an argument to oneShot rather than having it create its > own. I am not sure which the oneShot examples are, but I suspect you can implement them just as well using the execution contexts I have proposed. If you want to be sure your data will not be clobbered by other modules, simply wrap the state in special type, and make sure no-one else has access to that type. This requires no change to the Glasgow Haskell language at all, only a new library module. I suppose it may happen that you are worried about someone using withEmptyDict to create an inner execution context where everything starts from scratch, because you want to interface with broken C libraries which are stateful. However since this is a problem caused by broken C libraries rather than anything in Haskell, surely it would be better to support this by providing a global dictionary to be used in such exceptional cases, while leaving execution contexts the preferred tool in the Haskell world.

1 0

ACIO versus Execution Contexts
by George Russell 01 Dec '04

01 Dec '04

I think it would be nice to summarise the current state of play. This really needs to be a WiKi. Ian's ACIO proposal http://www.haskell.org//pipermail/haskell-cafe/2004-November/007680.html seems in fact to achieve much the same as the proposal I originally posted to http://www.haskell.org//pipermail/haskell/2004-November/014894.html and which Benjamin Franksen has explained and simplified here http://www.haskell.org//pipermail/haskell-cafe/2004-November/007691.html You can in fact do much the same with both. With Haskell 98, Data.Dynamic and ACIO and, if your implementation has concurrency at all, thread identifiers, I can implement execution contexts. On the other hand ACIO allows you to create variables with top-level declarations such as x <- newIORef 0 which can then be accessed in a pure way. With Execution Contexts you cannot do this; you would instead need a function getX :: IO (IORef Int) which would get the global variable x. In practice I don't think this distinction very important, since there's not much you could do with x except using the IO monad. Disadvantages of execution contexts ----------------------------------- 1. You are only allowed one value of each type in an execution context. Thus it is dangerous to try to use a global value of type (IORef Int); people would have to be advised to create a special newtype for each value. 2. They are likely to be less efficient than just allowing <- declarations at top level. Certainly they are in my implementation. The vast majority of this inefficiency can be eliminated by using hash tables, but you can't escape doing at least one hash-table lookup each time you want to access a global value. The bare minimum then would be one division by a constant followed by an indirection. 3. In a concurrent system, you also need forkIO to be modified, so that you can work out which execution context applies to you. Disadvantages of ACIO --------------------- 1. The ACIO proposal preserves one bad feature of unsafePerformIO, namely that you only have one "execution context". You cannot for example run two copies of the same program simultaneously, since they will clobber each other's global variables. 2. I don't know exactly how ACIO is to be implemented, but it looks as if at the least it requires an extension to the Haskell syntax. 3. I think that if the ACIO proposal were implemented, it would in any case be a good idea to implement execution contexts or something like them on top of it, so that people can create initialisation actions which do other things than the very strict subset allowed as ACIO actions. Questions --------- 1. Is there anything people would like to do with ACIO for which execution contexts would not be practical? 2. Which if either of the proposals would the gods responsible for implementing Haskell compilers favour?

6 9

RE: [Haskell-cafe] ACIO versus Execution Contexts
by Simon Peyton-Jones 01 Dec '04

01 Dec '04

| I think it would be nice to summarise the current state of play. This really | needs to be a WiKi. Thanks for the summary, George. | 2. Which if either of the proposals would the gods responsible for implementing | Haskell compilers favour? Rather than remain completely silent on this topic let me say that (a) I'm totally snowed under at the moment, at least partly with GHC stuff (Template Haskell, GADTs etc); (b) there has been so much traffic on this global variable topic that I've stopped reading it carefully. This isn't because I think it's unimportant or boring, but rather because I'm hoping that someone will eventually emit a summary that really does boil out the main issues, so that everyone else can benefit from the fruits of your (plural) labours. The idea would be that everyone else can just read the summary without reading the thread. A Wiki would be good. (c) I have the impression that there's still quite a bit of active discussion; convergence is not achieved (d) I'm not averse to changing GHC in some way, but big changes (e.g top level <-) would need a jolly persuasive argument and solid consensus. Smaller changes (e.g. a robust promise about top-level newMVars) are easier of course. (e) FWIW, as Simon has remarked, we're busy eliminating top-level global MVars from GHC. The really persuasive use I know for them is to implement semantically-pure but implementationally impure things like memo tables. Simon

2 1