Yitzchak Gale wrote:
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Please no.
The last thing haskell needs is more dangerous semantically broken
non-referentially-transparent lazy IO structures.
Jules
___
Hello folks,
Prompted by Ashley's proposal for Category class, I came up with the following
module, which gives a summary of the overloading situation in the base package.
Maybe it can help people find their way through all the available names...
Failing that it surely was fun to come up with. :)
PR Stanley wrote:
Thanks for the very clear explanation. More questions:
What is the role of ?
How is different to =? I am aware that = is used for
sequencing parsers but that's all I know about it.
Thanks, Paul
foo = bar
executes the action foo and passes its result to the function bar
I wrote:
...a tool for recursing through directories...
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Bryan O'Sullivan wrote:
See System.FilePath.Find in
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.2
Not a very good idea.
I wrote:
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Jules Bean wrote:
Please no.
The last thing haskell needs is more dangerous semantically broken
non-referentially-transparent lazy IO structures.
Agreed. I would definitely not want it to be a
Andrew Coppin writes:
PR Stanley wrote:
What is the role of ?
How is different to =? I am aware that = is used for
sequencing parsers but that's all I know about it.
foo = bar
executes the action foo and passes its result to the function bar
(which must then return another action, which
I wrote:
...a tool for recursing through directories...
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Bryan O'Sullivan wrote:
See System.FilePath.Find in
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.2
-- List all directories
Dear Haskellers,
I have been trying my best to read about Haskell from the various
tutorials available on the internet and blogs. I havent been following
YAHT properly, so its always been learning from 'bits and pieces'
scattered around.
For most languages (like C/C++/Ruby/Python), the above
Hi
Then, I set out to learn Monads + Category Theory from a Math
perspective.
This is where you went wrong. I know none of this stuff and am
perfectly happy with IO in Haskell. Read
http://www.haskell.org/haskellwiki/Monads_as_Containers and then read
lots of other Monad tutorials for Haskell.
Yitzchak Gale wrote:
I wrote:
...a tool for recursing through directories...
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
Bryan O'Sullivan wrote:
See System.FilePath.Find in
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.2
--
Vimal wrote:
I like learning by
comparison with other similar languages. This approach worked for me
when I tried learning Python+Perl together. The nicer syntax and
easier object-orientedness made me leave Perl behind and pursue
Python.
I also tried it for Haskell (Lisp+OCaml+Haskell together).
Vimal wrote:
I have been trying my best to read about Haskell from the various
tutorials available on the internet and blogs.
[...]
So, I requested my institute to buy Dr. Graham Hutton's book. I would
be getting hold of that quite soon, and am willing to start from the
beginning.
IMHO, the
Hi Vimal
I didnt want to repeat that mistake, so I made sure I would learn IO
in Haskell, which initially turned out to be a disaster, due to the
'Moands' which sounded like 'Go Mads' to me.
Then, I set out to learn Monads + Category Theory from a Math
perspective. And since I haven't been
I write a lot of programs that build bitmapped images. (Some of you may
remember the Chaos Pendulum Simulator...) Currently, all of these
programs work by writing the final image data to a PPM file on disk.
(Because that's the only way I can figure out to do something *useful*
with the data!)
I just started working in Haskell about 2-3 months ago, and I'm loving it.
I've programmed a lot in Scheme which I learned my freshman year in college,
so that helped a lot with the difference between functional and oop
languages, but as Andrew Coppin mentioned, Haskell is quite different even
On Sunday 14 October 2007 13:31:56 Andrew Coppin wrote:
PS. I've investigated existing APIs and I'm not seeing anything that
looks useful. Lots of support for drawing lines and arcs and so on, but
not for plotting individual pixels.
I highly recommend OpenGL. Even if you are just filling
David Stigant wrote:
Haskell programs tend to be structured to restrict IO to the surface
level of the program, and use purely functional ideas to solve the
meat of the problem. This seems to be one of the major design features
of the language.
Yep, that's the idea. :-D
However, most
Jon Harrop wrote:
On Sunday 14 October 2007 13:31:56 Andrew Coppin wrote:
PS. I've investigated existing APIs and I'm not seeing anything that
looks useful. Lots of support for drawing lines and arcs and so on, but
not for plotting individual pixels.
I highly recommend OpenGL. Even if
Cool! Lots of opinion. Let me consider them one by one:
@Neil:
This is where you went wrong. I know none of this stuff and am
perfectly happy with IO in Haskell. Read
@Andrew:
This probably works quite well for mainstream programming languages
(since they're all so similar), but is unlikely to work at all for
Haskell (since, as far as I know, no other programming language on Earth
is remotely like it - Miranda excluded). Even Lisp and Erland are
nothing
In my opinion (other may think differently) it is not a good idea to
learn IO by starting with trying to grasp the theoretical foundation for
monads. In the beginning you should just view the IO monad as Haskell's
way of doing imperative IO stuff. When you feel comfortable with Haskell
IO,
I think you have got a very good point in your mail that I overlooked
all along ... Why was Haskell created? is a question that I havent
tried looking for a answer :)
I also agree about this, so I started looking for small projects on which to
cut my teeth and really learn the basic concepts in
Vimal wrote:
Wikipedia. Open an article, and you branch out like anything.
Curiosity does kill the cat :(
Yeah, this has always been a problem with me. Its like browsing
Whenever I do this, I usually end up reading about something utterly
unrelated. (Actually, I usually end up reading
Hi ok,
On Fri, Oct 05, 2007 at 11:04:06AM +1300, ok wrote:
UltraSPARC II, Solaris 2.10, gcc 4.0.4 (gccfss),
Haskell GHC 6.6.1 binary release.
The Sparc/Solaris ports has probably bitrotted. If you do an
unregisterised build instead then it should work:
Vimal wrote:
IO isnt the only problem. Monads + how to define your own Monads etc.
Since Monad's arent just for IO, where else could it be used? (e.g.
Stateful functions), but is that it? Is it possible for me to come
up with an instance of a Monad to solve _my_ problem? Thats the kind
of
On Wed, Oct 10, 2007 at 05:05:28PM +0100, Magnus Therning wrote:
I've almost reached a state where I wouldn't be ashamed of sharing the
code so I looked into my options of free hosting.
It seems I only have one option for publishing the code:
- Request a project on code.haskell.org.
Vimal wrote:
I think you have got a very good point in your mail that I overlooked
all along ... Why was Haskell created? is a question that I havent
tried looking for a answer :)
To avoid success at all costs?
(No, seriously. The basic idea was that there used to be about two-dozen
Vimal wrote:
@Andrew:
But, being a computer science student, I think I need to look into it too!
I like the quote found on this site: http://patryshev.com/monad/m-intro.html
quote
Monads in programming seem to be the most mysterious notion of the century.
I find two reasons for this:
*
Hi Yitzchak,
On Sun, Oct 14, 2007 at 11:33:38AM +0200, Yitzchak Gale wrote:
Here it is critical that ListT be taken from
http://haskell.org/haskellwiki/ListT_done_right
and not the broken implementation that comes with mtl.
(Finally fixed in 6.8? Please?)
mtl is not part of GHC
On 10/14/07, Vimal [EMAIL PROTECTED] wrote:
Dear Haskellers,
I have been trying my best to read about Haskell from the various
tutorials available on the internet and blogs. I havent been following
YAHT properly, so its always been learning from 'bits and pieces'
scattered around.
You might
On 10/14/07, Vimal [EMAIL PROTECTED] wrote:
IO isnt the only problem. Monads + how to define your own Monads etc.
Since Monad's arent just for IO, where else could it be used? (e.g.
Stateful functions), but is that it? Is it possible for me to come
up with an instance of a Monad to solve _my_
I will be impolite.
Andrew Coppin says:
For what it's worth, a category is a class bearing some additional
structure. A class is exactly like a set, except that all sets are
classes, but only some classes are also sets. There *is* a reason for
this, but nobody knows what it is. (They say it's
On 14/10/2007, Andrew Coppin [EMAIL PROTECTED] wrote:
Jon Harrop wrote:
On Sunday 14 October 2007 13:31:56 Andrew Coppin wrote:
PS. I've investigated existing APIs and I'm not seeing anything that
looks useful. Lots of support for drawing lines and arcs and so on, but
not for plotting
[EMAIL PROTECTED] wrote:
I will be impolite.
If this were the first posting of A.C., I would suspect that he is
pulling
my leg, that his brilliant sense of humour surpasses my comprehension, so
I should be filled-up with deep respect for such a wonderful mind. But
enough is enough. Now, would
[EMAIL PROTECTED] wrote:
I will be impolite.
There was no need to.
Andrew Coppin wrote:
OK. I get the message. I'm unsubscribing now...
There was no need to.
Please, let's keep haskell-cafe a friendly place, as it's always been.
When someone posts inaccurate (or even wrong) facts:
Attack
The Mersenne twister should be able to split better than most. but I'm not
sure how efficient it is.
On 10/14/07, Isaac Dupree [EMAIL PROTECTED] wrote:
Don Stewart wrote:
I've seen similar results switching to the SIMD mersenne twister C
implementation for randoms:
On 10/14/07, [EMAIL PROTECTED]
I know that asking helpful humans is nicer than reading docs, but the latter
is usually more instructive, and often more efficient.
Sorry, but from my newbie point of view, I think the docs are
sometimes poor and lacking. After seeing the docs, I might want to ask
You don't need to unsubscribe. Just avoid posting things that are totally
wrong (at least without a warning).
-- Lennart
On 10/14/07, Andrew Coppin [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I will be impolite.
If this were the first posting of A.C., I would suspect that he is
On 10/14/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
You don't need to unsubscribe. Just avoid posting things that are totally
wrong (at least without a warning).
How would he know they're totally wrong ?
___
Haskell-Cafe mailing list
On 10/14/07, david48 [EMAIL PROTECTED] wrote:
On 10/14/07, Lennart Augustsson [EMAIL PROTECTED] wrote:
You don't need to unsubscribe. Just avoid posting things that are totally
wrong (at least without a warning).
How would he know they're totally wrong ?
Thinking before hitting the Send
Roberto Zunino writes:
[EMAIL PROTECTED] wrote:
...
Andrew Coppin wrote:
OK. I get the message. I'm unsubscribing now...
There was no need to.
Please, let's keep haskell-cafe a friendly place, as it's always been.
Yes.
I would add, friendly and USEFUL, as it's always been. It was not
I say someone binds SDL[1]. (If it hasn't been done already.)
Ask and you shall receive:
http://darcs.haskell.org/~lemmih/hsSDL/
I use those SDL bindings to plot pixels with OpenGL and play with 3D
stuff in Haskell.
___
Haskell-Cafe mailing list
Yitzchak Gale wrote:
Your library is very nice. But - it suffers from the
same problem. You use unsafe IO operations to build
a lazy IO list, and we all know what grief that can
lead to.
This is little different from the approach taken by Python's os.walk,
which lazily yields the contents of
Andrew said:
Oh, and the irony of using OpenGL (an API of unimaginable complexity) just to
write pixels to the screen. Isn't that kind of like using a thermonuclear
device to crack a nut?
Saying that using OpenGL to write pixels to the screen is like using a
thermonuclear device to crack a
On Sun, 14 Oct 2007, Andrew Coppin wrote:
Vimal wrote:
I like learning by
comparison with other similar languages. This approach worked for me
when I tried learning Python+Perl together. The nicer syntax and
easier object-orientedness made me leave Perl behind and pursue
Python.
I also tried
most widely-used programs (ex: web browsers, word processors, email
programs, data bases, IDEs) tend to be 90% IO and 10% (or less) computation.
This can make Haskell quite unweildy for solving these types of problems.
On the otherhand, writing something like a compiler (which requires a small
You're picking on Andrew Coppin? That's insane. He's got a sense of
humour, and he's a lay (non-phd) person.
Honestly, in one thread you've got Haskell is misunderstood! Its the
greatest language in the world! Why does no-one use it and in
another you're insulting one of the few non-phds
On Sun, 14 Oct 2007, David Stigant wrote:
However, most widely-used programs (ex: web browsers, word processors,
email programs, data bases, IDEs) tend to be 90% IO and 10% (or less)
computation.
No, they don't. They look it, but there's always a fair amount of
computation going on to
I'm also a Haskell no-so-new-anymore-bie, and for me, understanding
monads was a question of first reading the available docs, especially
http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html
and http://haskell.org/haskellwiki/IO_inside,
plus reading the Haskell School
Brian Hurt writes:
I'm going to offer an opinion here that's likely to be controversial (in
this forum): people new to functional programming shouldn't learn Haskell
first.
Great! So, there are at least two of us!
They should start with either Ocaml or SML first.
Or Scheme.
Or *any*
Interesting! I just wanted to reply (although Andrew Coppin must have
unsubscribed by now...) that I have an application that plots pixels
using OpenGL (it's actually not that hard, just visit the new Haskell
OpenGL page, and look at the examples given, e.g.
Brian Hurt wrote:
I mean, contemplate this trivial exercise for a moment: write a program
that reads from stdin a series of numbers (one number per line), and
writes out the sum of the last n numbers. This is a trivial problem,
and I have no doubt that someone who knows Haskell better than I
Hi Ian, thanks for responding to my plea!
I am renaming this thread and moving it to libraries.
Please respond there.
I wrote:
http://haskell.org/haskellwiki/ListT_done_right
and not the broken implementation that comes with mtl.
(Finally fixed in 6.8? Please?)
Ian Lynagh wrote:
If you want
Correction, I'm also very interested in Haskell, and I even don't have a
bachelor degree :-) I'm a completely self-educated kind-a-guy...
Anyway, IMHO Haskell rocks! A year ago I kind of started to hate writing
code, and that after 25 years of coding in imperative and
object-oriented
Or F#, if you know C#, which is the OCaml for the .NET world.
Now I immediately went from C/C++/C# to Haskell, and yes, that was (is)
hard. For me, the book Haskell School of Expression did it... All you
need is a good book and lots of patience...
Brian Hurt wrote:
On Sun, 14 Oct 2007,
On Sun, 14 Oct 2007 15:22:13 +0100
Ian Lynagh [EMAIL PROTECTED] wrote:
We could perhaps have web pages on projects.haskell.org, and some sort
of bug tracker on bugs.haskell.org (or perhaps trac.haskell.org etc).
Some days ago I stumbled upon Redmine tracker (http://redmine.org/)
written in
Hi apfelmus,
I wrote:
...a tool for recursing through directories...
How about a built-in function that represents a directory tree
as a lazy Data.Tree?
-- List all directories in the tree rooted at the given path
traverseDirectories :: MonadIO m =
TraversalDirection - FilePath - ListT m
apfelmus wrote:
I mean, contemplate this trivial exercise for a moment: write a program
that reads from stdin a series of numbers (one number per line), and
writes out the sum of the last n numbers. This is a trivial problem,
and I have no doubt that someone who knows Haskell better than
Hi Bryan,
You wrote:
This is little different from the approach taken by Python's os.walk,
which lazily yields the contents of a directory tree as it traverses it.
I'm a little unclear on why one appears good in your eyes, while the
other is not, beyond perhaps the depth/breadth knob and
On 10/14/07, Yitzchak Gale [EMAIL PROTECTED] wrote:
Not very much, I suspect. That monad really is broken -
it's not a monad at all.
Depending on your point of view, ListT isn't broken. It correctly
transforms commutative monads into monads. The problem is that you
can't express commutative
On Sun, 2007-10-14 at 15:22 +0100, Andrew Coppin wrote:
Vimal wrote:
I think you have got a very good point in your mail that I overlooked
all along ... Why was Haskell created? is a question that I havent
tried looking for a answer :)
To avoid success at all costs?
(No,
Yitzchak Gale wrote:
I do think that it is much better to provide IO laziness
using monad transformers (or whatever) rather than
unsafe IO.
That's fair enough. I think it would be great if you were to turn your
ideas into a library and provide a few examples of its use.
b
On Sun, 14 Oct 2007, Bryan O'Sullivan wrote:
Yitzchak Gale wrote:
I do think that it is much better to provide IO laziness
using monad transformers (or whatever) rather than
unsafe IO.
That's fair enough. I think it would be great if you were to turn your ideas
into a library and provide
On 10/14/07, Prabhakar Ragde [EMAIL PROTECTED] wrote:
main n = print . sum . map read . take n . reverse . lines = getContents
Could someone describe succinctly how to compute the space complexity of
this program, if there are m lines of input and m n? Many thanks. --PR
'reverse' needs to
On 10/14/07, Yitzchak Gale [EMAIL PROTECTED] wrote:
Interesting. What do you mean by a commutative monad?
It can't be a monad with some sort of additional commutative
law, because the old ListT doesn't even satisfy the monad
laws. Or does it in some sense?
If m is a commutative monad, then
Correction, I'm also very interested in Haskell, and I even don't have a
bachelor degree :-) I'm a completely self-educated kind-a-guy...
That's true, and actually you and Andrew are two of the people whose
opinions I respect the most. Well, I'll add SPJ to that list I guess.
Anyway, IMHO
More neatly, we can fully separate IO from computation:
h n = interact $ show . sum . map read . take n . reverse . lines
Better yet go a small step further and make *composable* combinations of IO
pure computation, as in TV (http://haskell.org/haskellwiki/TV).
Cheers, - Conal
On
On 10/14/07, Dan Piponi [EMAIL PROTECTED] wrote:
On 10/14/07, Yitzchak Gale [EMAIL PROTECTED] wrote:
Not very much, I suspect. That monad really is broken -
it's not a monad at all.
Depending on your point of view, ListT isn't broken. It correctly
transforms commutative monads into monads.
YEEESSS!! W00t11 I've been looking for that for a long time. I
get so sick of glut... Thanks.
Luke
On 10/14/07, Roel van Dijk [EMAIL PROTECTED] wrote:
I say someone binds SDL[1]. (If it hasn't been done already.)
Ask and you shall receive:
http://darcs.haskell.org/~lemmih/hsSDL/
I
On 10/14/07, Jean-Philippe Bernardy [EMAIL PROTECTED] wrote:
instance Arrow a = Functor (a r) where -- (not defined as such in base, but
ad-hoc)
f $ g = pure f . g
Similarly:
instance Arrow a = Applicative (a r) where
return a = pure (const a)
a * b = pure (\(f,x) - f x) . a b
I've been struggling with this for the last day and a half. I'm
trying to get some exercise with the type system and with logic by
playing with the curry-howard correspondence. I got stuck on
the excluded-middle, and I think now I got it almost all the way
there, but its still not quite right.
On 10/14/07, Tim Newsham [EMAIL PROTECTED] wrote:
I've been struggling with this for the last day and a half. I'm
trying to get some exercise with the type system and with logic by
playing with the curry-howard correspondence. I got stuck on
the excluded-middle, and I think now I got it
Hi
main n = print . sum . map read . take n . reverse . lines = getContents
Could someone describe succinctly how to compute the space complexity of
this program, if there are m lines of input and m n? Many thanks. --PR
The space complexity is the size of the file - i.e. of size m. reverse
On Sun, 2007-10-14 at 15:20 -0600, Luke Palmer wrote:
On 10/14/07, Tim Newsham [EMAIL PROTECTED] wrote:
I've been struggling with this for the last day and a half. I'm
trying to get some exercise with the type system and with logic by
playing with the curry-howard correspondence. I got
On Sat, 2007-10-13 at 09:56 -0400, Brandon S. Allbery KF8NH wrote:
Now you need to start forcing things; given laziness, things tend to
only get forced when in IO, which leads to time being accounted to
the routine where the forcing happened. If random / randomR are
invoked with large
David Menendez wrote:
If desired, we could easily define a class for commutative monads, and
then state that ListT m is only a monad if m is a commutative monad.
If we do that, can I suggest that we use some name other
than ListT for that? So far, we seem to agree that most
practical
You realize that Djinn can write all that code for you? :)
Well, not with your encoding of Not, but with a similar one.
-- Lennart
On 10/14/07, Tim Newsham [EMAIL PROTECTED] wrote:
I've been struggling with this for the last day and a half. I'm
trying to get some exercise with the type
On Oct 14, 2007, at 17:54 , ntupel wrote:
Now my problem still is, that I don't know how to speed things up. I
tried putting seq and $! at various places with no apparent
improvement.
Maybe I need to find a different data structure for my random
module and
lazy lists are simply not
On Sun, 2007-10-14 at 18:14 -0400, Brandon S. Allbery KF8NH wrote:
On Oct 14, 2007, at 17:54 , ntupel wrote:
Now my problem still is, that I don't know how to speed things up. I
tried putting seq and $! at various places with no apparent
improvement.
Maybe I need to find a different
On 11 Oct 2007, at 1:00 pm, [EMAIL PROTECTED] wrote:
An anonymous called ok writes:
I am not anonymous. That is my login and has been since 1979.
jerzy.karczmarczuk wrote [about R]:
... This is not a functional language.
There is some laziness (which looks a bit like macro-
processing),
jerzy == jerzy karczmarczuk [EMAIL PROTECTED] writes:
[...]
jerzy But, when J. Vimal threateneds us to throw away Haskell,
jerzy complained about monads, and most people confirmed that the
jerzy underlying theory is difficult, ugly, and useless, I began
jerzy to read those
G'day all.
Quoting Derek Elkins [EMAIL PROTECTED]:
The first goal listed in the Haskell 1.0 Report is:
It should be suitable for teaching, research, and applications,
including building large systems.
Haskell was never intended to be solely a teaching or research language.
(You didn't
Andrew Coppin:
As far as I know, all of this is *possible* with Gtk2hs
right now - it's just vastly more complex than making
a single function call. So what I'd like to do is write
a small library which will enable me to do each of the
above tasks in 1 function call. However, I'm getting
ok writes:
On 11 Oct 2007, at 1:00 pm, [EMAIL PROTECTED] wrote:
An anonymous called ok writes:
I am not anonymous. That is my login and has been since 1979.
Oh, bother...
According to my imperfect knowledge of English, an anonymous is somebody
who doesn't sign his/her letters. And
Dan Piponi wrote,
On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote:
He wants to write entire programs in the type system,
something like the crazies who write programs in C++ templates such
that template expansion does all the work at compile time
Crazies? :-)
Andrew Bromage writes:
There's some stuff from Haskell 1.3 that I miss, and I hope it will
come back, but there's also stuff that we're better off without.
I have heard that a few times, not recently. This is really interesting,
WHAT do you actually miss?
For me, from the ancient times,
ok wrote:
If one wants a lazy dynamically typed programming language that
lets you construct infinite lists by using the basic language
mechanisms in a simple and direct way, there's always Recanati's
Lambdix, which is a lazy Lisp. I don't know whether that ever saw
serious use, but it does
G'day all.
Vimal [EMAIL PROTECTED] quoted someone else as saying:
Monads in programming seem to be the most mysterious notion of the century.
I agree with the hair shirt talk on this. I found understanding monads
no harder than understanding objects, starting from a comparable level of
G'day all.
Quoting Andrew Coppin [EMAIL PROTECTED]:
I tried to use Wikipedia to learn about how to build digital filters...
this was a disaster. There is almost no useful information there! :-(
That's not my experience. I didn't really understand Kalman filters
until I read the Wikipedia
G'day all.
Quoting [EMAIL PROTECTED]:
Or perhaps I am again completely wrong, as in the case of R not being
something I ever wanted?
This is off-topic, but the email address r at google.com is Rob Pike.
Only someone a similar stature (e.g. Richard O'Keefe) could get away
with that.
Cheers,
G'day all.
Quoting [EMAIL PROTECTED]:
I have heard that a few times, not recently. This is really interesting,
WHAT do you actually miss?
Off the top of my head, from H1.4, I miss:
- MonadZero (a lot)
- Some of the monad/functor-overloaded functions (quite a bit)
- Record
Or you could just use Data.Sequence and brows the code at your later
leisure, right? Better yet, you could forget about optimal
datastructures until you learned how to do toy problems with just
plain lists.
--S
On Oct 14, 2007, at 2:12 PM, Brian Hurt wrote:
And the situation is worse
On 15 Oct 2007, at 2:59 am, Vimal wrote:
I like the quote found on this site: http://patryshev.com/monad/m-
intro.html
quote
Monads in programming seem to be the most mysterious notion of the
century.
I find two reasons for this:
* lack of familiarity with category theory;
* many
[EMAIL PROTECTED] wrote in article [EMAIL PROTECTED] in
gmane.comp.lang.haskell.cafe:
That's not my experience. I didn't really understand Kalman filters
until I read the Wikipedia page. It's better than most of the tutorials
out there.
While we're off topic, here's a nice introduction to
On Oct 14, 2007, at 22:54 , Richard A. O'Keefe wrote:
The really amazing thing about the IO Monad in Haskell is that
there *isn't* any magic going on. An level of understanding
adequate for using the I/O and State monads stuff (that is,
adequate for practically anything analogous to what you
On 15 Oct 2007, at 5:41 am, [EMAIL PROTECTED] wrote:
But, when J. Vimal threateneds us to throw away Haskell,
complained about
monads, and most people confirmed that the underlying theory is
difficult,
ugly, and useless, I began to read those postings with attention,
since
I disagree with
On Sun, 14 Oct 2007, Roberto Zunino wrote:
(Warning: wild guess follows, I can not completely follow CPS ;-))
Adding a couple of forall's makes it compile:
propCC :: ((forall q . p - Prop r q) - Prop r p) - Prop r p
func1 :: (forall q . Or r p (Not r p) - Prop r q)
- Prop r (Or r p (Not r
On Sun, 2007-10-14 at 17:19 -1000, Tim Newsham wrote:
On Sun, 14 Oct 2007, Roberto Zunino wrote:
(Warning: wild guess follows, I can not completely follow CPS ;-))
Adding a couple of forall's makes it compile:
propCC :: ((forall q . p - Prop r q) - Prop r p) - Prop r p
func1 :: (forall q
G'day all.
Quoting Richard A. O'Keefe [EMAIL PROTECTED]:
(5) Precisely because it seeks generality, category theory seems
difficult to concrete thinkers. And books on category theory
tend to be extremely fast-paced, so ideas which are not in themselves
particularly esoteric (which
G'day all.
Quoting Brandon S. Allbery KF8NH [EMAIL PROTECTED]:
I would really like to see category theory for the working
*non*mathematician.
It's pricey, but your local university library probably has it:
http://www.cambridge.org/catalogue/catalogue.asp?isbn=9780521478175
Cheers,
100 matches
Mail list logo
