November 2009 - Haskell-Cafe

Re: Re[Haskell-cafe] cursive to foldr
by Ezra Lalonde 18 Nov '09

18 Nov '09

Using the same basic structure you did, and foldr, I think below is the simplest method: ==================== import Data.Maybe searchList :: (a -> Bool) -> [a] -> Maybe [a] searchList p xs = foldr (\x acc -> if p x then Just (x: fromMaybe [] acc) else acc) Nothing xs ==================== ghci> searchList (=='o') "A quick brown fox" Just "oo" ghci> searchList (==' ') "A quick brown fox" Just " " ghci> searchList (=='z') "A quick brown fox" Nothing >From maybe gets rid of the Maybe, so that our recursive call works: ghci> fromMaybe [] (Just [1..3]) [1,2,3] That's why we got the error below when we tried without fromMaybe; on subsequent applications of foldr, the type would have to change. ==================== <interactive>:1:51: Couldn't match expected type `[a]' against inferred type `Maybe [a]' In the expression: if p x then Just (x : acc) else acc In the first argument of `foldr', namely `(\ x acc -> if p x then Just (x : acc) else acc)' In the expression: foldr (\ x acc -> if p x then Just (x : acc) else acc) Nothing xs ==================== I have a feeling that using fromMaybe is not the best way, but it gets the job done for now. On that note; if somebody with some more experience would chime in, that'd be awesome. ;) Ezra dima.neg wrote: > > How can I do this using foldr? > > searchList p [] = Nothing > searchList p (x:xs) > | p x = Just (x:filter p xs) > | otherwise = searchList p xs > > > I try this: > searchList p xs = foldr (\x acc -> if p x then Just (x:acc) else acc) > Nothing xs > but don't work. > > Thanks > -- View this message in context: http://old.nabble.com/Recursive-to-foldr-tp26368900p26399795.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

5 5

Call for Participation - PEPM'10 (co-located with POPL'10)
by Janis Voigtländer 18 Nov '09

18 Nov '09

=============================================================== CALL FOR PARTICIPATION ACM SIGPLAN 2010 Workshop on Partial Evaluation and Program Manipulation (PEPM'10) Madrid, January 18-19, 2010 (Affiliated with POPL'10) http://www.program-transformation.org/PEPM10 =============================================================== Abstracts of all papers and presentations are available from the above web site. INVITED TALKS: * Lennart Augustsson (Standard Chartered Bank, UK) Title: O, Partial Evaluator, Where Art Thou? * Jeremy Siek (University of Colorado at Boulder, USA) Title: General Purpose Languages Should be Metalanguages. SPECIAL FEATURE: * Andy Gill, Garrin Kimmell and Kevin Matlage. Capturing Functions and Catching Satellites. CONTRIBUTED TALKS: * Nabil el Boustani and Jurriaan Hage. Corrective Hints for Type Incorrect Generic Java Programs. * Johannes Rudolph and Peter Thiemann. Mnemonics: Type-safe Bytecode Generation at Run Time. * Elvira Albert, Miguel Gomez-Zamalloa and German Puebla. PET: A Partial Evaluation-based Test Case Generation Tool for Java Bytecode. * Martin Hofmann. Igor2 - an Analytical Inductive Functional Programming System. * José Pedro Magalhães, Stefan Holdermans, Johan Jeuring and Andres Löh. Optimizing Generics Is Easy! * Michele Baggi, María Alpuente, Demis Ballis and Moreno Falaschi. A Fold/Unfold Transformation Framework for Rewrite Theories extended to CCT. * Hugh Anderson and Siau-Cheng KHOO. Regular Approximation and Bounded Domains for Size-Change Termination. * Évelyne Contejean, Pierre Courtieu, Julien Forest, Andrei Paskevich, Olivier Pons and Xavier Urbain. A3PAT, an Approach for Certified Automated Termination Proofs. * Fritz Henglein. Optimizing Relational Algebra Operations Using Generic Equivalence Discriminators and Lazy Products. * Adrian Riesco and Juan Rodriguez-Hortala. Programming with Singular and Plural Non-deterministic Functions. * Martin Hofmann and Emanuel Kitzelmann. I/O Guided Detection of List Catamorphisms. * Andrew Moss and Dan Page. Bridging the Gap Between Symbolic and Efficient AES Implementations. * Christopher Brown and Simon Thompson. Clone Detection and Elimination for Haskell. * Stefan Holdermans and Jurriaan Hage. Making Stricterness More Relevant. * Arun Lakhotia, Davidson Boccardo, Anshuman Singh and Aleardo Manacero Júnior. Context-Sensitive Analysis of Obfuscated x86 Executables. * Xin Li and Mizuhito Ogawa. Conditional Weighted Pushdown Systems and Applications. * Ivan Lazar Miljenovic. The SourceGraph Program. * Florian Haftmann. From Higher-Order Logic to Haskell: There and Back Again. IMPORTANT DATES: * Early registration deadline: December 22, 2009 * Hotel registration deadline: December 28, 2009

1 0

ANN: LambdaCube engine and Bullet physics binding
by Csaba Hruska 18 Nov '09

18 Nov '09

Hi everyone, I'm pleased to announce the first pre-beta-candidate-release of the LambdaCube 3D engine [1] and the bindings for the Bullet physics library [2]. The packages are just a cabal-install away. You should be able to install lambdacube-engine and lambdacube-examples right away. In order to get the physics engine running, please check the instructions on the wiki. After compiling bullet, you can try the lambdacube-bullet package as well, which shows how to combine the two. It can't be stressed enough that this project is in a very early stage, and everything is bound to change and improve a lot. I just made this publicly available in order to attract contributions, so if you have anything to share, be it bugfixes, code improvements or more and prettier examples, feel free to join in! Cheers, Csaba [1] http://haskell.org/haskellwiki/LambdaCubeEngine [2] http://haskell.org/haskellwiki/Bullet

1 0

GHCi's :t misbehaving
by Philippa Cowderoy 18 Nov '09

18 Nov '09

I have some mildly complicated parsing code, that uses parsec to return a computation (in a state monad) that handles operator precedence - so I can handle scoped precedence/fixities, much like in Haskell. I just spent a while bolting on some new features. More time than I'd like, I'd left it alone for a while and it took a bit of time getting my head around it again enough to be okay doing folds on parse results and the like. Enough so that I've been leaning on the type checker to tell me when I've messed up! So, I have something that loads into ghci okay now. I go to check the type of one of the functions using :t and get this error: <interactive>:1:0: Ambiguous type variable `m' in the constraint: `Monad m' arising from a use of `constructor' at <interactive>:1:0-10 Probable fix: add a type signature that fixes these type variable(s) Now I'm not about the supply the type signature, that's what I asked it for! And it ought to typecheck okay, given that the code loaded in the first place. I'm about to turn in for the night, but I'm wondering what's going on here. Anyone? -- flippa(a)flippac.org

3 3

Announcing the GHC Bug Sweep
by Simon Marlow 18 Nov '09

18 Nov '09

Help us weed the GHC ticket database, and get a warm fuzzy feeling from contributing to Haskell core technology! There are currently ~750 tickets against GHC. Many of them have not been looked at in months or years. Often when I go through old tickets I find easy targets: bugs that have already been fixed, duplicates, bugs that are not reproducible and the submitter has gone away. So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least. This is a game for the whole family! We don't care how much progress you make on each ticket, just as long as someone has taken a look and moved the ticket forward in some way. For example, you might check for duplicates, update the metadata, ask for more information from the submitter, try to reproduce the bug against the latest version of GHC. To claim a ticket all you have to do is remove it from the list on the wiki. Full instructions are here http://hackage.haskell.org/trac/ghc/wiki/BugSweep including a list of suggestions for ways to make progress on a ticket. Cheers! Simon & the GHC team

3 4

ICFP '10: Second call for workshop proposals
by Wouter Swierstra 18 Nov '09

18 Nov '09

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2010 15th ACM SIGPLAN International Conference on Functional Programming September 27 - 29, 2010 Baltimore, Maryland http://www.icfpconference.org/icfp2010 The 15th ACM SIGPLAN International Conference on Functional Programming will be held in Baltimore, Maryland on September 27-29, 2010. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2010 and sponsored by SIGPLAN. These events should be more informal and focused than ICFP itself, include sessions that enable interaction among the attendees, and be fairly low-cost. The preference is for one-day events, but other schedules can also be considered. ---------------------------------------------------------------------- Submission details Deadline for submission: November 20, 2009 Notification of acceptance: December 18, 2009 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2010 workshop co-chairs (Derek Dreyer and Chris Stone), via email to icfp10-workshops at mpi-sws.org by November 20, 2009. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 18, 2009, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2010/icfp10-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://acm.org/sigplan/sigplan_workshop_proposal.htm ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2010 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: Derek Dreyer (MPI-SWS) Workshop Co-Chair: Chris Stone (Harvey Mudd College) General Chair: Paul Hudak (Yale University) Program Chair: Stephanie Weirich (University of Pennsylvania) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Derek Dreyer and Chris Stone), via email to icfp10-workshops at mpi-sws.org.

1 0

hipmunkplayground on windows
by Anatoly Yakovenko 18 Nov '09

18 Nov '09

Anyone else seeing a bunch of linker errors when trying to install HipmunkPlayground? this is what i see: C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(RenderMode.o):fake:(.text+0x5be): more undefined references to `glRenderMode' follow C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x1c25): undefined reference to `glGetTexEnvfv' C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x5779): undefined reference to `glTexEnvi' C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x58f5): undefined reference to `glGetTexEnviv' C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x5aba): undefined reference to `glTexEnvf' C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x5c7d): undefined reference to `glGetTexEnvfv' C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Environments.o):fake:(.text+0x6d51): undefined reference to `glTexEnvfv' C:\Program Files\Haskell\OpenGL-2.2.3.0\ghc-6.10.4/libHSOpenGL-2.2.3.0.a(Queries.o):fake:(.text+0x339): undefined reference to `glGetTexLevelParameteriv' collect2: ld returned 1 exit status cabal.exe: Error: some packages failed to install: HipmunkPlayground-5.0.0 failed during the building phase. The exception was: exit: ExitFailure 1

