Re: [Haskell-cafe] hipmunkplayground on windows
Am Mittwoch 18 November 2009 08:56:26 schrieb Felipe Lessa: On Tue, Nov 17, 2009 at 10:21:07PM -0800, Anatoly Yakovenko wrote: Anyone else seeing a bunch of linker errors when trying to install HipmunkPlayground? Hmmm, no, I've never seen those errors before. Are you able to compile any OpenGL programs at all? You may try, for example, installing the game 'bloxorz'[1]. [1] http://hackage.haskell.org/package/bloxorz I don't think that'll work: Quaternion.hs:34:26: Couldn't match expected type `GLfloat' against inferred type `Float' In the expression: (r00 :: GLfloat) In the second argument of `newMatrix', namely `[(r00 :: GLfloat), r01, r02, r03, ]' In the expression: newMatrix ColumnMajor [(r00 :: GLfloat), r01, r02, r03, ] cabal: Error: some packages failed to install: bloxorz-0.1 failed during the building phase. The exception was: exit: ExitFailure 1 Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0
On 17/11/2009 18:42, Brandon S. Allbery KF8NH wrote: On Nov 17, 2009, at 11:36 , Bryan O'Sullivan wrote: On Tue, Nov 17, 2009 at 3:00 AM, Simon Marlow marlo...@gmail.com mailto:marlo...@gmail.com wrote: I've just uploaded deepseq-1.0.0.0 to Hackage http://hackage.haskell.org/package/deepseq This provides a DeepSeq class with a deepseq method, equivalent to the existing NFData/rnf in the parallel package. http://www.haskell.org/mailman/listinfo/haskell-cafe If it's equivalent, what are the relevant differences? Why would I choose DeepSeq over NFData or vice versa? Considering that he said he's going to be using it in parallel, the difference is merely that it's usable *without* parallel. It's about dependencies, not functionality. Yes, that's exactly it. No new functionality relative to NFData, just moving it to a more appropriate place. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: deepseq-1.0.0.0
On 17/11/2009 12:25, Nicolas Pouillard wrote: Excerpts from Simon Marlow's message of Tue Nov 17 12:00:21 +0100 2009: I've just uploaded deepseq-1.0.0.0 to Hackage Great! I'm wondering what is the need/purpose for DeepSeqIntegral and DeepSeqOrd? I don't actually know, they were previously NFDataIntegral and NFDataOrd respectively. Unless anyone can think of a reason to want these, I'll remove them. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
On 18/11/2009 03:48, Dean Herington wrote: At 11:00 AM + 11/17/09, Simon Marlow wrote: I've just uploaded deepseq-1.0.0.0 to Hackage http://hackage.haskell.org/package/deepseq This provides a DeepSeq class with a deepseq method, equivalent to the existing NFData/rnf in the parallel package. I'll be using this in a newly revamped parallel package, which I hope to upload shortly. Cheers, Simon 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? So the main difference is that with the current formulation of deepseq, you need to explicitly force the result in order to use it, either with a pattern match, another seq, or a pseq. If we used (a - b - b) then the top-level forcing is built-in. Let's look at an example instance; here (1) is the current deepseq, (2) is deepseq :: a - b - b instance (DeepSeq a, DeepSeq b) = DeepSeq (a,b) where -- (1) deepseq (a,b) = deepseq a `seq` deepseq b -- (2) deepseq (a,b) = deepseq a . deepseq b They're both fairly similar. Most instances follow this pattern, with seq being replaced by (.). You could argue that (a - b - b) is doing more than (a - ()), because it has a kind of built-in continuation (Luke's point). I buy that, although (a - ()) has a strange-looking unit type in the result and you have to use it in conjunction with seq. (1) generates slightly better code with GHC, because it compiles seq directly into a case expression, whereas (.) involves a thunk. If deepseq is inlined all the way down, then it would turn into the same thing either way. I don't feel terribly strongly, but I have a slight preference for the current version. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
Hello Simon, Wednesday, November 18, 2009, 12:17:31 PM, you wrote: You could argue that (a - b - b) is doing more than (a - ()), if i correctly understand, we have two versions: 1) easier to use 2) more efficient and one of them may be defined via another? how about providing both versions, with simpler name for simpler version? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
Simon Marlow wrote: I've just uploaded deepseq-1.0.0.0 to Hackage http://hackage.haskell.org/package/deepseq This provides a DeepSeq class with a deepseq method, equivalent to the existing NFData/rnf in the parallel package. I'll be using this in a newly revamped parallel package, which I hope to upload shortly. Any reason for the name change? I liked normal form being part of NFData and rnf . Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| Simon, have you given any thought to how this interacts with type system | extensions, in particular with GADTs and type families? The proposal relies | on being able to find the type of a term but it's not entirely clear to me | what that means. Here is an example: | | foo :: F Int - Int | foo :: Int - Int | | bar1 :: Int - Int | bar1 = foo | | bar2 :: Int ~ F Int = Int - Int | bar2 = foo | | IIUC, bar1 is ok but bar2 isn't. Do we realy want to have such a strong | dependency between name lookup and type inference? Can name lookup be | specified properly without also having to specify the entire inference | algorithm? Yes I think it can, although you are right to point out that I said nothing about type inference. One minor thing is that you've misunderstood the proposal a bit. It ONLY springs into action when there's a dot. So you'd have to write bar1 x = x.foo bar2 x = x.foo OK so now it works rather like type functions. Suppose, the types with which foo was in scope were foo :: Int - Int foo :: Bool - Char Now imagine that we had a weird kind of type function type instance TDNR_foo Int = Int - Int type instance TDNR_foo Bool = Bool - Char Each 'foo' gives a type instance for TDNR_foo, mapping the type of the first argument to the type of that foo. So when we see (x.foo) we produce the following constraints TDNR_foo tx ~ tx - tr where x:tx and the result type is tr. Then we can solve at our leisure. We can't make progress until we know 'tx', but when we do we can choose which foo is used. Of course, there'd be some modest built-in machinery rather than a forest of Now you rightly ask what if foo :: F Int - Int Now under my type function analogy, we'd get type instance TDNR_foo (F Int) = F Int - Int and now we may be in trouble because type functions can't have a type function call in an argument pattern. I hadn't thought of that. The obvious thing to do is to *refrain* from adding a type instance for such a 'foo'. But that would be a bit odd, because it would silently mean that some 'foo's (the ones whose first argument involved type functions) just didn't participate in TDNR at all. But we can hardly emit a warning message for every function with a type function in the first argument! I suppose that if you use x.foo, we could warn if any in-scope foo's have this property, saying you might have meant one of these, but I can't even consider them. GADTs, on the other hand, are no problem. | Another example: suppose we have | | data T a where | TInt :: T Int | TBool :: T Bool | | foo :: T Int - u | foo :: T Bool - u | | bar :: T a - u | bar x = case x of | TInt - foo x | TBool - foo x | | Here, (foo x) calls different functions in the two alternatives, right? To be | honest, that's not something I'd like to see in Haskell. You mean x.foo and x.foo, right? Then yes, certainly. Of course that's already true of type classes: data T a where T1 :: Show a = T a T2 :: Sow a = T a bar :: a - T a - String bar x y = case y of T1 - show x T2 - show x Then I get different show's. Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
It's always tempting to spend a lot of time on syntax, but in this case it may be justified. Syntactic brevity is a good part of the point of TDNR. And I'm on a train which is a good time to argue about syntax. Personally I think there are strong advantages to .: * For record selectors, currently written (x r), writing r.x is exactly right * For these unary operators, r.x really does mean (abstractly) select the x field from r * And that is the way that . is used for modules: M.x means select the x function from module M * You can think of qualified names for modules in the same way Control.Monad means pick the Monad module from the Control group. * It culturally fits with the way . is used on OO languages What is the disadvantage? Well, Haskell already uses . for composition. But * . is already special. If you write M.x you mean a qualified name, not the composition of data constructor M with function x I merely propose to make it even special-er! I'll keep quiet about syntax now. Simon | -Original Message- | From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe- | boun...@haskell.org] On Behalf Of wren ng thornton | Sent: 18 November 2009 03:07 | To: Haskell Cafe | Subject: Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal? | | Neil Brown wrote: | Having skimmed the page, it seems like the re-use of . is one of the | major difficulties of the proposal. Would it be possible to use -? | It has been used for accessing members in C and C++, so it is not too | unusual a choice. | | It's also the one that Perl went with. | | | It is already special in Haskell so it wouldn't break | anyone's code -- but do its other uses (case statements and lambdas) | mean that it would cause problems in the grammar if re-used for TDNR? | | Given the other uses of - in Haskell, I'm hesitant to suggest it | either. I seem to recall # is the option used by OCaml and a few other | functional-OO languages. So far as I know -XMagicHash is the only thing | that would conflict with that name so it seems far less invasive than . | or -. Another option would be to use @ which is currently forbidden in | expressions, though that might cause issues with System F/Core. | | -- | Live well, | ~wren | ___ | Haskell-Cafe mailing list | Haskell-Cafe@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
On 18/11/2009, at 21:10, Simon Peyton-Jones wrote: Yes I think it can, although you are right to point out that I said nothing about type inference. One minor thing is that you've misunderstood the proposal a bit. It ONLY springs into action when there's a dot. So you'd have to write bar1 x = x.foo bar2 x = x.foo Yes, that's what I meant to write, silly me. I promise to pay more attention next time. OK so now it works rather like type functions. Suppose, the types with which foo was in scope were foo :: Int - Int foo :: Bool - Char Now imagine that we had a weird kind of type function type instance TDNR_foo Int = Int - Int type instance TDNR_foo Bool = Bool - Char Each 'foo' gives a type instance for TDNR_foo, mapping the type of the first argument to the type of that foo. Hmm... GHC doesn't allow this: type instance TDNR_foo () = forall a. () - a - a IIUC this restriction is necessary to guarantee termination. Given your analogy, wouldn't this proposal run into similar problems? | Another example: suppose we have | | data T a where | TInt :: T Int | TBool :: T Bool | | foo :: T Int - u | foo :: T Bool - u | | bar :: T a - u | bar x = case x of | TInt - foo x | TBool - foo x | | Here, (foo x) calls different functions in the two alternatives, right? To be | honest, that's not something I'd like to see in Haskell. You mean x.foo and x.foo, right? Then yes, certainly. Of course that's already true of type classes: data T a where T1 :: Show a = T a T2 :: Sow a = T a bar :: a - T a - String bar x y = case y of T1 - show x T2 - show x Then I get different show's. How so? Surely you'll get the same Show instance in both cases unless you have conflicting instances in your program? Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP '10: Second call for workshop proposals
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell as an alternative to Java
I wonder whether the Haskell community tryed to reproduce the study Lisp as an alternative to Java, by Ron Garret / Erann Gat. However, since that study was reproduced in almost every other language (with a fair amount of cheating going on, I believe :-), I am sure that there is a Haskell version (without cheating, I am sure :-). Here is a paper about the original study: http://www.flownet.com/gat/papers/lisp-java.pdf Here is Norvig's solution to the original problem: http://www.norvig.com/java-lisp.html Could someone send me a link to a Haskell solution, with comments? I have seen a solution in Clean, but since it was a homework in the college where I study, I am quite sure that my fellow students have just translated Norvig's solution to Clean. Therefore, it would be great if one could send me a link to a Clean solution too. __ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announcing the GHC Bug Sweep
On 16/11/2009 16:29, Simon Marlow wrote: 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. Thanks to all those who have helped out so far. The bug database now has fewer bugs than a couple of days ago (we're now at 738). It's not much, but we're heading in the right direction. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Announcing the GHC Bug Sweep
On 16/11/2009 22:32, Michael Lesniak wrote: Hello, I'm also interested and find Roman's idea about a wiki-page for tracking motivating. 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. What I'd really like to see is a kind of categorization according to the topic, difficulty etc I think determing these things could be quite difficult for a GHC newbie (e.g. me). Any plans to do this? If you go to the Custom Query section of Trac, you can do these kinds of searches. The field Component is for the part of the system that the ticket applies to (e.g. compiler, run-time system, build system etc.), and Difficulty is a rough idea of how much work is involved. Obviously the difficulty varies a lot depending on who is doing the work, which is why I say it's a rough idea. These fields aren't always set correctly, which is one of the things that we hope to improve with the bug sweep. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] cursive to foldr
It looks quite neat to use the Maybe monoid here: import Data.Monoid searchList p = foldr (\x - if p x then mappend (Just [x]) else id) Nothing but it seems that the Maybe Monoid instance keeps this strict. I fiddled with this a bit, and came up with the following: instance (Monoid m) = Monoid (Maybe m) where mempty = Nothing -- as usual mappend (Just x) y = Just $ mappend x (fromMaybe mempty y) mappend Nothing y = y which results in the expected behaviour (it's unsatisfyingly asymmetric, since it should (but can't) produce a Just if the second argument is Just without pattern-matching on the first, but there is only so much one can do without involving scary things like unamb). I'd be interested in what people thought of the relative merits of this alternative Monoid instance, but perhaps that would be a subject for a different thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] pthread_kill missing?
Hi all, I'd like to send a signal from the main thread to a forkOS-ed thread in GHC. The former should use raiseSignal and the second should sit in awaitSignal. I figured that the posix functionality in the unix-2.3 library does not cover this case. I would have expected that blocking/sending/receiving signals would utilize the pthread_* routines. This does not seem to be the case. Any idea when these will be available? Thanks in advance, cheers, Gabor PS: I guess some of you will say, use condition variables. But that won't answer my question :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pthread_kill missing?
On Wed, Nov 18, 2009 at 2:03 PM, Gabor Greif ga...@mac.com wrote: PS: I guess some of you will say, use condition variables. But that won't answer my question :-) Actually, I was going to say use throwTo. Is there som reason you have to use the POSIX routines directly instead of using native haskell exceptions? -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHCi's :t misbehaving
Luke Palmer wrote: It's very hard to tell what is going on without more details. If you *at least* give the ghci session, and possibly the whole code (while it might be too much to read, it is not to much to load and try ourselves). This looks like a monomorphism restriction, which shouldn't happen when you are using :t. So that's why more info is necessary. I was using GHC 6.10.3 because I'd not felt like building my own gtk2hs on windows - it looks like it's fixed in 6.10.4, there was a remaining type error that 6.10.3 wasn't flagging up. -- fli...@flippac.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: parallel-2.0.0.0
I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies at all, I'd advise updating to this version of the parallel package. It's not completely API compatible, but if you're just using the supplied Strategies such as parList, the changes should be relatively minor. The Haddock docs include a full description of the changes, reproduced below. Haddock docs are also here, until Hackage catches up: http://www.haskell.org/~simonmar/parallel/index.html The Strategy-using programs I've tried so far go faster. Enjoy! Cheers, Simon - Version 1.x The original Strategies design is described in http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. Version 2.x Later, during work on the shared-memory implementation of parallelism in GHC, we discovered that the original formulation of Strategies had some problems, in particular it lead to space leaks and difficulties expressing speculative parallelism. Details are in the paper \Runtime Support for Multicore Haskell\ http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf. This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously @a - Done@ and is now @a - a...@. This change helps to fix the space leak described in \Runtime Support for Multicore Haskell\. The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a \new\ value after applying a 'Strategy', so that the application can evaluate each spark created by the 'Strategy'. The simple rule is this: you /must/ use the result of applying a 'Strategy' if the strategy creates parallel sparks, and you should probably discard the the original value. If you don't do this, currently it may result in a space leak. In the future (GHC 6.14), it will probably result in lost parallelism instead, as we plan to change GHC so that unreferenced sparks are discarded rather than retained (we can't make this change until most code is switched over to this new version of Strategies, because code using the old verison of Strategies would be broken by the change in policy). The other changes in version 2.x are: * Strategies can now be defined using a convenient Applicative type Eval. e.g. parList s = unEval $ traverse (Par . s) * 'parList' has been generalised to 'parTraverse', which works on any 'Traversable' type. * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', and there are transformation rules that automatically translate e.g. @parList rwnhf@ into a call to the optimised version. * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ package instead. Note that since the 'Strategy' type changed, 'rnf' is no longer a 'Strategy': use 'rdeepseq' instead. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
On Wed, 2009-11-18 at 09:17 +, Simon Marlow wrote: So the main difference is that with the current formulation of deepseq, you need to explicitly force the result in order to use it, either with a pattern match, another seq, or a pseq. If we used (a - b - b) then the top-level forcing is built-in. Let's look at an example instance; here (1) is the current deepseq, (2) is deepseq :: a - b - b instance (DeepSeq a, DeepSeq b) = DeepSeq (a,b) where -- (1) deepseq (a,b) = deepseq a `seq` deepseq b -- (2) deepseq (a,b) = deepseq a . deepseq b They're both fairly similar. Most instances follow this pattern, with seq being replaced by (.). You could argue that (a - b - b) is doing more than (a - ()), because it has a kind of built-in continuation (Luke's point). I buy that, although (a - ()) has a strange-looking unit type in the result and you have to use it in conjunction with seq. I think the most important thing is to make the public interface that people use most frequently simple and easy to remember. Thus I suggest the primary function people use should be deepseq :: DeepSeq a = a - b - b because then all that users have to remember is: deepseq --- like seq but more so! That's it. Users already know how to use seq, so now they know how to use deepseq too. (1) generates slightly better code with GHC, because it compiles seq directly into a case expression, whereas (.) involves a thunk. If deepseq is inlined all the way down, then it would turn into the same thing either way. I don't feel terribly strongly, but I have a slight preference for the current version. If it so happens that it is more convenient or faster to make the class and instances use the (a - ()) style then that is fine. We can give the class method a different name. Presumably people have to write Deepseq instances much less frequently than they use deepseq. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| Each 'foo' gives a type instance for TDNR_foo, mapping the type of the first | argument to the type of that foo. | | Hmm... GHC doesn't allow this: | | type instance TDNR_foo () = forall a. () - a - a | | IIUC this restriction is necessary to guarantee termination. Given your analogy, | wouldn't this proposal run into similar problems? Maybe so. Of course I don't propose to *really* make a type function; just a new form of constraint. I am not sure of the details. But I'm disinclined to work it through unless there's a solid consensus in favour of doing something, and I do not yet sense such a consensus. My nose tells me that the typing questions will not be a blocker. | Of course that's already true of type classes: | | data T a where | T1 :: Show a = T a |T2 :: Show a = T a | |bar :: a - T a - String |bar x y = case y of |T1 - show x |T2 - show x | | Then I get different show's. | | How so? Surely you'll get the same Show instance in both cases unless you have | conflicting instances in your program? T1 and T2 both bind a local (Show a) dictionary. I suppose you could argue that they must be the same, yes. But anyway, the original TDNR thing is perfectly well defined. It might occasionally be surprising. But that doesn't stop the OO folk from loving it. S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] surrogate code points in a Char
Hi. The Unicode Standard (version 4.0, section 3.9, D31 - pag 76) says: Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range D800 .. DFFF are ill-formed However GHC does not reject this code units: Prelude print '\xD800' '\55296' Is this a correct behaviour? Note that Python, too (2.5.4, UCS4 build, Linux Debian), accept these code units. Thanks Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: LambdaCube engine and Bullet physics binding
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
On Nov 18, 3:43 pm, Simon Peyton-Jones simo...@microsoft.com wrote:
But anyway, the original TDNR thing is perfectly well defined. It might
occasionally be surprising. But that doesn't stop the OO folk from loving it.
Not only OO folks but I think anybody who works with many records
having similar selectors. In the past I had hopes for Daan Leijen's
Extensible records with scoped labels [1] to have some impact on
Haskell's record system but that didn't happen. Module-scoped
selectors + the fact that you need one file per module are just not
very convenient. Type classes only lead to more boilerplate in this
area. If I compare for instance:
data D1 = D1 { d1_p :: Int }
data D2 = D2 { d2_p :: Int }
class P a where
p :: a - Int
withP :: a - Int - a
instance P D1 where
p = d1_p
withP p x = p { d1_p = x }
instance P D2 where
p = d2_p
withP p x = p { d2_p = x }
with the TDNR solution:
data D1 = D1 { p :: Int }
data D2 = D2 { p :: Int }
I have a clear preference. I think the important issue is not so much
that one can access p with OO-like notation, but that the scope of p
is effectively restricted. And very often one is not done with just
one type class but instead one writes many for the different record
fields. It was nice to see that DDC also has something similar to TDNR
[2]. I would be happy if someone corrects me and points out an easy
solution for this problem, but I fail to see one.
Cheers,
Levi
---
[1] http://legacy.cs.uu.nl/daan/pubs.html#scopedlabels
[2] http://www.haskell.org/haskellwiki/DDC/FieldProjections
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Wiki software?
Hi, I'm finally about to organize myself, somewhat. And am going to use a wiki for it. Does there a good one exist that's written in Haskell? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wiki software?
2009/11/18 Günther Schmidt gue.schm...@web.de: Hi, I'm finally about to organize myself, somewhat. And am going to use a wiki for it. Does there a good one exist that's written in Haskell? Günther http://hackage.haskell.org/cgi-bin/hackage-scripts/package/gitit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wiki software?
2009/11/18 Günther Schmidt gue.schm...@web.de: Hi, I'm finally about to organize myself, somewhat. And am going to use a wiki for it. Does there a good one exist that's written in Haskell? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Not what you were looking for, but org-mode in Emacs is great for organizing stuff. -- Deniz Dogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] surrogate code points in a Char
Enforcing a gap in the middle of the range of Char would be exceedingly awkward to propagate through all of the libraries. Off the top of my head: 1.) Functions like succ and pred which currently work on Char as an enumeration would have to jump over the gap, to be truly anal retentive about the mapping 2.) The toEnum and fromEnum would need to make the gap vanish as well, ruining the ability to treat toEnum/fromEnum as chr/ord 3.) Every application would take a performance hit 4.) What to do in the presence of an encoding error is even more uncertain. All you can do is throw an exception that can only be caught in IO. A couple of less defensible considerations: 5.) It would break alternative encodings like utf-8b which use the invalid code points in the surrogate pair range to encode ill-formed bytes in the input stream to allow 'cut and paste'-safe round tripping of utf-8b-Char-utf-8b even in the presence of invalid binary data/codepoints. 6.) Not all data is properly encoded. Consider, Unicode data you get back from Oracle, which isn't really encoded in UTF-8, but is instead CESU-8, which encodes codepoints in the higher plane as a surrogate pair, then utf-8 encodes the surrogate pair. So, I suppose the answer would be it is functioning as designed, because the current behavior is the least bad option. =) -Edward Kmett On Wed, Nov 18, 2009 at 10:28 AM, Manlio Perillo manlio_peri...@libero.itwrote: Hi. The Unicode Standard (version 4.0, section 3.9, D31 - pag 76) says: Because surrogate code points are not included in the set of Unicode scalar values, UTF-32 code units in the range D800 .. DFFF are ill-formed However GHC does not reject this code units: Prelude print '\xD800' '\55296' Is this a correct behaviour? Note that Python, too (2.5.4, UCS4 build, Linux Debian), accept these code units. Thanks Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wiki software?
Hi Deniz, you're probably right, but I'm looking for a web-based solution so I could access it from different machines / desktops. I'm doing work in about half a dozen different VMs. Günther Am 18.11.2009, 18:17 Uhr, schrieb Deniz Dogan deniz.a.m.do...@gmail.com: 2009/11/18 Günther Schmidt gue.schm...@web.de: Hi, I'm finally about to organize myself, somewhat. And am going to use a wiki for it. Does there a good one exist that's written in Haskell? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Not what you were looking for, but org-mode in Emacs is great for organizing stuff. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Participation - PEPM'10 (co-located with POPL'10)
=== 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
You know, another solution to the records problem, which is not quite
as convenient but much simpler (and has other applications) is to
allow local modules.
module Foo where
module Bar where
data Bar = Bar { x :: Int, y :: Int }
module Baz where
data Baz = Baz { x :: Int, y :: Int }
f a b = Bar.x a + Baz.y b
On Tue, Nov 17, 2009 at 5:18 AM, Simon Peyton-Jones
simo...@microsoft.com wrote:
| What's the status of the TDNR proposal [1]? Personally I think it is a
| very good idea and I'd like to see it in Haskell'/GHC rather sooner
| than later. Working around the limitations of the current record
| system is one of my biggest pain points in Haskell and TDNR would be a
| major improvement. Thus I wonder if someone is actively working on
| this proposal?
It's stalled. As far as I know, there's been very little discussion about
it. It's not a trivial thing to implement, and it treads on delicate
territory (how . is treated). So I'd need to be convinced there was a
strong constituency who really wanted it before adding it.
I've added an informal straw poll to the bottom of [1] to allow you to
express an opinion.
Also I'm not very happy with the stacking operations part, and I'd like a
better idea.
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
On Nov 18, 8:18 pm, Luke Palmer lrpal...@gmail.com wrote:
You know, another solution to the records problem, which is not quite
as convenient but much simpler (and has other applications) is to
allow local modules.
module Foo where
module Bar where
data Bar = Bar { x :: Int, y :: Int }
module Baz where
data Baz = Baz { x :: Int, y :: Int }
f a b = Bar.x a + Baz.y b
+1
Independent of TDNR I would welcome this. Maybe Ticket 2551 (Allow
multiple modules per source file) [1] should be reconsidered.
Cheers,
Levi
---
[1] http://hackage.haskell.org/trac/ghc/ticket/2551
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Status of TypeDirectedNameResolution proposal?
On Wed, Nov 18, 2009 at 3:10 PM, levi greenspan.l...@googlemail.com wrote:
On Nov 18, 8:18 pm, Luke Palmer lrpal...@gmail.com wrote:
You know, another solution to the records problem, which is not quite
as convenient but much simpler (and has other applications) is to
allow local modules.
module Foo where
module Bar where
data Bar = Bar { x :: Int, y :: Int }
module Baz where
data Baz = Baz { x :: Int, y :: Int }
f a b = Bar.x a + Baz.y b
+1
Independent of TDNR I would welcome this. Maybe Ticket 2551 (Allow
multiple modules per source file) [1] should be reconsidered.
Although ticket 2551 is not exactly what Luke is suggesting (which would be
an extension to the language, whereas, if I'm not mistaken, 2551 is just a
change to where GHC can find modules, not nesting of modules).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
The proposal has this sentence, apparently in reference to using qualified imports: This is sufficient, but it is just sufficiently inconvenient that people don't use it much. Does this mean qualified imports? I use them exclusively, and I'd love it if everyone else used them too. Anyway, a few concerns about TDNR as prosposed: One thing I'd really like that this would provide is shorter record selection. b.color is a lot nicer than Button.btn_color b. Or would it? It seems like under a TDNR scheme to be able to write b.color I'd have to either import color explicitly or go over to the unqualified import world. I don't really want to do the latter, but I also wouldn't want to maintain explicit import lists. Also, as far as I can see this doesn't provide is nice record update syntax. If I can write b.color I want to be able to write b2 = b.color := red! I think this will also lead to either lots of name shadowing warnings or more trouble picking variable names. The short perspicuous names this allows are also the most convenient for local variables. I don't want to suddenly not be able to use a 'color' variable name because some record has a 'color' field. A record system (and OO languages) would have no trouble with 'let color = b.color' but as far as I can see TDNR would have a problem. So as far as records, TDNR doesn't seem too satisfactory. I'm also worried about the use of dot with regards to a possible future record system. If we're already using dot for TDNR it's seems like it would be even harder for a record system to use it. I'm not saying this very well, but it seems like both proposals solve overlapping problems: TDNR provides convenient method calls and convenient field access as a side-effect, a record system would provide convenient field access and some form of subtyping. I think records are more interesting and I worry that TDNR would lessen motivation to implement records or make them more tricky to implement. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
On Wed, Nov 18, 2009 at 3:53 PM, Evan Laforge qdun...@gmail.com wrote: The proposal has this sentence, apparently in reference to using qualified imports: This is sufficient, but it is just sufficiently inconvenient that people don't use it much. Does this mean qualified imports? I use them exclusively, and I'd love it if everyone else used them too. A possibly irrelevant aside: Qualified imports are some times problematic when you need to work with classes from the module. You can't define a member of two instances from different two modules that define classes with conflicting member names. This can lead to situations where you have no option but to have orphan instances. module Bar where class Foo a where foo :: a module Baz where class Quux a where foo :: a module Quaffle where import qualified Bar import qualified Baz instance Bar.Foo Int where Bar.foo = 1 -- ^- syntax error. instance Baz.Quux Int where Baz.foo = 2 I suppose this could possibly be fixed if something deep in the parser allowed a QName there. -Edward Kmett Anyway, a few concerns about TDNR as prosposed: One thing I'd really like that this would provide is shorter record selection. b.color is a lot nicer than Button.btn_color b. Or would it? It seems like under a TDNR scheme to be able to write b.color I'd have to either import color explicitly or go over to the unqualified import world. I don't really want to do the latter, but I also wouldn't want to maintain explicit import lists. Also, as far as I can see this doesn't provide is nice record update syntax. If I can write b.color I want to be able to write b2 = b.color := red! I think this will also lead to either lots of name shadowing warnings or more trouble picking variable names. The short perspicuous names this allows are also the most convenient for local variables. I don't want to suddenly not be able to use a 'color' variable name because some record has a 'color' field. A record system (and OO languages) would have no trouble with 'let color = b.color' but as far as I can see TDNR would have a problem. So as far as records, TDNR doesn't seem too satisfactory. I'm also worried about the use of dot with regards to a possible future record system. If we're already using dot for TDNR it's seems like it would be even harder for a record system to use it. I'm not saying this very well, but it seems like both proposals solve overlapping problems: TDNR provides convenient method calls and convenient field access as a side-effect, a record system would provide convenient field access and some form of subtyping. I think records are more interesting and I worry that TDNR would lessen motivation to implement records or make them more tricky to implement. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wiki software?
How about: http://hackage.haskell.org/package/orchid a simple, but nice wiki produced by one of our students Sebastiaan Visser, Doaitse Swierstra On 18 nov 2009, at 18:14, Günther Schmidt wrote: Hi, I'm finally about to organize myself, somewhat. And am going to use a wiki for it. Does there a good one exist that's written in Haskell? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
On Wed, Nov 18, 2009 at 4:12 PM, Edward Kmett ekm...@gmail.com wrote: Qualified imports are some times problematic when you need to work with classes from the module. You can't define a member of two instances from different two modules that define classes with conflicting member names. This can lead to situations where you have no option but to have orphan instances. module Bar where class Foo a where foo :: a module Baz where class Quux a where foo :: a module Quaffle where import qualified Bar import qualified Baz instance Bar.Foo Int where Bar.foo = 1 -- ^- syntax error. instance Baz.Quux Int where Baz.foo = 2 I suppose this could possibly be fixed if something deep in the parser allowed a QName there. Try Quaffle without the qualifications. module Quaffle where import qualified Bar import qualified Baz instance Bar.Foo Int where foo = 1 instance Baz.Quux Int where foo = 2 -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[Haskell-cafe] cursive to foldr
On Wed, Nov 18, 2009 at 7:43 AM, Ben Millwood hask...@benmachine.co.ukwrote: It looks quite neat to use the Maybe monoid here: import Data.Monoid searchList p = foldr (\x - if p x then mappend (Just [x]) else id) Nothing but it seems that the Maybe Monoid instance keeps this strict. I fiddled with this a bit, and came up with the following: instance (Monoid m) = Monoid (Maybe m) where mempty = Nothing -- as usual mappend (Just x) y = Just $ mappend x (fromMaybe mempty y) mappend Nothing y = y The existing Monoid instance for 'Maybe a' lifts what is logically a Semigroup into a Monoid by extending the domain of the operation with a unit (Nothing). Alas, This is annoyingly not the same behavior as the MonadPlus behavior for Maybe, unlike all of the other cases where MonadPlus and Monoid happen to exist in a manner in which they coincide, and since there is no Semigroup class, it lies and claims that it transforms Monoid m = Monoid (Maybe m). Your version uses mempty from the underlying monoid, so it would break any code that relied on the existing 'lifted Semigroup' interpretation of the Maybe Monoid, which safely operate lift Semigroups-that-claim-to-be-Monoids where mempty = undefined -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
Thanks! Learn something new every day. =) -Edward Kmett On Wed, Nov 18, 2009 at 4:29 PM, David Menendez d...@zednenem.com wrote: On Wed, Nov 18, 2009 at 4:12 PM, Edward Kmett ekm...@gmail.com wrote: Qualified imports are some times problematic when you need to work with classes from the module. You can't define a member of two instances from different two modules that define classes with conflicting member names. This can lead to situations where you have no option but to have orphan instances. module Bar where class Foo a where foo :: a module Baz where class Quux a where foo :: a module Quaffle where import qualified Bar import qualified Baz instance Bar.Foo Int where Bar.foo = 1 -- ^- syntax error. instance Baz.Quux Int where Baz.foo = 2 I suppose this could possibly be fixed if something deep in the parser allowed a QName there. Try Quaffle without the qualifications. module Quaffle where import qualified Bar import qualified Baz instance Bar.Foo Int where foo = 1 instance Baz.Quux Int where foo = 2 -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ http://www.eyrie.org/%7Ezednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: parallel-2.0.0.0
I love the new Eval Applicative! Out of idle curiosity, can parListN be generalized to parTraverseN similar to how parList was generalized to parTraverse? Similarly, parListChunk? -Edward Kmett On Wed, Nov 18, 2009 at 9:21 AM, Simon Marlow marlo...@gmail.com wrote: I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies at all, I'd advise updating to this version of the parallel package. It's not completely API compatible, but if you're just using the supplied Strategies such as parList, the changes should be relatively minor. The Haddock docs include a full description of the changes, reproduced below. Haddock docs are also here, until Hackage catches up: http://www.haskell.org/~simonmar/parallel/index.htmlhttp://www.haskell.org/%7Esimonmar/parallel/index.html The Strategy-using programs I've tried so far go faster. Enjoy! Cheers, Simon - Version 1.x The original Strategies design is described in http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.htmlhttp://www.macs.hw.ac.uk/%7Edsg/gph/papers/html/Strategies/strategies.html and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. Version 2.x Later, during work on the shared-memory implementation of parallelism in GHC, we discovered that the original formulation of Strategies had some problems, in particular it lead to space leaks and difficulties expressing speculative parallelism. Details are in the paper \Runtime Support for Multicore Haskell\ http://www.haskell.org/~simonmar/papers/multicore-ghc.pdfhttp://www.haskell.org/%7Esimonmar/papers/multicore-ghc.pdf . This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously @a - Done@ and is now @a - a...@. This change helps to fix the space leak described in \Runtime Support for Multicore Haskell\. The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a \new\ value after applying a 'Strategy', so that the application can evaluate each spark created by the 'Strategy'. The simple rule is this: you /must/ use the result of applying a 'Strategy' if the strategy creates parallel sparks, and you should probably discard the the original value. If you don't do this, currently it may result in a space leak. In the future (GHC 6.14), it will probably result in lost parallelism instead, as we plan to change GHC so that unreferenced sparks are discarded rather than retained (we can't make this change until most code is switched over to this new version of Strategies, because code using the old verison of Strategies would be broken by the change in policy). The other changes in version 2.x are: * Strategies can now be defined using a convenient Applicative type Eval. e.g. parList s = unEval $ traverse (Par . s) * 'parList' has been generalised to 'parTraverse', which works on any 'Traversable' type. * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', and there are transformation rules that automatically translate e.g. @parList rwnhf@ into a call to the optimised version. * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ package instead. Note that since the 'Strategy' type changed, 'rnf' is no longer a 'Strategy': use 'rdeepseq' instead. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pthread_kill missing?
Am 18.11.2009 um 14:15 schrieb Svein Ove Aas: On Wed, Nov 18, 2009 at 2:03 PM, Gabor Greif ga...@mac.com wrote: PS: I guess some of you will say, use condition variables. But that won't answer my question :-) Actually, I was going to say use throwTo. Is there som reason you have to use the POSIX routines directly instead of using native haskell exceptions? Because I'd like to eventually send signals from outside (e.g. a shell) too. This is in fact a stripped-down version of a real program written in C mainly to demonstrate how much easier it is to get the same functionality in Haskell. How much work would it be to add the pthread signal blocking/sending facility to the unix library? Cheers, Gabor -- Svein Ove Aas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. Bitwise Tricks Techniques
If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. The Art of Computer Programming: Volume 4 Bitwise Tricks Techniques Binary Decision Diagrams Fascicle 1 Donald E. Knuth 2009 Describes basic broadword operations and an important class of data structures that can make computer programs run dozens - even thousands - of times faster. I started a Haskell program using bitwise operations and then discarded them thinking them to low level. I think one of the dangers of Haskell, is that I get carried away with medium and high level abstractions and think everything MUST be done that way. :) -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. Bitwise Tricks Techniques
I can't compare it with Knuth's fascicle, but the FXT book (linked to from http://www.jjj.de/fxt/) has a whole chapter on bit wizardry and is another excellent resource along these lines. On Wed, Nov 18, 2009 at 6:22 PM, Casey Hawthorne cas...@istar.ca wrote: If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. The Art of Computer Programming: Volume 4 Bitwise Tricks Techniques Binary Decision Diagrams Fascicle 1 Donald E. Knuth 2009 Describes basic broadword operations and an important class of data structures that can make computer programs run dozens - even thousands - of times faster. I started a Haskell program using bitwise operations and then discarded them thinking them to low level. I think one of the dangers of Haskell, is that I get carried away with medium and high level abstractions and think everything MUST be done that way. :) -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. Bitwise Tricks Techniques
Thank you for the URL. On Wed, 18 Nov 2009 18:30:31 -0500, you wrote: I can't compare it with Knuth's fascicle, but the FXT book (linked to from http://www.jjj.de/fxt/) has a whole chapter on bit wizardry and is another excellent resource along these lines. On Wed, Nov 18, 2009 at 6:22 PM, Casey Hawthorne cas...@istar.ca wrote: If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. The Art of Computer Programming: Volume 4 Bitwise Tricks Techniques Binary Decision Diagrams Fascicle 1 Donald E. Knuth 2009 Describes basic broadword operations and an important class of data structures that can make computer programs run dozens - even thousands - of times faster. I started a Haskell program using bitwise operations and then discarded them thinking them to low level. I think one of the dangers of Haskell, is that I get carried away with medium and high level abstractions and think everything MUST be done that way. :) -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
Levi Greenspan wrote: What's the status of the TDNR proposal [1]? Personally I think it is a very good idea and I'd like to see it in Haskell'/GHC rather sooner than later. Working around the limitations of the current record system is one of my biggest pain points in Haskell and TDNR would be a major improvement. Thus I wonder if someone is actively working on this proposal? The TDNR proposal really tries to do two separate things: 1. Record syntax for function application. The proposal is to tread x.f or a variation thereof the same as (f x) 2. Type directed name lookup. The proposal is to look up overloaded names based on the type of the first function argument. Why can't these be considered separately? Is there a good reason for not using TDNR in normal function applications? The only argument I can think of (compared to the record syntax) is that it would be a bigger change. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some help needed to start Haskell with Yi
Kapil Hari Paranjape schrieb: Hello, On Sat, 14 Nov 2009, Jaco van Iterson wrote: Only installation with 'cabal install yi' in a Cygwin shell under MS Windows XP ended in: Yi\Prelude.hs:182:9: Duplicate instance declarations: instance Category Accessor.T -- Defined at Yi\Prelude.hs:182:9-38 instance Category Accessor.T -- Defined in data-accessor-0.2.1:Data.Accessor.Private cabal.exe: Error: some packages failed to install: yi-0.6.1 failed during the building phase. The exception was: exit: ExitFailure 1 Seems easy to fix but I can't even find where on my drive I can find the source code. Where is the source? Seems to be that the author defined an orphan instance - something one should never do! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] inversion lists
Ted Zlatanov schrieb: On Mon, 16 Nov 2009 00:03:54 +0300 Eugene Kirpichov ekirpic...@gmail.com wrote: EK 2009/11/15 Michael Mossey m...@alumni.caltech.edu: Can someone tell me if this is correct. I'm guessing that if I represent two sets of integers by Word32 (where ith bit set means i is in the set), then an algorithm to determine if x is a subset of y would go something like (y - x) == (y `exclusiveOr` x) EK It's simpler: x~y == 0 Depending on the OP data set the simple bit vector may be a good strategy, but I wonder if an inversion list would be better? Do you expect long runs of adjacent numbers and gaps? Inversion lists tend to encode those much more efficiently than bit vectors. I'm just now learning Haskell so I don't know enough to show an implementation but inversion lists are very simple conceptually. If your set is (2,3,4,5,8,9,10) the inversion list would be (2,6,8,11). It's easy to generate it from a set of Ord elements. Is inversion list = Gray code ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: parallel-2.0.0.0
Hello, On Wed, Nov 18, 2009 at 02:21:54PM +, Simon Marlow wrote: [...] is now @a - a...@. This change helps to fix the space leak described in \Runtime Support for Multicore Haskell\. The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This [...] I tried to understand the implications of this, read the relevant sections in the paper, and put together a little piece of code: sparkN 0 f = f sparkN !n f = (n + 42) `par` sparkN (n-1) f main = sparkN 1 $ do performGC getLine I compiled that with GHC 6.10.4 and expected to get a huge space leak, which didn't happen. What am I doing wrong? Thanks in advance for any tips. Regards, -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some help needed to start Haskell with Yi
Am Donnerstag 19 November 2009 01:07:37 schrieb Henning Thielemann: Kapil Hari Paranjape schrieb: Hello, On Sat, 14 Nov 2009, Jaco van Iterson wrote: Only installation with 'cabal install yi' in a Cygwin shell under MS Windows XP ended in: Yi\Prelude.hs:182:9: Duplicate instance declarations: instance Category Accessor.T -- Defined at Yi\Prelude.hs:182:9-38 instance Category Accessor.T -- Defined in data-accessor-0.2.1:Data.Accessor.Private cabal.exe: Error: some packages failed to install: yi-0.6.1 failed during the building phase. The exception was: exit: ExitFailure 1 Seems easy to fix but I can't even find where on my drive I can find the source code. Where is the source? Seems to be that the author defined an orphan instance - something one should never do! So what do you do if you need an instance ClassX TypeY but the author of the package that defines TypeY hasn't provided one? You can define an orphan instance or duplicate packageY but with the instance. Both are bad. Providing an orphan instance until packageY has one seems the lesser evil to me. Are there any good options? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some help needed to start Haskell with Yi
On Wed, Nov 18, 2009 at 8:15 PM, Daniel Fischer daniel.is.fisc...@web.dewrote: Am Donnerstag 19 November 2009 01:07:37 schrieb Henning Thielemann: Kapil Hari Paranjape schrieb: Hello, On Sat, 14 Nov 2009, Jaco van Iterson wrote: Only installation with 'cabal install yi' in a Cygwin shell under MS Windows XP ended in: Yi\Prelude.hs:182:9: Duplicate instance declarations: instance Category Accessor.T -- Defined at Yi\Prelude.hs:182:9-38 instance Category Accessor.T -- Defined in data-accessor-0.2.1:Data.Accessor.Private cabal.exe: Error: some packages failed to install: yi-0.6.1 failed during the building phase. The exception was: exit: ExitFailure 1 Seems easy to fix but I can't even find where on my drive I can find the source code. Where is the source? Seems to be that the author defined an orphan instance - something one should never do! So what do you do if you need an instance ClassX TypeY but the author of the package that defines TypeY hasn't provided one? You can define an orphan instance or duplicate packageY but with the instance. Both are bad. Providing an orphan instance until packageY has one seems the lesser evil to me. Are there any good options? Whether it qualifies as 'good' or not, I'm not sure, but I think the standard recommendation is to newtype-wrap the type you want to make an orphan instance of, and make the instance on that (new) type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some help needed to start Haskell with Yi
Daniel Fischer schrieb: Am Donnerstag 19 November 2009 01:07:37 schrieb Henning Thielemann: Seems to be that the author defined an orphan instance - something one should never do! So what do you do if you need an instance ClassX TypeY but the author of the package that defines TypeY hasn't provided one? The author (me) has added the instance after it became aware to him (me) ... You can define an orphan instance or duplicate packageY but with the instance. Both are bad. Providing an orphan instance until packageY has one seems the lesser evil to me. Are there any good options? A separate package for that orphan instance would be the best solution. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some help needed to start Haskell with Yi
Am Donnerstag 19 November 2009 03:03:09 schrieb Henning Thielemann: Daniel Fischer schrieb: Am Donnerstag 19 November 2009 01:07:37 schrieb Henning Thielemann: Seems to be that the author defined an orphan instance - something one should never do! So what do you do if you need an instance ClassX TypeY but the author of the package that defines TypeY hasn't provided one? The author (me) has added the instance after it became aware to him (me) ... Of course :) You can define an orphan instance or duplicate packageY but with the instance. Both are bad. Providing an orphan instance until packageY has one seems the lesser evil to me. Are there any good options? A separate package for that orphan instance would be the best solution. I'm not sure that's really better. With a separate package, you'd have dependencies packageY, orphanInstance. When a new version of packageY with the instance is uploaded, things break in the same way. The fix is easy either way, delete the dependency orphanInstance or delete the orphan instance, but with a separate package, that stays around polluting hackage - or is there now a way to remove packages from hackage swiftly? Perhaps the very best method is to contact the author/maintainer of packageY and say you need the instance. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: inversion lists
On Thu, 19 Nov 2009 01:13:23 +0100 Henning Thielemann lemm...@henning-thielemann.de wrote: HT Ted Zlatanov schrieb: On Mon, 16 Nov 2009 00:03:54 +0300 Eugene Kirpichov ekirpic...@gmail.com wrote: EK 2009/11/15 Michael Mossey m...@alumni.caltech.edu: Can someone tell me if this is correct. I'm guessing that if I represent two sets of integers by Word32 (where ith bit set means i is in the set), then an algorithm to determine if x is a subset of y would go something like (y - x) == (y `exclusiveOr` x) EK It's simpler: x~y == 0 Depending on the OP data set the simple bit vector may be a good strategy, but I wonder if an inversion list would be better? Do you expect long runs of adjacent numbers and gaps? Inversion lists tend to encode those much more efficiently than bit vectors. I'm just now learning Haskell so I don't know enough to show an implementation but inversion lists are very simple conceptually. If your set is (2,3,4,5,8,9,10) the inversion list would be (2,6,8,11). It's easy to generate it from a set of Ord elements. HT Is inversion list = Gray code ? No. An inversion list contains the boundaries of all the continuous intervals in the input. In other words, any time you see input of [n,n+1, n+2...n+k,n+m...] where m k+1 your inversion list gets the entries n and n+k+1. As I said I'm just starting to learn Haskell so I can't give a proper implementation: isSuccessor:: (Num a) = a - a - Bool isSuccessor x y = x+1 == y inversion :: (Num a) = [a] - [a] inversion [] = [] inversion (x:xs) = x:(inversion . dropWhile isSuccessor xs) The above is obviously broken, but the idea is to drop successive elements. I don't know how to do that in a predicate for dropWhile so I may need a different function from Data.List or elsewhere. Ted ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: inversion lists
Am Donnerstag 19 November 2009 03:57:56 schrieb Ted Zlatanov: On Thu, 19 Nov 2009 01:13:23 +0100 Henning Thielemann lemm...@henning-thielemann.de wrote: HT Ted Zlatanov schrieb: On Mon, 16 Nov 2009 00:03:54 +0300 Eugene Kirpichov ekirpic...@gmail.com wrote: EK 2009/11/15 Michael Mossey m...@alumni.caltech.edu: Can someone tell me if this is correct. I'm guessing that if I represent two sets of integers by Word32 (where ith bit set means i is in the set), then an algorithm to determine if x is a subset of y would go something like (y - x) == (y `exclusiveOr` x) EK It's simpler: x~y == 0 Depending on the OP data set the simple bit vector may be a good strategy, but I wonder if an inversion list would be better? Do you expect long runs of adjacent numbers and gaps? Inversion lists tend to encode those much more efficiently than bit vectors. I'm just now learning Haskell so I don't know enough to show an implementation but inversion lists are very simple conceptually. If your set is (2,3,4,5,8,9,10) the inversion list would be (2,6,8,11). It's easy to generate it from a set of Ord elements. HT Is inversion list = Gray code ? No. An inversion list contains the boundaries of all the continuous intervals in the input. In other words, any time you see input of [n,n+1, n+2...n+k,n+m...] where m k+1 your inversion list gets the entries n and n+k+1. As I said I'm just starting to learn Haskell so I can't give a proper implementation: isSuccessor:: (Num a) = a - a - Bool isSuccessor x y = x+1 == y inversion :: (Num a) = [a] - [a] inversion [] = [] inversion (x:xs) = x:(inversion . dropWhile isSuccessor xs) The above is obviously broken, but the idea is to drop successive elements. I don't know how to do that in a predicate for dropWhile so I may need a different function from Data.List or elsewhere. Ted like: h :: Num a = a - [a] - [a] h x (y:ys) | x+1 == y = x:ys h x zs = x:(x+1):zs invlist = foldr h [] ghci invlist [2,3,4,5,8,9,10] [2,6,8,11] ghci invlist [4] [4,5] ghci invlist [1,2,3,4,7,8,9,13,14,15,20,22] [1,5,7,10,13,16,20,21,22,23] ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] faster compiling for ghc
A good trick is to use NOINLINE and restricted module exports to ensure
changes in one module don't cause others to be recompiled. A common
idiom is something like.
module TypeAnalysis(typeAnalyze) where
where the module is a fairly large complicated beast, but it just has
the single entry point of typeAnalyze, by putting a
{-# NOINLINE typeAnalyze #-} in there, you can be sure that changes to
the module don't cause other modules to be recompiled in general.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pthread_kill missing?
Gabor Greif wrote: Because I'd like to eventually send signals from outside (e.g. a shell) too. This is in fact a stripped-down version of a real program written in C mainly to demonstrate how much easier it is to get the same functionality in Haskell. Much easier then to install a signal handler the usual way? This signal handler can in turn use standard asynchronous exceptions to send signals on to the appropriate forkIOed threads... Of course this is a different mechanism, but it feels much more idiomatic vis a vis haskell concurrency and the GHC runtime. --S ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal + gfortran?
Hi, I want to set up a build that compiles fortran sources in addition to the Haskell, and which maybe also eventually checks for the existence of a library or two (specifically, LAPACK and BLAS). Does anyone here have a suggestion for where I should be looking to figure out how to do this, such as a package which uses such a setup that would provide an example? Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
