Re: [Haskell-cafe] Laziness enhances composability: an example
Thomas Davie wrote: On 9 Jul 2009, at 14:55, Cristiano Paris wrote: I'm wondering what a good example of why laziness enhances composability would be. I'm specifically looking for something that can't implemented in Python with iterators (at least not elegantly), but can actually be implemented in Haskell. Pretty much anything that uses tying the knot is very difficult to implement in a non-lazy language without a lot of indirection. I disagree; mutation can work rather well instead. One application I work on has to parse input containing items with forward and backward references using keys into a graph of objects, a classic tying-the-knot problem. However, we are not using a lazy language, so have only one procedure to create or look up the object corresponding to an item, by key. Parsing references to an item will just store the returned address, but parsing the definition of an item will mutate the object to fill in the data. The effect is that all the references end up as pointers to the right objects, and the objects for undefined items end up keeping their default values (caught by later checks). Situations like that make either mutation or laziness very handy, and if one cannot imagine the tying the knot technique then mutation looks like the only good way. No wonder people don't get pure FP! ;-) -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Sometimes I wish there was a global variable
Ok, replying to the list this time. Darn Thunderbird not reading my
mind again.
Rafael Cunha de Almeida wrote:
Maurício wrote:
In one module, you can write:
--
giveMeFunctions = do {
newIORef ...
newIORef ...
newIORef ...
(...)
let f1 = ...
let f2 = ...
return (f1,f2)
--
and in the main:
(keyboardMouse,display) - giveMeFunctions
Doing it like that I could have all the definitions in one module, but
it doesn't solve another important problem: keyboardMouse and display
functions have to have as many parameters as there are IORefs.
I don't think so. I think M means the two functions are closures
capturing all the IORefs, i.e. they know which IORefs they refer to. In
OO terms, the two functions together are the two methods of an object
that contains the IORefs as fields, and you needn't pass those IORefs
in. Note that calling giveMeFunctions twice will get you two distinct
objects, not the same one twice.
--
src/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foldl vs foldl'
Bas van Dijk wrote: On Wed, Nov 5, 2008 at 12:43 AM, Bas van Dijk [EMAIL PROTECTED] wrote: 2008/11/5 Daryoush Mehrtash [EMAIL PROTECTED]: Are there cases (function or list) where the result of foldl (or foldr)would be different that foldl' (or foldr')? Maybe this wiki article I wrote some time ago will answer your question: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl' Oops that link should be: http://haskell.org/haskellwiki/Foldr_Foldl_Foldl%27 I have an idea for the foldl diagram. If you rotate the RHS 90deg clockwise, it slopes the same way as the original list, but the 'f's are still rotated sideways to signify which their inputs are. That makes the relationship between imperative accumulator loops and foldl a bit clearer to me, as well as the relationship between the list and the recursion structure. -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: is there a way to pretty print a module?
Anatoly Yakovenko wrote: is there a way to pretty print a module? like: module Main where import Language.Haskell.TH main = do print $ pprint Main haskell-src should be able to do that. I think haskell-src requires you to read the module at run time. I want to embed the contents of the module in my program. Basically a program that can print itself. This is rather like the idea of a quine; a program the prints itself out without referring directly to its own source code. The usual Haskell quine is: putStrLn$(\s-s++show s)putStrLn$(\\s-s++show s) If merely returning the source code is enough then you can do: (\s-s++show s)(\\s-s++show s) It could be more elegant if \ weren't both lambda and string escape. -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [] vs [()]
Sam Danielson wrote: The [] constructor takes no arguments and is like Nothing in the Maybe type. The list : (cons) infix constructor takes two arguments, an element of type a and a list of type a, to construct a new list. Compare to Maybe. data []a = [] | a : [a] data Maybe a = Nothing | Just a Another way of saying [()] is ():[] which, comparing with the Maybe type, is similar to saying Just () but Just only takes one argument where (:) takes two. Both List and Maybe are containers that have a null constructor, namely [] and Nothing. ():[] contains () similar to how Just () contains (). You can make your own list type and put () in it as follows. Or, in Monad terms: [()] and Just () are both return () in their respective Monads. [] and Nothing are both mzero in their respective MonadsPluses. (Both are also fail in their respective Monads, but I find fail's presence in Monad a bit inelegant, though handy.) -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shooting your self in the foot with Haskell
John Van Enk wrote: On Sun, Oct 5, 2008 at 11:21 PM, John Van Enk [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Sun, Oct 5, 2008 at 6:22 PM, Simon Richard Clarkstone [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: BTW, these could go on the wiki. I'll see about putting them there. :) http://haskell.org/haskellwiki/Shooting_your_self_in_the_foot This needs to be cleaned up a little (lots of dups, though they are all great). You missed my one, though I think the ballistics algebra one is better. ISTR that the point of the original list was originally to show that, though you can screw up with C, with every other language you can screw up in far more complicated and inscrutable ways. Ballistics algebra is indeed a way to screw up that is not possible in C. (Darnit Thunderbird, why don't you DWIM when I hit reply or reply-all?) -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Shooting your self in the foot with Haskell
John Van Enk wrote: You shoot the gun, but the bullet gets trapped in the IO monad. The community points you at the paper Bang-bang-patterns: expressing lethal weaponry in the Haskell typesystem. Your head explodes. BTW, these could go on the wiki. -- src/ -XIncomprehensibleTypes Equivalent to all of: -fallow-inconvinient-types, -XOmnipotentInstances, -XFunkyFunctors, -XSuperTuringTypes, -XErraticTypeClasses, -XCoAntiRetroHyperArrows ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell-Cafe Digest, Vol 61, Issue 49
Mark Snyder wrote: whoops! wow, wrong message to reply to... please disregard the previous. Apologies, ~Mark Snyder [Snip entire digest] Ouch. When apologising for quoting the entire digest, quoting your entire previous message doesn't really help the situation :-). grin -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [m..n] question
Jonathan Cast wrote: On Sat, 2008-09-27 at 02:09 +0100, Simon Richard Clarkstone wrote: Darn, I sent this as personal mail the first time. Evan Laforge wrote: In Haskell, The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3]. The list is empty if e1 e3. I like it, since it means that things like [n .. n + length m - 1] work as expected when m is []. Or say 'map (array!) [bsearch x .. bsearch y - 1]'. Tangent: Of course, I would prefer the range be half-open, which is a pretty consistent standard in the rest of the world. I've had a number of off by one errors from this, and from Array.bounds. I guess it's too late to fix those, though, even if there were agreement that they need to be fixed. It causes problems with types that have an upper bound. You can't express Haskell's [False .. True] as a half-open range for example. [False .. ] works great, though, whether ranges are closed or half-open. You get problems though if you want to tell a function about a range, passing in a low and a high by some means, and it is expecting a half-open range, but you want to tell it [False..]. For example, creating a new array. BTW, why isn't [..] the notation for the entirety of a Bounded type? --- This mailing list is odd; thunderbird defaults to replying to sender rather than to the whole list. -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [m..n] question
Darn, I sent this as personal mail the first time. Evan Laforge wrote: In Haskell, The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3]. The list is empty if e1 e3. I like it, since it means that things like [n .. n + length m - 1] work as expected when m is []. Or say 'map (array!) [bsearch x .. bsearch y - 1]'. Tangent: Of course, I would prefer the range be half-open, which is a pretty consistent standard in the rest of the world. I've had a number of off by one errors from this, and from Array.bounds. I guess it's too late to fix those, though, even if there were agreement that they need to be fixed. It causes problems with types that have an upper bound. You can't express Haskell's [False .. True] as a half-open range for example. --- One solution would be a new syntax for half-open ranges distinct from that for closed ranges, or maybe a couple of operators. Sketching without a compiler: lo . hi = takeWhile ( hi) [lo ..] data EnumStart a = a : a (lo : mid) : hi = takeWhile ( hi) [lo, mid ..] So you can do things like (0 . 10) or (0 : 2 : 10) Or one could use the same operator for both, if one defined something like: class OpenEnum bot top where (.) :: bot - top - [top] instance (Enum e) = OpenEnum e e where lo . hi = takeWhile ( hi) [lo ..] instance (Enum e) = OpenEnum (EnumStart a) a ... (lo : mid) . hi = takeWhile ( hi) [lo, mid ..] A better choice of line noise for the operator could still be made though. -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] message passing style in Monad
jinjing wrote: I found that as I can do xs.map(+1).sort by redefine . to be a . f = f a infixl 9 . This looks rather like ($), but backwards. I believe the F# name for this operator is (|), which is also a legal name for it in Haskell. Odd, since (|) alone isn't legal. Calling it (.) will confuse the heck out of anyone who maintains your code though, and make any transfer of code between your projects and other people's liable to introduce bugs. I can also do readFile readme.markdown . lines . length by making a . b = a .liftM b infixl 9 . Kinda annoying, but the option is there. Now that looks more interesting. Another name for it is (=^), since it is like (=) but lifts its right argument. I know the Fudgets library uses ^ in operators for a similar lifting meaning. -- src/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