3 2

omitting params in function bindings
by Doug McIlroy 18 Nov '09

18 Nov '09

Is there a deep reason (beyond saving a sentence or two in the language definition) for requiring all patterns in a function binding to have the same explicit arity? For example, in dropWhile0 :: Num a => [a] -> [a] dropWhile0 (0:xs) = dropWhile0 xs dropWhile0 xs = xs why shouldn't the last line be replaceable by dropWhile0 = id

3 2

Re: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
by Luke Palmer 17 Nov '09

17 Nov '09

On Tue, Nov 17, 2009 at 8:48 PM, Dean Herington <heringtonlacey(a)mindspring.com> wrote: > The documentation claim that "The default implementation of 'deepseq' is > simply 'seq'" is not exactly right, as `deepseq` and `seq` have different > signatures. Which raises the more interesting question: Why did you choose > a different signature? And, would a version of `seq` with the same > signature as `deepseq` be useful? The situation is analogous to, say, "null" having this signature: null :: [a] -> Bool Instead of this one: null :: [a] -> b -> b -> b Or the recent famous debate about returning Maybe a vs. Monad m => m a for failure. If we have seq' :: a -> (), then we have seq = m . seq' where m () = id And of course we can go the other way too. So it is a question of taste. deepseq is simpler by at least two standards: it is not polymorphic and it has only one argument. There are exactly two values of both () and forall b. b -> b, but that fact is more obvious of the former (IMO). I think it is the right choice. Luke

1 0

help with musical data structures
by Michael Mossey 17 Nov '09

17 Nov '09

I'm pretty new to Haskell so I don't know what kind of data structure I should use for the following problem. Some kind of arrays, I guess. One data item, called OrientedPCSet ("oriented pitch class set," a musical term) will represent a set whose members are from the range of integers 0 to 11. This could probably be represented efficiently as some kind of bit field for fast comparison. Another item, PitchMatrix, will be a 2-d matrix of midi pitch numbers. This matrix will be constructed via a backtracking algortithm with an evaluation function at each step. It will probably be constructed by adding one number at a time, starting at the top of a column and working down, then moving to the next column. This matrix should probably be implemented as an array of some sort for fast lookup of the item row x, column y. It doesn't require update/modification to be as fast as lookup, and it won't get very large, so some sort of immutable array may work. Thanks, Mike

6 9