July 2005 - Haskell-Cafe

Proposal: deriving ShallowEq?
by Ben Lippmeier 19 Jul '05

19 Jul '05

Hello, I often find it useful to determine whether two objects are using the same constructor, without worrying about the constructors' arguments. An example, using some arbitrary data type "Thingo": > class ShallowEq a where > shallowEq :: a -> a -> Bool > data Thingo a b > = TOne a > | TTwo a b Int Char Float > | TThree Int Char b b > (TOne 23) `shallowEq` TOne{} True > (TThree 5 'c' True False) `shallowEq` TTwo{} False -- Having some sort of generic shallowEq operator reduces the need for a host of predicates such as: (this one from Data.Maybe) > isJust x > = case x of > Just {} -> True > _ -> False .. which is an approach that is obviously going to be tedious when the size of the data type becomes large. -- There is way to hack together a partial implementation of the ShallowEq class within GHC, but it leaves much to be desired: > instance Show a => ShallowEq a where > (=@=) a b > = (head $ words $ show a) == (head $ words $ show b) Notice that in the example the term "TTwo{}" is a partially constructed record. The implementation relies on laziniess to avoid trying to show the missing fields (which would fail). -- Questions: 1) Does anyone know a better/existing way to implement ShallowEq that doesn't involve enumerating all the constructors in the data type? 2) If not, can anyone think of reasons why it wouldn't be a good idea for GHC to derive ShallowEq (by expanding said enumeration)?

6 6

RE: [Haskell-cafe] Strict and non-strict vs eager and lazy, was C onfused about Cyclic struture
by Bayley, Alistair 19 Jul '05

19 Jul '05

> From: Jerzy Karczmarczuk [mailto:karczma@info.unicaen.fr] > > Bernard Pope wrote: > > >I'll be a little bit pedantic here. Haskell, the language definition, > >does not prescribe lazy evaluation. It says that the language is > >non-strict. Lazy evaluation is an implementation technique which > >satisfies non-strict semantics, but it is not the only > technique which > >does this. > > > > > This pedantry is renewed periodically. > > It is a pity that nobody ever writes anything about that other > methods of implementation of non-strictness, nor about the > languages which use those methods. > > I believe it might do some good to people who learn functional > programming in general, and Haskell in particular. > Any takers? Not a taker (yet - where can I find information about non-lazy implementation of non-strict languages? From Google so far: speculative evaluation (Eager Haskell), call-by-name vs call-by-need.) Wikipedia frustratingly hints that "other evaluation strategies are possible", but that's all it says: http://en.wikipedia.org/wiki/Non-strict_programming_language Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

4 3

lazy Graphics, was - How to variables
by Jake Luck 19 Jul '05

19 Jul '05

