May 2006 - Haskell-Cafe

Re: [Haskell] (.) . (.)
by Brian Hulley 28 May '06

28 May '06

[moved to cafe] Robert Dockins wrote: > On Sunday 28 May 2006 05:02 pm, Brian Hulley wrote: >> I see my error was that I was reversing the args in eta expansion, >> so the correct derivation is: > > FYI, eta-expansions isn't valid in Haskell. Its safe in this > derivation, but it isn't always. Am I right in thinking that this is because of _|_ ? In any case I suppose I should have instead just replaced the function with it's definition like you (view Lambda Shell) and Christophe did. Also, is your Lambda Shell publicly available? (I had a quick look on the wiki in the Theorem provers section but couldn't find a link.) Thanks, Brian.

2 2

Re: [Haskell-cafe] Linking to third party libraries in windows
by Matthew Bromberg 28 May '06

28 May '06

That's an interesting statement that bears further scrutiny. I've been viewing monads as a kind of encapsulation in a quasi-hidden world state. Yes a monad is a function that would give you an output if you had access to the input world. That is the picture drawn in Simon Peyton Jones' tutorial. I've been thinking of actions in terms of the functions x -> IO(a), but Simon calls these IO actions and calls monads actions as you do. Is it your claim that whenever an 'IO action' is performed on something like IO (x) with x <- newListArray a l that the newListArray function will be called ? So with the old paradigm, where Rmatrix was stored as (Int, Int, IO(StorableArry Int CDouble)). A typical matrix operation, that calls out to a BLAS C routine cside_effect() looks something like this under the old scheme matfunc A = (u,v, arr) where u = f1 (getrows A) (getcols B) v = f2 (getrows A) (getcols B) arr = do arrA <- getarr A withStorableArray arrA (\vara -> cside_effect vara ) return arrA Now when one uses this code do A <- getAfromSomewhere fA = matfunc A B <- anotherfunc A fA has been changed by the cside_effect function, but A has not! Is it your contention that the array in A is essentially copied or created anew for every getarr A call? I think getarr A looked something like getarr (Rmatrix (r,c,arr)) = arr in the old technique, but now looks like getarr (Rmatrix (r,c,arr)) = return arr Is this perhaps an effect of lazy evaluation? When does one actually need to evaluate the constructor for the storable array contained in A? Hmmm. Is it that the rules specify that an IO action forces the evaluation of the value in the monad, but otherwise this value may be unevaluated? So return x doesn't evaluate x but (return x) >>= \z -> IOfunc z does? This would actually make sense in the end. The IO action of A <- getAfromSomewhere would not evaluate the monad that is the third element of the tuple A, since there is no real 'need' to do so. So in fact no constructor of A's array would ever get evaluated until a function was applied to it, which would have to be in the form of an IO action. That's a nice mind twister. Clean's uniqueness types are a little easier to grasp I think. Ahh I think I understand now. It has to work that way or else you cannot guarantee the sequential execution property of monads. Thus if y :: IO (a) and you evaluate z <- func (f1 y) (f2 y), the evaluation order of y is controlled by what is implemented in func (and f1 and f2), not by evaluation rules for arguments. The value wrapped in y MUST remain unevaluated until IO 'actions' are performed on it. Brian Hulley wrote: this is not correct. IO (StorableArray Int CDouble) is a monadic *value* itself, which represents an *action* which returns a storable array, and since you are filling in the slot in Rmatrix with the action (newListArray a l), this monadic value represents the action of creating a new array whenever the action is executed.

3 4

Re: [Haskell] (.) . (.)
by Brian Hulley 28 May '06

28 May '06

