Re: [Haskell-cafe] Elevator pitch for Haskell.

2007-09-10 Thread Kim-Ee Yeoh
Devin Mullins wrote: > > As for the latter, the reason I hear most often is "I want to be able to > use the language at my job."* > > -- snip -- > * This is somewhat odd, as the strong majority of vocal Rubyists /are/ > using it at their job. > Not without risk though. Their necks get wrung

Re: [Haskell-cafe] Question of a manual computation on Reader Monad.

2007-08-25 Thread Kim-Ee Yeoh
一首诗 wrote: > > runReader (do { b <- Reader $ show; return b } ) -- This is the initial > expression, it should equals "show" > > runReader (Reader $ show >>= \b -> return b) -- remove do notion > I'm not sure that's the right un-do-ization. It so happens that the exponent monad ((->) r) a

Re: [Haskell-cafe] Compile-time v run-time

2007-08-17 Thread Kim-Ee Yeoh
If RAM was treated as an extension of non-volatile storage instead of the other way round, we'd already be there. Put another way, would "suspending" program to disk achieve the same results? Jon Fairbairn wrote: > > Something I've wanted to experiment with for a long time and > never got r

Re: [Haskell-cafe] Hints for Euler Problem 11

2007-08-17 Thread Kim-Ee Yeoh
Lennart Augustsson wrote: > > On 8/17/07, Kim-Ee Yeoh <[EMAIL PROTECTED]> wrote: >> How much static evaluation do you want to see >> in Haskell? > > I'd like to see as much static evaluation as is practically possible. > Yes but not in (the language form

Re: [Haskell-cafe] Re: Bathroom reading

2007-08-17 Thread Kim-Ee Yeoh
ok-4 wrote: > > Someone mentioned the "Blow your mind" page. > One example there really caught my attention. > "1234567" => ("1357","246") > foldr (\a ~(x,y) -> (a:y,x)) ([],[]) > > I've known about lazy match since an early version of the Haskell > report, but have never actually used it.

Re: [Haskell-cafe] Hints for Euler Problem 11

2007-08-17 Thread Kim-Ee Yeoh
The compiler dumps are illuminating, thank you. I'm afraid I don't always compile under -O. In fact I never debug with -O. I see now what I'm missing. (Pain, grief, despair.) Ketil Malde wrote: > > On Thu, 2007-08-16 at 12:50 -0700, Kim-Ee Yeoh wrote: >> A

Re: [Haskell-cafe] Hints for Euler Problem 11

2007-08-17 Thread Kim-Ee Yeoh
Lennart Augustsson wrote: > > On 8/16/07, Kim-Ee Yeoh <[EMAIL PROTECTED]> wrote: >> 'Course not. The (++) function like all Haskell functions is only a >> /promise/ to do its job. What does "assembling at compile time" >> mean here: >> >>

Re: [Haskell-cafe] Hints for Euler Problem 11

2007-08-16 Thread Kim-Ee Yeoh
Aaron Denney wrote: > > On 2007-08-15, Pekka Karjalainen <[EMAIL PROTECTED]> wrote: >> A little style issue here on the side, if I may. You don't need to use >> (++) to join multiline string literals. >> >> text = "If you want to have multiline string literals \ >>\in your source code, y

Re: [Haskell-cafe] Explaining monads

2007-08-16 Thread Kim-Ee Yeoh
Paul Hudak wrote: > > [I]n the one-of-many ways that I view monads, a monad is just a high-order > function that abstracts away function composition. In particular, if I > have an action f, and an action g, I can think of them as recipes, because > I can combine them via f >>= g. It's only aft

Re: [Haskell-cafe] Explaining monads

2007-08-14 Thread Kim-Ee Yeoh
Ronald Guida wrote: > > Here is the brief explanation I came up with: > > Arrows and monads are abstract data types used to construct Domain > > Specific Embedded Languages (DSELs) within Haskel. A simple arrow > > provides a closed DSEL. A monad is a special type of arrow that > > creates

Re: [Haskell-cafe] Explaining monads

2007-08-13 Thread Kim-Ee Yeoh
Ronald Guida wrote: > > Given the question "What is a Monad", I would have to say "A Monad is > a device for sequencing side-effects." > There are side-effects and there are side-effects. If the only monad you use is Maybe, the only side-effect you get is a slight warming of the CPU. Dave Men

Re: [Haskell-cafe] Explaining monads

2007-08-12 Thread Kim-Ee Yeoh
David Menendez wrote: > > This is probably because no one has found a compelling use case for > comonadic-style programming in Haskell. There have been some > interesting papers, such as "Comonadic functional attribute > evaluation" by Uustalu and Vene, but nothing as compelling as Wadler's > "M

Re: [Haskell-cafe] Explaining monads

2007-08-11 Thread Kim-Ee Yeoh
Ronald Guida wrote: > > Here's my interpretation of the table: > > -- > Structure | Subject | Action| Verb | Result > +--+++-- > function| a | a-

Re: [Haskell-cafe] Explaining monads

2007-08-10 Thread Kim-Ee Yeoh
Brian Brunswick-5 wrote: > > g f ??? g ??? f > > application a a->b flip ($) b > monad bind m a a->m b>>= m b > comonad cobind w a w a->b=>> w b > arrowarr a b arr b c >

Re: [Haskell-cafe] Monad Description For Imperative Programmer

2007-08-08 Thread Kim-Ee Yeoh
Seth Gordon wrote: > > Functors are a generalization from lists to "things that can be mapped > over" in general, and then monads are a generalization of functors. > Way to go! That way lies true co/monadic enlightenment. Put another way, monads are no more about (only) IO/sequencing than fmap

Re: [Haskell-cafe] FW: RE Monad Description For Imperative Programmer

2007-08-08 Thread Kim-Ee Yeoh
Claus Reinke wrote: > > there is usually a way to interpret monadic structures built in > this way (a 'run' operation of some kind). > The "run" operation of type (m a -> a) is the (comonadic) coreturn. Many monads are almost comonads too, for a meaning of "almost" to be made precise. Claus

<    1   2