>> I need to write functions fast and efective. Math, heuristic, metadata >> and expert systems are better in haskell. If I could use haskel from C, >> I would do it. The problem are optimalizations, which are a critical >> change in algorithm. Other (and me too) won't understand my concepts. >> The speed and usability of Haskell is a good argument to use and learn it. > > I can buy that. Well, one can actually call into Haskell from C. It is less > commonly done, but very possible. Skim through the FFI addendum; you can > export static functions (foreign export) or arbitrary thunks (with the > confusingly named foreign import "wrapper"). If you are real adventurous, > you can tie directly into the GHC API from the C side as well (although I'm > not sure I can seriously recommend this method). > > Having said that, if you feel that Haskell has sufficient advantages to > warrant its use, I don't think you lose much by writing your main loops etc. > in Haskell as well, and I would recommend you go with the labeled record > technique to contain your program state. I too am working on a Haskell 3d renderer. However, my motivation is mostly inspired by Conal Elliott's Tbag and Vertigo projects. In my opinion, geometry, expressions and most 3d technologies fit naturally with the functional approach, like you said ("math, heuristic, metadata and expert systems"). Haskell's lazy execution is where I see opportunity for parallel optimization. Think about all the computed pixels and polygons that we throw away in our culling and clipping. Now if we can structure the system inside out .... (do you see what I am getting at?) Having written several keyframe system, I feel that Fran's frameless timing approach is ingenious (Hudak's School of Expression book has an excellent section describing its motivation). Though I am not without reservation in all of this, paying close attention to the graphics world, where things are progressively moving towards programmable hardware. IMO, Vertigo is a good example of a practical application using Haskell. I think that the division between where does functional stops and where imperative starts will be a key deciding factor in the performance feasability as well as adaptability for haskell software in the real graphics world. In other words, 1 million IORefs make me feel quite unsettled. Anyone care to comment on the feasability of those hypothesis? jake

1 0

RE: [Haskell-cafe] Strict and non-strict vs eager and lazy, was C onfused about Cyclic struture
by Bayley, Alistair 19 Jul '05

19 Jul '05

> From: Bernard Pope [mailto:bjpop@cs.mu.OZ.AU] > > I should have mentioned this paper: > > @article{Tremblay01, > author= {G. Tremblay}, > title= {Lenient evaluation is neither strict nor lazy}, > journal= {Computer Languages}, > volume= {26}, > number= {1}, > pages= {43--66}, > year= {2001}, > } > > (however I think he says that Haskell is lazy!) Thanks. Do you have a link to a free (beer) version? I don't have an ACM subscription. I found this related paper, which was useful: How Much Non-strictness do Lenient Programs Require? http://www.cs.ucsb.edu/~schauser/papers/95-fpca.ps (unrelated) BTW, I found this, which sounds similar to the STM in GHC 6.4. Again, does anyone have a link to a free version? P. Tinker and M. Katz. Parallel execution of sequential Scheme with ParaTran. http://portal.acm.org/citation.cfm?doid=62678.62682 Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

2 1

hawiki Haskell SDL openGl example works strange
by yin 18 Jul '05

18 Jul '05

Hello, again, I tried to run the example from http://haskell.org/hawiki/HaskellOpenGl (the SDL version), but the scene is shown, only when I resize the window. I tried to insert the drawGLScreen before mainloop call, but it didn't worked. Do you some idea how to resolve this little problem? Thanks Matej 'Yin' Gagyi

2 2

RE: Unicode in GHC 6.2.2 and 6.4.x (was: Re: [Haskell-cafe] Unicode.hs)
by Simon Marlow 18 Jul '05

18 Jul '05

On 17 July 2005 04:42, Dimitry Golubovsky wrote: > Dear List Subscribers, > > Simon Marlow wrote: >> On 30 June 2005 14:36, Dimitry Golubovsky wrote: >> >> >>> It is in CVS now, and I believe will be in 6.4.1 >> >> >> Not planned for 6.4.1, but definitely in 6.6. >> > > I have put those files that work for me in GHC 6.2.2 (Unicode support) > for download. Please read the Wiki page: > > http://haskell.org/hawiki/GhcUnicode > > for instructions. > > Any feedback will be appreciated. I believe, the code will work with > GHC > 6.4.x as well. Please let me know if there are any problems. I should mention that 6.4.1 will contain Dimitry's updated Unicode character-class support, albeit without the changes to library APIs that went along with it. The upshot is that all platforms should have consistent behaviour for the isXXX functions from Data.Char in 6.4.1. Cheers, Simon

1 0

RE: [Haskell-cafe] Re: Module.T naming style
by Simon Marlow 18 Jul '05

18 Jul '05

On 15 July 2005 16:13, Malcolm Wallace wrote: >> Hand-writing .hi files is how GHC used to work (up to version 0.29, >> IIRC). It's not entirely satisfactory because you can get into >> situations where you have to 'make' several times to get to a fixed >> point, and you can construct examples that never reach a fixed point. > > I believe, provided the hand-written boot file gives accurate type > signatures in the first place, there is no (correctness) need to > compile any file a second time. At least, this is the case in nhc98 > where the interface file records only type signatures. However, > certainly if you /do/ re-compile, often the /sequence/ of signatures > in the .hi file never reaches a fixpoint. Yes - actually I was thinking of the case where you modify something in a mutually-recursive group and recompile. It's tempting (especially for me, since I'm lazy) to just type 'make;make;make;make' rather than modify any .hi files by hand. So the .hi files don't initially contain correct information, but you hope they converge. It's possible by writing wrong type signatures in .hi files to diverge instead of converge. I can't remember the particular example right now; IIRC it was due to Lennart. Cheers, Simon

1 0

RE: [Haskell-cafe] Re: Module.T naming style
by Simon Marlow 18 Jul '05

18 Jul '05

On 15 July 2005 11:53, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> I hope you weren't including GHC in "most compilers" :-) GHC's >> implementation of mutually recursive modules is conformant with >> Haskell 98 (see Section 5.7). > > It depends on how you interpret this phrase: > "may require that imported modules contain additional information" > If you count writing a separate .hs-boot file as being the additional > information that is somehow "contained" within the module, then I > suppose nhc98 is also conformant with the report. True, I considered mentioning this detail, but decided against it - the fact that the type signatures aren't actually in the same file isn't really important. We follow the spirit of the specification. You guys should really document that nhc98 support mut. rec. modules too. > The only difference with nhc98 is that you hand-write a .hi file, > rather than a .hs-boot file, but the syntax is very similar to plain > Haskell. Also, the hand-written .hi file will be replaced with a > machine-generated one after compilation, but that is only a problem > if the user inadvertently removes all the .hi files. Hand-writing .hi files is how GHC used to work (up to version 0.29, IIRC). It's not entirely satisfactory because you can get into situations where you have to 'make' several times to get to a fixed point, and you can construct examples that never reach a fixed point. And 'make' complains about recursive dependencies a lot. What does hmake do? It used to be Really Fun(TM) when GHC was built like this... you could improve GHC's performance by simply typing 'make' a couple more times to let the inter-module optimisations propagate a bit further :) Cheers, Simon

4 3

IO platform for testing
by yin 18 Jul '05

18 Jul '05

Hello all, first I have to apologise for my English. So, I don't fully understand haskells IO, but I need some testing 'main' function: ./bundle01 <cmd> <arg1> <arg2> ... I more apoarches, but no one worked. Now I tried this: m01_mod :: Int -> Int -> Int b01_mod a b = a mod b main = do (cmd:ss) <- getArgs putStrLn ( if (cmd == "mod") then do show (b01_mod (read (ss!!1)) (read (ss!!2))) else do "unknown command!") Please, send me somethung like this (I need to understand it). I need runing more <cmd>s and with various argument counts and types. All functions "in a bundle" should be in one file. Thanks to you all :) Matej 'Yin' Gagyi

4 4

flushing trace debug output before getting other output
by Terrence Brannon 17 Jul '05

17 Jul '05

I'm working on exercise 6.16 in Thompson's "Haskell; the Craft of Functional Programming" My goal for the moment is to call printPicture to see my results: type Picture = [[Char]] printPicture :: Picture -> IO () printPicture = putStr . concat . map (++"\n") And everything is encouraging. The return type of my function syncs up: *Main> :t superimposeImage imgA imgB superimposeImage imgA imgB :: [[Char]] Now, the only issue is that I have put a number of trace statements in my program whose output is *interspersed* with the return data. The return data is simply lists of characters, where each character is "." or "#" *Main> printPicture $ superimposeImage imgA imgB siPointLogic i1 i2 0 15 .siPointLogic i1 i2 1 15 .siPointLogic i1 i2 2 15 .siPointLogic i1 i2 3 15 .siPointLogic i1 i2 4 15 .siPointLogic i1 i2 5 15 .siPointLogic i1 i2 6 15 .siPointLogic i1 i2 7 15 .siPointLogic i1 i2 8 15 .siPointLogic i1 i2 9 15 .siPointLogic i1 i2 10 15 .siPointLogic i1 i2 11 15 When I remove my various trace statements, I get what I want: *Main> printPicture $ superimposeImage imgA imgB ................ ................ ................ ................ ...........##... So the question is, how can I leave the trace statements in the code and yet get the printPicture output after all the debugging output has output? It only makes sense for it to work that way. The trace output occurs during the program and in particular, during the program *prior* to the call to printPicture. Therefore all of the trace output should have finished *prior* to printPicture outputting it's rows. -- Carter's Compass: I know I'm on the right track when, by deleting something, I'm adding functionality.

2 1