[Moved to cafe] Christophe Poucet wrote: > Hello, > > I think you look at the (.) . (.) as all being c's in the wrong way. > You have to consider what will evaluate first (syntactical priority > rules). (.) . (.) === (.) (.) (.) -- a + b === (+) a b === c c c > Anyways the simplest case that this is equivalent can be seen > here: 22:33 < vincenz> @pl \f g a b -> f (g a b) > 22:33 < lambdabot> (.) . (.) > > Writing it explicilty: > (.) f g a = f (g a) > > > so we get > (.) . (.) = \f -> (.) ((.) f) > (.) . (.) f = (.) ((.) f) > (.) . (.) f g = (.) ((.) f) g > (.) . (.) f g = ((.) f) . g > (.) . (.) f g a = ((.) f) (g a) > (.) . (.) f g a = (.) f (g a) > (.) . (.) f g a = f . (g a) > (.) . (.) f g a b = f . (g a) $ b > (.) . (.) f g a b = f ((g a) b) > (.) . (.) f g a b = f (g a b) Thanks for the proof. I see it's got the advantage over mine that it doesn't need to use eta expansion and is also much clearer. Regards, Brian.

1 0

Projects related to Haskell
by Imam Tashdid ul Alam 27 May '06

27 May '06

I was just wondering, when the HCAR will come out. just the same, for people like me who are not very involved with the community, it is difficult to get an overview of the ongoing projects. the wiki says Gofer is now abandoned and Hugs replaces it. nice to know. I wonder how about Mondrian, Eden and the rest. there should be a mechanism to officially deprecate a project, shouldn't there? and once again, a mechanism to nominate a successor so that newbies like me will know where to start exploring. cheers. Imam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

request for co-development: improving Data.CharEncoding module
by Bulat Ziganshin 27 May '06

27 May '06

