- Haskell-Cafe - Haskell.org

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

not possible with monad transformers ?
by Pavel Zolnikov 01 Dec '04

01 Dec '04

Hi, I have been playing with Maybe and Output monad transformers and realized that I cannot make the following work nicely: > foo a b = do > output "before" > r <- (liftM2(+)) a b > when r == Nothing $ output "error" > return r As soon as computation produces Nothing, I am loosing ability to do any output. I think what I need is not wrapping one monad into another with transformer; I need some sort of monad combiner: > newtype MC m1 m2 = MC (m1 a, m2 b) So I could execute both of monads ‘in parallel’. But I have no idea how to express this or even if this is doable at all. Any comments? Thanks, Pavel. P.S. Here is summary of what I tried with transformers so far: Let’s say I have following monad transformers: > newtype MaybeMonadT m a = MMT (m a) > newtype OuptutMonadT m o a = OMT (m a, o) And I am trying to use following monads: > type M1 a = MaybeMonadT OutputM a > type M2 a = OuptutMonadT Maybe String a Now, they both won’t quite work in the following example: > foo a b = do > output "before" > r <- (liftM2(+)) a b > when r == Nothing $ output "error" > return r In case of M1, as soon as I get Nothing in r, computation will stop and return without any output gathered. In case of M2, as soon as I get Nothing in r, computation will stop and return only with output gathered so far. That is > output "error" will never be called.

7 11

Re: [Haskell-cafe] Equality of functions
by oleg＠pobox.com 01 Dec '04

01 Dec '04

Jules Bean wrote: > From the point of view of a programmer, that's all there is to it: > there is no way of proving two functions are the same except by > exhaustively checking every input. That is too pessimistic, I'm afraid. There is also an intensional equality. Granted, it can be sound but never, in general, complete (although it can be total). That is, if the comparison function returns True, then the arguments truly denote the same, identically the same function. If the answer is False, well, we don't know. The arguments may still denote the same function. Here's one example of intensional comparison: > import Foreign > > comp a b = > do > pa <- newStablePtr a > pb <- newStablePtr b > let res = pa == pb > freeStablePtr pa > freeStablePtr pb > return res *FD> comp id id >>= print True *FD> comp undefined id >>= print False *FD> comp undefined undefined >>= print True This function lives in the IO monad, where it should stay because it destroys free theorems. It is quite equivalent to Scheme's eq? predicate. For some -- wide -- classes of functions, it is possible to define a pure functional intensional comparison. For example, a recent message http://www.haskell.org/pipermail/haskell/2004-November/014939.html demonstrated the reconstruction of (even compiled) numerical functions. So, one can define intensional equality of two numeric functions as structural equality of their reconstructed representations. Alas, this comparison function can't be total: bottom is beyond comparison.

2 1

Equality of functions
by Adam Zachary Wyner 01 Dec '04

01 Dec '04

Hi All, After some weeks of experimenting and digging around, I understand that functions cannot be compared for equality. Thanks to Bjorn Lisper for pointing this out. I basically understand (?) the underlying mathematical issue, which is that functions in general may have infinite domains and ranges. For example, a function f, which gives the successor of an integer, x + 1, could not be compared to a function g, which gives the predecessor of an integer which has 2 added, (x + 2) - 1, even though these two functions give exactly the same result on all arguments, because we would have to compare them on all possible values for x. Question -- is this all there is to the issue, or is there something more? Apologies in advance for not understanding the math better here. Question -- though Haskell, as a lazy language, does not otherwise have problems with infinite lists, why does it here? Question -- is there some way around this problem? It is very handy to be able to have a variable over functions and then compare the value to a designated function. This would let me say things like: when variableFunctionX == functionA then.... otherwise etc... One possible (dirty?) solution I thought up is to use the record types of Hugs to correlate the function with a name of type String: type FunctionNameFunction = Rec (functionName :: String, functionFunction :: WhateverFunction) Then, whenever one needs to use the function, one uses the value of functionFunction, but whenever one needs to evaluate for identity, one uses the value of functionName, using just string identity. Of course, this makes lots of things less 'pretty' (to apply a function to an argument, one has to first 'pull out' the function from the record), but it addresses a general problem. One would also have to keep careful track of which functionNames correlate with with functionFunctions. Other suggestions? Cheers, Adam

6 6