- Haskell-Cafe - Haskell.org

Named data type members
by yin 20 Jul '05

20 Jul '05

Hello, I've a data type: data SomeData = SomeData { int1 :: Int, int2 :: Int } class SomeClass where infix 1 `i_` i_ :: SomeData -> Int -> SomeData infix 1 `_i` _i :: SomeData -> Int -> SomeData instance SomeClass SomeData where (SomeData int1 int2) `i_` i = SomeData (int1 + i) int2 (SomeData int1 int2) `_i` i = SomeData int1 (int2 + i) 1. Possible optimalizations ...? 2. There are several data type members in 'SomeData' and I wish to access them in other way then "(SomeData m1 m2 m3 m4 m5 ... m100) `a` i = SomeData (m1 + i) m2 m3 ... m100" 3a. The 'SomeData' is something like c structure, which holds all application data. One instanciated variable is passed in more functions to each other: -- SomeData is now very complex initsomeData :: SomeData initsomeData = do var1 <- init... ... SomeData 0 0 0 1 1 True False (-1) var1 var2 ....... main = do p <- initAplication processEvents p -- First Function processEvents :: SomeData -> IO () processEvents p = do event <- pollEvent case event of Event1 -> do processEvents (SomeData v1 v2 v3 (v4*2) ... v100) Event2 -> do processEvents (SomeData v1 ... False ... v100) Event2' -> do processEvents (SomeData v1 ... True ... v100) EventQuit -> do return () NoMoreEvents -> do computeNext p _ -> processEvents p where (SomeData v1 v2 v3 v4 v5 ... v100) = p -- An time based function computeNextStep = do timeDelta <- getTimeDelta let i1' = compute1 i1 i2 i3 ... i50 i2' = compute2 i1 i2 i3 ... i50 ... if (condition) then -- need more computing computeNextStep (SomeData u1 u2 ... u50 i1 i2 ... i50) else do p' <- (SomeData u1 u2 ... u50 i1 i2 ... i50) draw p' processEvents p' where (SomeData u1 u2 ... u50 i1 i2 ... i50) = p -- ux - uninteresting (State variables, like left-key-down was last left-key related event: move left) -- ix - interesting for computing -- where x = 1, 2 ... 50 ... ... 3b. every funtion needs only a part of the data... can I build for every fintion a class with defined operators to manipulate with the data and then: * pass the variable in func1 known as class A to func2, which is infering a class B? Thank you all... Matej 'Yin' Gagyi

2 1

RE: [Haskell-cafe] Proposal: deriving ShallowEq?
by Ralf Lammel 20 Jul '05

20 Jul '05

As Bulat points out, the GHC primitive dataToTag# indeed nicely solves the problem. Ben, just for completeness' sake; with SYB, you get such reflective information too (and others): shallowEq :: Data a => a -> a -> Bool shallowEq x y = toConstr x == toConstr y (dataToTag# returns Int, while toConstr comprises other things like the constructor name.) Regards, Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Bulat Ziganshin > Sent: Tuesday, July 19, 2005 1:18 AM > To: Ben Lippmeier > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Proposal: deriving ShallowEq? > > Hello Ben, > > Tuesday, July 19, 2005, 11:01:32 AM, you wrote: > BL> I often find it useful to determine whether two objects are using the > BL> same constructor, without worrying about the constructors' arguments. > > BL> There is way to hack together a partial implementation of the > ShallowEq > BL> class within GHC, but it leaves much to be desired: > > BL> > instance Show a => ShallowEq a where > BL> > (=@=) a b > BL> > = (head $ words $ show a) == (head $ words $ show b) > > reading GHC sources is always very interesting :) > > that is from GHC/Base.hs : > > %********************************************************* > %* * > \subsection{@getTag@} > %* * > %********************************************************* > > Returns the 'tag' of a constructor application; this function is used > by the deriving code for Eq, Ord and Enum. > > The primitive dataToTag# requires an evaluated constructor application > as its argument, so we provide getTag as a wrapper that performs the > evaluation before calling dataToTag#. We could have dataToTag# > evaluate its argument, but we prefer to do it this way because (a) > dataToTag# can be an inline primop if it doesn't need to do any > evaluation, and (b) we want to expose the evaluation to the > simplifier, because it might be possible to eliminate the evaluation > in the case when the argument is already known to be evaluated. > > \begin{code} > {-# INLINE getTag #-} > getTag :: a -> Int# > getTag x = x `seq` dataToTag# x > \end{code} > > > > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Re: [Haskell-cafe] Error with Float
by Dinh Tien Tuan Anh 20 Jul '05

20 Jul '05

So there's no way to get exact stream that represents a fraction, such as: .5 = .10000000000000000.... .2 = .00110011001100110011............ ??? >From: Udo Stenzel <u.stenzel(a)web.de> >To: Dinh Tien Tuan Anh <tuananhbirm(a)hotmail.com> >Subject: Re: [Haskell-cafe] Error with Float >Date: Tue, 19 Jul 2005 20:51:14 +0200 > > > Value is: 0.800000000000001 > >What did you expect? Floating point numbers are inexact by their very >nature. Since 0.8, like many other numbers, is not representable >exactly in binary, (10 * 0.8 - 8) will certainly not be zero. > >Take a course in numerical mathematics some time. It helps. > > >Udo. >-- >HTML needs a <rant> tag. -- Alan Cox ><< signature.asc >> _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger 7.0 today! http://messenger.msn.co.uk

1 0

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