Hello Haskell, i plan to publish new version of Streams library on next week (see http://haskell.org/haskellwiki/Library/Streams if you still don't know about it :) ). one of it's current drawbacks is lack of support for file encodings other than UTF-8 and Latin-1. if someone can work on this support, it will widen usage area of the library i attached to letter current version of this module. it uses monadic approach to encoding and decoding: each encoder is just a function that performs monadic PutChar action via calls to monadic PutByte action, and decoder in the same fashion translates each call to GetChar into calls to GetByte. this allows to use encoders in various environments - for monadic i/o, string conversion and so on this module requires two improvements - first, support for other UTF encodings; second, raising an exception in situations when data can't be encoded (such as char > '\255' for Latin-1) or decoded (bad UTF bytes sequence). if you are going to work on this module, please write about this here - to avoid overlapping of work -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

Re: [Haskell] Keeping input separate from output?
by Clifford Beshers 26 May '06

26 May '06

ihope wrote: > > How would I keep the "Foo!" from conflicting with the "Lorem ipsum > dolor sit amet."? Well, if two millennia were not enough, I'm not sure any amount of Haskell will help.

1 0

help with MPTC for type proofs?
by David Roundy 26 May '06

26 May '06

Hi all, I've been thinking about extending some (experimental) GADT-based proof code that verifies that the darcs patch theory code is properly used. A given patch has type (Patch a b), and I'd like to be able to write something like commute :: (Patch a b, Patch b c) -> (Patch a d, Patch d c) in such a way that the type system know that the type d is one particular type, uniquely determined by the types a, b and c. Currently, which I do is to make d be existential with data Pair a c where (:.) :: Patch a d -> Patch d c -> Pair a c commute :: Pair a c -> Pair a c which prevents misuse of the returned pair, but doesn't allow proper use, for example we ought to be able to compile: test (a :. b) = do (b' :. a') <- return $ commute (a :. b) (b'' :. a'') <- return $ commute (a :. b) (a''' :. b''') <- return $ commute (b' :. a'') return () but this will fail, because the compiler doesn't know that b' and b'' have the same type. So I'd like to write something like class Commutable a b d c commute :: Commutable a b d c => (Patch a b, Patch b c) -> (Patch a d, Patch d c) But for this to work properly, I'd need to guarantee that 1. if (Commutable a b d c) then (Commutable a d b c) 2. for a given three types (a b c) there exists at most one type d such that (Commutable a b c d) I have a feeling that these may be enforceable using fundeps (or associated types?), but have pretty much no idea to approach this problem, or even if it's soluble. Keep in mind that all these types (a, b, c and d) will be phantom types. Any suggestions would be welcome. -- David Roundy http://www.darcs.net

2 1

Re: [Haskell-cafe] Linking to third party libraries in windows
by Brian Hulley 26 May '06

26 May '06

Dear friends - I must have clicked "reply" instead of "reply all" so here is the reply haskell cafe would have received: Matthew Bromberg wrote: > Not only does your suggestion make more sense than what I was doing, > but also > it causes the 'matrices' to behave as expected, namely to have the > side effects > incorporated into their array values. > > I can't say I fully understand why this is true. In both cases I was > wrapping Rmatrix in > a monad after every computation. The difference is that the array > component had an > additional monad wrapper around and now it doesn't. That is, > > old case > newtype Rmatrix = Rmatrix (Int, Int, IO(StorableArray Int CDouble)) > > new case > newtype Rmatrix = Rmatrix (Int, Int, StorableArray Int CDouble) > > In the old way, the additional IO wrapper forces an additional > nesting of do loops for most processing. This is the essential difference, but I think you haven't quite understood what it means. When you say > The difference is that the array component had an > additional monad wrapper around and now it doesn't. this is not correct. IO (StorableArray Int CDouble) is a monadic *value* itself, which represents an *action* which returns a storable array, and since you are filling in the slot in Rmatrix with the action (newListArray a l), this monadic value represents the action of creating a new array whenever the action is executed. Whereas (StorableArray Int CDouble) is the actual array itself. You could also use your old definition of Rmatrix but change the way it is created eg: listtoRmatrix r c es = do arr <- newListArray (0, r * c) es return (Rmatrix r c (return arr)) do r2 <- listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1] -- the rest is old code and everything would work as expected, because in this case, the monadic action contained in Rmatrix just returns the array arr that was created in the execution of listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1], because listtoRmatrix is the only place where the action of creating a new array, ie (newListArray (0, r * c) es) is actually executed. I think the subtlety is one of these things that's very difficult to understand at first, but once you've grasped the fact that in Haskell expressions can evaluate to actions which are themselves values, and which in turn can create new values when executed, it will hopefully become a lot clearer. Regards, Brian. -- Logic empowers the living and justifies the dead. But societal laws, and religious dogma, empower the dead, to destroy what's living. http://www.metamilk.com

1 0

Re: [Haskell-cafe] Linking to third party libraries in windows
by Matthew Bromberg 26 May '06

26 May '06

Not only does your suggestion make more sense than what I was doing, but also it causes the 'matrices' to behave as expected, namely to have the side effects incorporated into their array values. I can't say I fully understand why this is true. In both cases I was wrapping Rmatrix in a monad after every computation. The difference is that the array component had an additional monad wrapper around and now it doesn't. That is, old case newtype Rmatrix = Rmatrix (Int, Int, IO(StorableArray Int CDouble)) new case newtype Rmatrix = Rmatrix (Int, Int, StorableArray Int CDouble) In the old way, the additional IO wrapper forces an additional nesting of do loops for most processing. It is certainly the case that the do loop that performs the withStorableArray operations has the contents of the array modified. Outside that loop, once all actions on the monad are done, I am not convinced the array will mutate unless it's explicitly returned. Now hopefully I won't induce unnecessary copying. Thanks again for your help. Brian Hulley wrote: > > Hi Matthew - > Sorry about the long delay in my reply to your last message - I'd > composed the reply but when I tried to send it I was blocked by > spamhaus.com because the dynamic IP that my ISP had allocated to me at > the time I was connected had been listed on some composite spam > blocker database, and even when I tried reconnecting several times I > kept ending up being allocated the same client IP. So I did a complete > scan of my system and now (several hours later) when I tried to > reconnect again, I've been allocated a different client IP so my reply > to your last message was sent at last! ... > > I hope it answers your question relating to the above: the array is > not created in the let statement, but twice, in > rout <- mac r2 (-0.5) rmat > and then again in > mprint r2 > > Rmatrix really needs to have type (Int, Int, StorableArray Int > CDouble) if your intention is to pass around an actual allocated > matrix together with its dimensions, and listtoRmatrix would need to > be typed as: > > listtoRmatrix :: Int -> Int -> IO Rmatrix > > so that the let statement could be replaced by > > r2 <- listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1] > > and for example mprint would be defined as: > > mprint :: Rmatrix -> IO () > mprint (Rmatrix cols rows arr) = do > -- just print element at (0,0) for the moment > readArray arr 0 >>= print > > (Of course the above needs to iterate through the rows cols etc but > you've already got the code to do this...) > > Hope this helps, > > Brian. >

2 1

Re: [Haskell-cafe] Linking to third party libraries in windows
by Matthew Bromberg 26 May '06

26 May '06

OK I'm punting on the AMD libraries for now and will just use the Atlas libraries until I can get to the bottom of this. However, for me, it seems the rabbit hole goes a little deeper on the issue of array copies. Consider this code snippet import Matrix main = do print "Matrices" let r2 = listtoRmatrix 3 2 [1, 1, 1, 1, 1, 1] rout <- mac r2 (-0.5) rmat putStrLn "\nrout" mprint rout putStrLn "\nrmat2" mprint r2 putStrLn "\nrmat" mprint rmat An Rmatrix has type (Int, Int, IO (StorableArray Int CDouble)) and mac (multiply and accumulate) should provide the side effecting operation A <- A+ alpha * B for mac A alpha B . It returns IO(Rmatrix) for clarity here. listtoRmatrix just returns a regular Rmatrix. Now mac is implemented via daxpy and it should modify the mutable array in r2. rout is printed prior to r2, which (surprisingly?) remains unchanged. Here are the outputs rout 0.5000000 -1.0000000 0.0000000 -1.5000000 -0.5000000 -2.0000000 rmat2 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 1.0000000 rmat 1.0000000 4.0000000 2.0000000 5.0000000 3.0000000 6.0000000 Thus Haskell does not allow the side effect to affect the let binding. How does it achieve this without copying r2? If I bound r2 to this matrix using <- and a monad wrapper the result is the same. Does it recreate r2 just prior to the call to mprint r2? If Haskell has a magic way of doing this, without actually making a copy of the mutable array in r2, that would be pretty nifty actually. Brian Hulley wrote: > > I'd thought the stub was just to give the compiler something to > compile against, and that __stdcall was only used by Windows API > rather than all DLLs, but no doubt you're right. Ive just been looking > at the "Exporting from a DLL" help page from Visual Studio and it says > "When exporting functions with either method, make sure to use > __stdcall", so perhaps the functions I've exported using > __declspec(dllexport) are using __stdcall after all. > >> >> Now for my 'surprising' result. The matrix library is working against >> double arrays stored in a StorableArray. Presumably these storable >> arrays are mutable, but in fact the compiler makes sure that the >> array's are copied, when I enter a do clause. So for example >> arrx = newListArray (1 , 3) [3,2,1]:: IO (StorableArray Int CDouble) >> arry = newListArray (1 , 3) [1,1,1]:: IO (StorableArray Int CDouble) >> >> allocates two Storable arrays. > > No - this doesn't do any allocation. It just sets up two equations so > that anywhere you write arrx is equivalent to writing newListArray (1 > , 3) [3,2,1]:: IO (StorableArray Int CDouble) > > > It's not copied. A new array is created. Your do loop is the same as: > > -- the outer do > do > -- presumably you wrote arr <- arrx somewhere here > arr <- newListArray (1 , 3) [3,2,1]:: IO (StorableArray Int CDouble) > > -- the do loop quoted above > do > arr <- newListArray (1 , 3) [3,2,1]:: IO (StorableArray Int > CDouble) > withStorableArray arr sumarr >>= print > > -- view the contents of the first "arr" > putStrLn "Element 1: " >> (readArray arr 1 >>= print) > > Regards, Brian. >

1 0