Re: [Haskell-cafe] Filesystem questions
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Categories in base
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. :)
-- JP
{-# OPTIONS -fallow-undecidable-instances #-}
import Prelude ()
class Functor f where
($) :: (a - b) - f a - f b-- a.k.a: fmap, map, liftM
class Functor f = Applicative f where
return :: a - f a -- a.k.a: Control.Applicative.pure
(*) :: f (a - b) - f a - f b -- a.k.a: ap
-- f $ g = return f * g
class Applicative m = Monad m where
(=) :: (a - m b) - m a - m b -- a.k.a: flip (=)
-- f * g = (\h - (return . h) = g) = f
class Category c where
id :: c a a
(.) :: c y z - c x y - c x z -- a.k.a: (), flip ()
class Category a = Arrow a where
pure :: (b - c) - a b c
first :: a b c - a (b, d) (c, d)
instance Arrow a = Functor (a r) where -- (not defined as such in base, but
ad-hoc)
f $ g = pure f . g
-- instances for (-)
instance Category (-) where
id = \x - x
f . g = \x - f (g x)
instance Arrow (-) where
pure = id
first f = \(b, d) - (f b, d)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
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 (which must then return another action, which is executed). foo bar executes the action too, and then executes the action bar. Any result generated by foo is discarded, and bar must be an action rather than a 1-argument function that *returns* an action. Make any sense? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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. Representing a directory structure as a tree
makes people think they can manipulate it as if it were a tree, which
leads to all kinds of nasty bugs when the real world bleeds through the
holes in the abstraction.
You are right. Well, I didn't say what I meant by a
lazy Data.Tree :).
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.
Especially in this application, using that type of laziness
is really unsafe. Any user must be explicitly aware of
potential side effect complications, such as directory
structure shifting under your feet as you work, possibly
induced by your own traversal if you are not careful.
(In my opinion, the documention for Python's os.walk
http://docs.python.org/lib/os-file-dir.html#l2h-2715
gives a nice, clear description of what must be
avoided during such a traversal.)
So I think that what is needed here is something like
the following. Based on my experience, this would be
a really convenient API:
data TraversalDirection = TopDown | BottomUp
data Directory = Directory {
dirPath :: FilePath,
fileNames :: [FilePath],
subdirNames :: [FilePath]}
-- List all directories in the tree rooted at the given path
traverseDirectories :: MonadIO m =
TraversalDirection - FilePath - ListT m Directory
-- List all non-directory files in the tree rooted at the given path
traverseFiles :: MonadIO m =
TraversalDirection - FilePath - ListT m FilePath
traverseFiles = join . fmap (liftList . fileNames) . traverseDirectories
-- List the paths to all subdirectories in the tree rooted at the given path
traverseSubdirs :: MonadIO m =
TraversalDirection - FilePath - ListT m FilePath
traverseSubdirs = join . fmap (liftList . subdirNames) . traverseDirectories
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?)
You could plug the above into your machinery for
recursion predicates and all the other nice stuff.
-Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 dangerous semantically broken non-referentially-transparent lazy IO structure. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
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 is executed). foo bar executes the action too, and then executes the action bar. Any result generated by foo is discarded === I believe that our - sometimes helpful, sometimes not - answers should regularly encourage the newbies to *READ* the tutorials, the documentation, etc. My goodness, is it really too difficult? Then, the answer would be given by the default definition in the Prelude: -- Minimal complete definition: m k = m = \_ - k which means exactly that, = is the base, uses it, but doesn't care about the argument. And shows that the verbal explanation, actions, executed, etc. may not be true in general I know that asking helpful humans is nicer than reading docs, but the latter is usually more instructive, and often more efficient. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 in the tree rooted at the given path traverseDirectories :: MonadIO m = TraversalDirection - FilePath - ListT m Directory You could plug the above into your machinery for recursion predicates and all the other nice stuff. Or - getting back to the lazy Data.Tree idea - we could define TreeT, analgous to ListT: newtype TreeT m a = NodeT (m (a, TreeT (ListT m) a)) and give it a nice Monad instance. Then you can prune and filter trees in a natural way, inside the monad. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] On the verge of ... giving up!
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 approach has helped me. But for Haskell, it is failing. 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). The next step I usually take in learning a language is, not to go by the topics found in textbooks, but by taking real world examples and then blindly try to solve it using that language as a tool. For e.g, I tried writing a terminal GTalk client for Python when I was learning it, and learnt so many features that way. I used to call this 'learning by need', and it worked, to the extent that I never knew how to take 'input' from the user, but knew how to write Objects in Python! (Since I never used input in that example :) 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 introduced to abstract math (like Groups, etc.), I found this a little difficult. However I tried my best to understand the tiniest bit and waited for the tiniest spark that would enlighten me. It didn't work out. --snip-- Okay, so you might be wondering as to whats the whole point of this mail? Well, I am almost on the verge of giving up on something I really like to learn, just because I didn't go in the right order! 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. Meanwhile, could anyone suggest if there was anything wrong in my approach to learning Haskell/the other languages? I agree that the learning methodology is something personal and I have to find out what best suits me, but I would like to hear something from you, Haskellers, too. I have no need to hurry anything at this point of time. But after being introduced to the tiniest bit of Haskell, and after seeing such a large and active community here, and #haskell, I had the plan of conducting a Haskell Workshop, in our department (sometime in Feb next year, the dates have not been finalized). I just hope that I should be able to reach a substantial amount of familiarity with Haskell by that time! Sorry for the long mail, and pardon me if it was too boring. I just put my thoughts on strikepaper/strike a mail :) I did have a couple of ambitious projects in my mind when to help me learn Haskell. They were: 1. An online judge system (Like http://spoj.pl). I had already done one for contests that were held during our Technical festival here, using php. The ideas are laid out. All I had to focus on was learning Haskell. 2. A solver for the Peg-Solitaire. This was more of an academic interest. I have seen Richard Bird's presentation on 'How to write a functional pearl, with an example' and was quite impressed by it. But the actual modelling might be slightly tricky here, and I am yet to start off with it. Many thanks for your patience, Cheers, -- ~Vimal IIT Madras RLE :) encode = map (length head) . group decode = concatMap (uncurry replicate) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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. 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. I'm not sure this covers IO in any great detail - it will be useful for general Haskell though. 1. An online judge system (Like http://spoj.pl). I had already done one for contests that were held during our Technical festival here, using php. The ideas are laid out. All I had to focus on was learning Haskell. 2. A solver for the Peg-Solitaire. This was more of an academic interest. I have seen Richard Bird's presentation on 'How to write a functional pearl, with an example' and was quite impressed by it. But the actual modelling might be slightly tricky here, and I am yet to start off with it. I would try number 2 first. IO in Haskell can be tricky, especially while you are learning all the other bits of the language at the same time. Network stuff is also not as well developed in terms of libraries as something like Python - but something like HappS should be able to do a spoj clone easily enough. A better choice for an initial IO application might be something like du, then moving to an online judge system later on. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Filesystem questions
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 -- List all directories in the tree rooted at the given path traverseDirectories :: MonadIO m = TraversalDirection - FilePath - ListT m Directory You could plug the above into your machinery for recursion predicates and all the other nice stuff. Or - getting back to the lazy Data.Tree idea - we could define TreeT, analgous to ListT: newtype TreeT m a = NodeT (m (a, TreeT (ListT m) a)) and give it a nice Monad instance. Then you can prune and filter trees in a natural way, inside the monad. Eh, isn't that what ListT is already for? I mean, type Directory = FilePath contents :: MonadIO m = Directory - m [FilePath] liftList :: Monad m = m [a] - ListT m a runList :: Monad m = ListT m a - m [a] allows you to prune the directory tree in whatever way you like it. Here's an example top-down traversal that lists all non-directories: allFiles :: MonadIO m = Directory - m [FilePath] allFiles d = runList $ do f - liftList $ contents d if isDirectory f then allFiles f else return f In other words, ListT is like one of those iterators I keep hearing from the Python/Java/.../imperative world (except that you can't suspend a traversal once started). Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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). 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 like Haskell, and they're supposedly based on the same ideas. The next step I usually take in learning a language is, not to go by the topics found in textbooks, but by taking real world examples and then blindly try to solve it using that language as a tool. Not a bad way to learn to use a tool. You might want to stick to things that involve simple I/O and complex processing rather than the other way round though. ;-) (For example, I wrote a program that renders an animation of the solutions of a simple differential equation by numerical integration. The math is complex; the I/O just involves dumping millions of numbers into a big text file.) 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. For the longest time I couldn't remember whether it's monad or monand... but anyway, yeah, it's a common problem. It's not actually complicated ones you understand it; it's just that it's so abstract that it's hard to explain. It's a bit like trying to explain to somebody what a magnet is... it's not a complex concept, just hard to describe. Then, I set out to learn Monads + Category Theory from a Math perspective. Um... yeah, that probably won't work. As far as I know, Haskell's idea of monad has little to do with the theoretical concept. Meanwhile, could anyone suggest if there was anything wrong in my approach to learning Haskell/the other languages? I agree that the learning methodology is something personal and I have to find out what best suits me, but I would like to hear something from you, Haskellers, too. I'm a maths nerd. To me, Haskell looks like an advanced term-rewrite system similar to Mathematica. It was quite easy to learn the basics. What took longer was learning to approach problems in the right way. The way you'd do things in an object oriented language is usually NOT the way you'd do it in Haskell. (Unless you enjoy making your life hard...) Unfortunately, that's all practice. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
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 best way to learn Haskell is to learn it from a textbook. That's basically all there is to it :) I mean, the same goes for Theoretical Computer Science, Mathematics, Physics etc. I think that the key properties of a textbook are 1) printed on paper 2) well-written Of course, if a book doesn't have property 2), use another one. An online book satisfying 2) can be made satisfy 1) by printing it out. In other words, anything goes that fulfills 1) and 2). And since reading two textbooks (in parallel) is even better than reading only one, I'd additionally recommend Bird's Introduction to Functional Programming using Haskell. For other books, see also http://haskell.org/haskellwiki/Books_and_tutorials#Textbooks Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 introduced to abstract math (like Groups, etc.), I found this a little difficult. However I tried my best to understand the tiniest bit and waited for the tiniest spark that would enlighten me. It didn't work out. 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, then try to learn a couple of other monads. Then maybe this article http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html about monad transformers. It is good because it do not try to explain the implementation details of monad transformers - just how you use them. When you have done all that, then you should be ready for all the details. --snip-- Okay, so you might be wondering as to whats the whole point of this mail? Well, I am almost on the verge of giving up on something I really like to learn, just because I didn't go in the right order! 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. Meanwhile, could anyone suggest if there was anything wrong in my approach to learning Haskell/the other languages? I agree that the learning methodology is something personal and I have to find out what best suits me, but I would like to hear something from you, Haskellers, too. As I wrote above, I think you are trying to understand too many details at once. Also a textbook can sometimes be helpful. But you also have a learning by doing approach, which I personally find very productive. And do not give up yet. Haskell has a lot to offer and I think it is well worth the steep learning curve. Cheers, Mads Lindstrøm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pixel plotter
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!) What I'd *like* to be able to do, in priority order: 1. Display images on the screen. 2. Save images as PNG files. (PPM eats too much space!) 3. Animate images on the screen. 4. With double-buffering. 5. Not break horribly when rendering in multiple threads. 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 nowhere fast with this. Anybody have any suggestions? 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 from Lisp/Scheme etc. By way of an annecdote, the other day, I was working on a problem in Haskell and having some problems getting types (I believe it was a problem of converting between different types of numbers) to match up correctly. Darnit, if I was doing this in Scheme, I thought, the types would just work themselves out, so I booted up DrScheme and started translating the code. It took me three times as long because of all the list comprehensions and laziness that I had started to use so automatically in Haskell. Anyway... let me get to some of your questions. 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. So when I first started with Haskell, I started with the online tutorials, but got stuck with the Monad stuff. So I actually ordered this same book and read it cover to cover, and it helped a quite a bit, but I still needed some practical experience. I think the examples which compare parsing strings to doing IO are especially instructive with respect to understanding Monads. However, what I'm really missing at this point is how to write my own monads. (As a side note, I'm not entirely convinced that you need to write a lot of your own monads, but I'd still like to understand that) The next step I usually take in learning a language is, not to go by the topics found in textbooks, but by taking real world examples and then blindly try to solve it using that language as a tool. For e.g, I tried writing a terminal GTalk client for Python when I was learning it, and learnt so many features that way. I used to call this 'learning by need', and it worked, to the extent that I never knew how to take 'input' from the user, but knew how to write Objects in Python! (Since I never used input in that example :) 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 Haskell well. Then I stumbled onto Project Euler (projecteuler.net). Its a whole bunch of math-related problems where you usually need to write a program to do some sort of search for numbers with specific properties or to find the number of combinations for some bizarre situation etc. It may or may not be your cup of tea in the sense that the problems themselves are a bit esoteric and you'll never use these programs again. However, I (have) found that: 1. These smaller exercises have really helped me learn some of the weirder syntax better (ex: list comprehensions are now a piece of cake) 2. A number of the exercises require you to come up with more than just a brute force search (or your program will take too long to produce an answer), so I've had to learn about various topics (ex: how to use arrays in a functional (non-imperitive) way to accomplish dynamic programming type tasks) 3. Haskell is ideally suited to doing mathy type problems. For example, the laziness feature of the language (something else that is entirely different from most main stream languages, and which I needed more practice with) allows me to implement (potentially) infinite searches in the same way as I implement finite searches. 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. A couple of my solutions to project euler required me to use hashtables (before I figured out how to use arrays functionally) so I've picked up a little of the IO stuff. Its... less than intuitive, and I avoid it at all costs... some of the problems have large input files. I parse them by hand into Haskell syntax to avoid making my program have to do IO. But you can definitly learn more about IO by doing it the sane/intended way. 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. 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. This can make Haskell quite unweildy for solving these types of problems. On the otherhand, writing something like a compiler (which requires a small amount of IO - read a file(s), write results to a file - and a large amount of unseen computation - generating and optimizing code) is right up Haskell's alley. Then, I set out to learn Monads + Category Theory from a Math perspective. And since I haven't been introduced
Re: [Haskell-cafe] Pixel plotter
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 texture maps for now, you have a future proof way to do far more sophisticated graphics. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 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 amount of IO - read a file(s), write results to a file - and a large amount of unseen computation - generating and optimizing code) is right up Haskell's alley. Au contrare... ;-) Let us examine web browser for a moment. Yes, it does some input (typically fetching resources by HTTP), and some output (mainly displaying stuff on your screen). But wait a moment there... For a typical web page, you might well have to perform all of the following operations: - Parse an XHTML file into a document tree. (That's pretty algorithmic.) - Parse multiple CSS style sheets, and apply them to the document. (This involves processing possibly-complex element selectors, observing inheritance relationships, and merging the properties from several sources into a single result set. That's A LOT of algorithm!) - Parse some JavaScript and execute it. (That's an entire programming language, remember.) Watch in horror is it uses the DOM to *modify* the XHTML data you just parsed and applied CSS to... - Load several JPEG files. (You might think that load a JPEG file is I/O, but really, getting the data into memory is just the beginning. You've got a file to parse, you've got an arithmetic code to decompress, and then you've got an inverse Discrete Cosine Transform to do. Again, LOTS of algorithm.) - Let us hope to God the page doesn't contain any SVG... (Think of the massacre!) - Perform final layout (frames, tables, justification, backgrounds, transparency...) and rendering to incorporate all this data into one huge bitmap that can be dumped into the framebuffer. OK, so if you wrote this program today, the JPEG part would probably be an external library. And SVG, if you supported it. But you get the point; there is A LOT of heavily algorithmic stuff happening there that has little or nothing to do with I/O. The browser is sucking in XHTML, CSS, JavaScript, JPEG, SVG and God only knows what else (XSLT, anyone?), doing a mountain of processing with it, and only then showing the final result on your computer screen. There's a lot more I/O than your typical compiler, but don't go thinking there's nothing algorithmic happening here. ;-) Similarly, any good word processor is going to have layout algorithms (would you like that left-justified or right-justified? what happens if you have several typeface sizes in the same block of text? how does text flow round images?), and possibly cross-referencing. Email programs need to efficiently store and retrieve user's mail, and often have search facilities (and even Baysian filters for eliding spam). Even a humble IDE usually has syntax recognition... So you see, they may not spend quite as much *time* on computation as a compiler does, but there's still plenty of *complexity* there. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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 you are just filling texture maps for now, you have a future proof way to do far more sophisticated graphics. ...just... the irony of using OpenGL to write a software ray tracer. ;-) 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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 http://www.haskell.org/haskellwiki/Monads_as_Containers and then read lots of other Monad tutorials for Haskell. I tried this too, and this made some sense to me in the beginning. But, not enough to satisfy my curiosity! So, I tried to dig in ... 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. I'm not sure this covers IO in any great detail - it will be useful for general Haskell though. 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 question I would like to answer :) I would try number 2 first. IO in Haskell can be tricky, especially while you are learning all the other bits of the language at the same time. Network stuff is also not as well developed in terms of libraries as something like Python - but something like HappS should be able to do a spoj clone easily enough. A better choice for an initial IO application might be something like du, then moving to an online judge system later on. You are probably right. Mimicking *nix tools might be great fun to start off with :) Thanks Thanks :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
@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 like Haskell, and they're supposedly based on the same ideas. I didnt know this when I _started_ :) So, thats why I am learning Haskell in exclusion. Not a bad way to learn to use a tool. You might want to stick to things that involve simple I/O and complex processing rather than the other way round though. ;-) (For example, I wrote a program that renders an animation of the solutions of a simple differential equation by numerical integration. The math is complex; the I/O just involves dumping millions of numbers into a big text file.) Yes, as someone pointed out, Haskell was meant for a lot of computation, and IO is just a part of the story! For the longest time I couldn't remember whether it's monad or monand... but anyway, yeah, it's a common problem. It's not actually complicated ones you understand it; it's just that it's so abstract that it's hard to explain. It's a bit like trying to explain to somebody what a magnet is... it's not a complex concept, just hard to describe. 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: * lack of familiarity with category theory; * many authors carefully bypass any mention of categories. It's like talking about electricity without using calculus. Good enough to replace a fuse, not good enough to design an amplifier. /quote I'm a maths nerd. To me, Haskell looks like an advanced term-rewrite system similar to Mathematica. It was quite easy to learn the basics. What took longer was learning to approach problems in the right way. The way you'd do things in an object oriented language is usually NOT the way you'd do it in Haskell. (Unless you enjoy making your life hard...) Unfortunately, that's all practice. Ah, I am not familiar with the term-rewrite you are talking about. I will Google it up then. Thanks :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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, then try to learn a couple of other monads. Then maybe this article http://sigfpe.blogspot.com/2006/05/grok-haskell-monad-transformers.html about monad transformers. It is good because it do not try to explain the implementation details of monad transformers - just how you use them. When you have done all that, then you should be ready for all the details. Alright, this post seems interesting. Will try it out soon! As I wrote above, I think you are trying to understand too many details at once. Also a textbook can sometimes be helpful. But you also have a learning by doing approach, which I personally find very productive. Yeah, this has always been a problem with me. Its like browsing Wikipedia. Open an article, and you branch out like anything. Curiosity does kill the cat :( And do not give up yet. Haskell has a lot to offer and I think it is well worth the steep learning curve. Nope. I enjoy learning it, just waiting to hit the peak! Someone creative enough should draw the learning curve for Haskell :D. I remember some funny ones for text editors! (emacs had a spiral...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 Haskell well. Then I stumbled onto Project Euler (projecteuler.net). Its a whole bunch of Ah, yes, Project Euler. I did start doing this sometime back, but then gave up on it. Perhaps its time to start again :) Thanks, that was an eyeopener. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 about things which are toxic, explosive, flammable or corrosive... hmm, That's Not Good...) I tried to use Wikipedia to learn about how to build digital filters... this was a disaster. There is almost no useful information there! :-( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is this a known problem?
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: http://hackage.haskell.org/trac/ghc/wiki/Building/Unregisterised Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 question I would like to answer :) I/O is a monad. Actually, there's another one called STM (for doing transactional modifications). And there are various ones for doing stateful stuff (e.g., incrimentally building a solution or something). Then there's the Maybe monad (for operations which sometimes fail). Lists are a monad (for operations that yield multiple results). Parsers are a celebrated example of monads - although the most efficient ones use something called arrows. (These are like monads, but even more abstract. If you enjoy making your head hurt...) There is also an entire zoo of other monads out there. There's a CPS monad (for writing unmaintainable code), many graphics libraries have a drawing monad... the list goes on. Is there any merit in you writing your own monad? Well, if it's doing something similar to existing monads, then maybe. (Note that there are such things as monad transformers, which allow you to merge multiple monads together into a giant, all-powerful monad. So, if you wanted a stateful parser that does I/O, you could use transformers to mix those exact features together - no coding required.) I would try number 2 first. IO in Haskell can be tricky, especially while you are learning all the other bits of the language at the same time. Network stuff is also not as well developed in terms of libraries as something like Python - but something like HappS should be able to do a spoj clone easily enough. A better choice for an initial IO application might be something like du, then moving to an online judge system later on. You are probably right. Mimicking *nix tools might be great fun to start off with :) Uh... think it's been done already. ;-) Still, you could try it yourself and see what you get - and then marvel at how others have done it in half the code. :-} ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
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. I could only find one option for a homepage for the project: - Create a page on the Wiki. There seems to be no option when it comes to tracking bugs. :-( I could also not locate any option for publishing haddock pages. :-( We'd like community.haskell.org to be usable for all of this, it just needs someone to ask us for something, and then us to get around to setting it up. Currently source repos go on code.haskell.org. 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). Would it be better to make things consistent for users, and have all projects use trac (or something else), or for each project to be able to easily use the bug tracker of their choice? Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 languages like Haskell, but all developed by different people and all with different syntax and so on. So they wanted to create a single language suitable for teaching to students. You could say it's the Pascal of the functional world... Hey, maybe that explains the lack of success?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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: * lack of familiarity with category theory; * many authors carefully bypass any mention of categories. It's like talking about electricity without using calculus. Good enough to replace a fuse, not good enough to design an amplifier. /quote Maybe *this* is why I get nowhere with designing electronic things? I know very little about calculus. (And I can't begin to imagine what it has to do with electricity...) 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 because some classes are bigger than sets - which is absurd since a set can be of any size...) Ah, I am not familiar with the term-rewrite you are talking about. I will Google it up then. Thanks :) A term-rewrite system is just a system that replaces (rewrites) certain terms with other terms. For example, a package like Mathematica would have a term rewrite rule that says that all occurrances of x - x should be rewritten as 0. Haskell can't do anything quite *that* sophisticated, but what it *can* do is things like linear a b x = a*x + b which causes all terms involving linear to be rewritten into the thing on the RHS. You can actually draw the reduction sequence as an expression is transformed step by step into the final result: sum [1,2,3] foldr1 (+) [1,2,3] foldr (+) 1 [2,3] foldr (+) (1+2) [3] foldr (+) (1+2+3) [] 1+2+3 3+3 6 Each line is derrived from the previous one by some program rule. (The last three being hard-coded into the language itself.) If you're pathologically curiose, look up lambda calculus for a programming language like Haskell where the last few steps above are *definable* from first principles. :-D ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 (although it is currently included in some distributions as an extra lib). If you want to propose that mtl switches to a different definition of ListT then please see http://www.haskell.org/haskellwiki/Library_submissions Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 try Erlang. It's easy like Python. It's designed for rock-solid enterprise applications. Threading and rpc are insanely easy. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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_ problem? Thats the kind of question I would like to answer :) The approach I used to fully understand monads was the same as I used to fully understand Python's metaclasses: don't try to get into its inner until you need. I mean, don't try to find a problem to come up with a monad. Instead, someday you will going to solving a problem and you'll have the idea of making instance Monad of it. Meanwhile you'll get used to the language and see lots of other already-built monads. Well, worked for me. The beautiful thing about monads and metaclasses is that they are extremely simple after you understand them. That's also why monads are called Warm, fuzzy things, AFAICT =). But both don't fit everywhere, and it requires some experience to see that. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 because some classes are bigger than sets - which is absurd since a set can be of any size...) 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 it be really too much asking that - at least from time to time - Andrew Coppin think twice before saying things he - apparently - knows NOTHING about? Haskell café, is, well, café... even no tobacco restrictions. But, since we have here people who want to learn something structured and based on some real competence, saying e.g. that CPS monad is for making unmaintainable code, or I know very little about calculus. (And I can't begin to imagine what it has to do with electricity...), is becoming a nuisance. I skipped the postings of A.C., as most of people on this forum I happen to know, and there was no personal reason to react. But A.C. engages in a dialogue with newbies, and this is, from the pedagogical point of view, rather harmful. Please stop. Another example, for the rewriting this time: foldr (+) 1 [2,3] foldr (+) (1+2) [3] foldr (+) (1+2+3) [] 1+2+3 3+3 6 This derivation is pure rubbish. Read the definition of foldr, please, would it be the first time in your life??? The functional foldr is NOT tail recursive! And, actually, as EVERYBODY knows, Haskell is not a rewriting system. So, a good advice for J. Vimal: do whatever you wish, but avoid this fellow A. Coppin, since he leads you nowhere. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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 individual pixels. I highly recommend OpenGL. Even if you are just filling texture maps for now, you have a future proof way to do far more sophisticated graphics. ...just... the irony of using OpenGL to write a software ray tracer. ;-) 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? OpenGL is used as a pixel-plotting mechanism relatively often. You wouldn't be doing anything new if you did it that way. I say someone binds SDL[1]. (If it hasn't been done already.) - Jeremy [1] - http://libsdl.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
[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 it be really too much asking that - at least from time to time - Andrew Coppin think twice before saying things he - apparently - knows NOTHING about? OK. I get the message. I'm unsubscribing now... [How ironic the subject line suddenly seems.] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
[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 ideas. Do not attack people. (Please!) Regards, Zun. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance problem with random numbers
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: http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/SFMT/index.html If there's interest, I can package up the bindings for hackage. looks nice... at least for those of us who have non-old computer CPUs Is there a decent way to implement 'split'? A way that doesn't take too long to run, and produces fairly independent generators? Isaac ___ 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] do
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 the list some explanation; if I get a reply pointing me back to the doc, it doesn't help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 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 it be really too much asking that - at least from time to time - Andrew Coppin think twice before saying things he - apparently - knows NOTHING about? OK. I get the message. I'm unsubscribing now... [How ironic the subject line suddenly seems.] ___ 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] On the verge of ... giving up!
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 button might be a good first step, as well as refraining from giving the impression of certainty when one isn't actually sure. A little knowledge can be a dangerous thing, and it can be hard for newbies to evaluate the credibility of an answer. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt There's no money in poetry, but there's no poetry in money, either. --Robert Graves ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
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 my intention of throwing away, anybody, and I didn't. I had no right to do such thing either. I just asked A. Coppin to think twice before submitting dubious statements, didn't I? I believe that it would be useful for the list if he stayed, and *asked questions*. My impoliteness was quite restrained... 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 spreading such atmosphere. And A.C. additionally wrote that all this theory has nothing to do with Haskell, and submitted three more postings, one more dubious than the other, I found that a warning seems suitable, not for him, but for his readers! Mathematics is beautiful and useful. The commutativity of some categorical diagrams can be translated into the optimization of Haskell constructs, say, showing that there is a canonical isomorphism between (map f) . (map g) and: map (f . g) etc. So, why dump the theory away, which suggests additionally that the conceptors of Haskell are irresponsible dreamers, living on some crystal mountain?... The language is not trivial to learn, that's it. If somebody feels discouraged, my own students often are, then the recipe is simple: ask CONCRETE questions, get CONCRETE answer. THEN generalize. But if some people offer general answers, they must be based on a real competence and experience, otherwise they easily become harmful. == David48 points out that if a list returns the reader to the docs which he has already seen, and which is poor, then it doesn't work at all. OK, then, once more, don't say I cannot understand monads, or rewriting, or whatever, but say plainly: I read XYZ in the ABC tutorial, and the example PQR remains too difficult. And say WHAT doesn't work. Go ahead, criticize *concrete* documentation, don't say that docs are lousy! Almost all Haskell documentation has been written by people who *beg* constantly for comments, for criticism; let's help them instead of shouting at them. Of course, the repeated, ever and ever again questions mean that one day it will be absolutely necessary to make a true FABQ, proposed a few times, and still in statu nascendi... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 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 differences in amount of documentation. Maybe you could expand on that a bit? b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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 nut, is like saying that using a computer to edit files is like using a thermal lance to slice butter. (Do you like my higher order simile?) Incidentally, people raytrace with OpenGL all the time via GPGPU: http://www.gpgpu.org/cgi-bin/blosxom.cgi/Advanced%20Rendering/index.html I'm looking forward to someone implementing a nice Haskell API to all that yummy GPGPU stuff, like Python's http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/ (I've heard rumours...) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 it for Haskell (Lisp+OCaml+Haskell together). 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 like Haskell, and they're supposedly based on the same ideas. 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. They should start with either Ocaml or SML first. If it makes it easier to accept this argument, you can consider Ocaml and SML as Haskell with training wheels. And that the original poster, rather than giving up on Haskell, should instead put Haskell on the backburner and instead learn Ocaml (which is likely to be hard enough). Then, in a year or two, start taking another swing at Haskell. The problem is that Haskell has a lot of big ideas that all come at you pretty much immediately. Learning a new language in a new paradigm is a lot harder than learning in a new language in a paradigm you already know. If you know Java or C#, it's not that hard to learn Python or Ruby, because you already know how to think in objects. The problem with going from a C/Java/Ruby paradigm to Haskell is that Haskell isn't just one paradigm shift, it's several all rolled into one: - Purely functional - Lazy - Monadic - Strongly typed Each one of these has a huge impact in how you think about problems and design programs- I'd argue about as large an impact as Objects have. These are all good things (well, I'd admit to not being 100% sure about pure laziness), and knowing how to think in these paradigms is definately a good thing. And the situation is worse with pure functional languages. When you move from, say C/Pascal/Fortran to Java/Ruby/Python, you don't have to learn new data structures and new algorithms. A doubly linked list is still just a doubly linked list, still has the same properties, and still has more or less the same implementation. In addition to learning Haskell, you also need to relearn basic computer science. You need to learn what a realtime lazy catenable dequeue is, how to implement it, and why you need one, all the while struggling with the syntax, type errors, and all the other problems trying to learning a new language. 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 will reply to this email with a single line of code that does it. But just think for a moment the number of different paradigm shifts that you need to make to write this program in Haskell. I'm not saying that it's impossible to go directly to Haskell, I'm saying that it's just very very hard. Ocaml, meanwhile, is in many ways the C++ of the functional world. C++ was needed for object orientation to take off, because it allowed you to continue to program in plain old procedural C when you needed to get something done, and to play with OO concepts and ideas as you have the time/inclination/need. Then, once people became comfortable with objects and OO thinking, they were ready for the real OO languages. In a similiar fasion, Ocaml allows you to write old fasioned impertive code when you need to just get something working. And as you have the time/inclination/need to, you can start playing with more advanced functional concepts, like purely applicative data structures, lazy evaluation, and even monads. Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 amount of IO - read a file(s), write results to a file - and a large amount of unseen computation - generating and optimizing code) is right up Haskell's alley. hey, compilers do nothing but IO! they read sources, print error messages or write object files and executables. there is really no need to do any unseen computation at all! unless there is some visible effect on the file system or programmer console, any such unseen computation is wasted, and should be optimised away. .. just kidding, of course?-) if compilers seem more suitable for haskell, it may be because they have been studied for a long time, and while throughput is important, noone is likely to argue that the core of compilation is about reading or writing files. the focus in writing compilers is on designing, implementing and manipulating the internal representations of the source and object code represented externally as strings of chars and bytes. applying the same reasoning to your most widely-used programs, we could say that their theory hasn't reached the same level as that of compilers (and so i'd remove data bases from your list, and editors are also reasonably well-understood). once their internal representations are better understood, programming again focusses on working with these internal representations (often called models), while IO reduces to a straightforward mapping from and to those internal representations that are closest to the external ones. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 who's interested in the language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 decide things like what IO to do. For example, in a web browser the IO is in reading user input, rendering the display and interacting with the network - but page layout is computation, as is dispatching input. -- [EMAIL PROTECTED] Society does not owe people jobs. Society owes it to itself to find people jobs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do
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 of Expression http://haskell.org/soe/ book, but mainly, creating some of the monad instances myself, step by step (I started with a random number generator, and ended with the list monad). I found this very useful, and I actually had to look many times to the existing solution to get it right. It made me appreciate the genius minds behind this. After a bit of practice, I can now use monads almost as easy as I can write imperative C/C++/C# code, although I find this is also the dangerous part of the do notation: you tend to forget the beautiful pure functional implementation that is behind the scenes, and start to think imperatively (again)... If you want I can dig up my old source code where I converted a random number generator from a purely functional approach to a monadic approach, but I'm not sure reading it would help you, it's creating the code yourself that will be useful I guess. Good luck, Peter Verswyvelen avid48 wrote: 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 the list some explanation; if I get a reply pointing me back to the doc, it doesn't help. ___ 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] On the verge of ... giving up!
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* decent language, with functional tools. It is *exactly* what we tried to do with Python. Paying tribute to our pedagogical constraints, and teaching a language with a strong imperative taste, but using functional constructions as frequently as possible. Recursion, comprehensions, map/filter business (despite strong intentions of Guido V.R. of killing them...), etc. Also, higher-order functions, not so bad in Python, although sometimes curiously inefficient. But, anyway, splitting between the language and the basic techniques may be not so stupid. Hm. An Anglosaxon shouldn't say techniques may not be so stupid?... I agree with what Brian says next. But...: In a similiar fasion, Ocaml allows you to write old fasioned impertive code when you need to just get something working. And as you have the time/inclination/need to, you can start playing with more advanced functional concepts, like purely applicative data structures, lazy evaluation, and even monads. As far as the lazy evaluation is concerned, I would suggest then to jump to Haskell or to Clean, after just a few simple-minded exercices in other languages (the cons-stream, etc. in Scheme. Or, the generators in Python, which are in a sense lazy objects). Otherwise you will *never* get a taste of laziness. It is useful only if it is comfortable. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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. http://darcs.haskell.org/packages/GLUT/examples/RedBook/Image.hs). But the SDL stuff seems easier... Thanks, Peter Verswyvelen Roel van Dijk 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 use those SDL bindings to plot pixels with OpenGL and play with 3D stuff in Haskell. ___ 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: On the verge of ... giving up!
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 will reply to this email with a single line of code that does it. Sorry, I can't resist :) main n = print . sum . map read . take n . reverse . lines = getContents I'm not saying that it's impossible to go directly to Haskell, I'm saying that it's just very very hard. [] 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. They should start with either Ocaml or SML first. If it makes it easier to accept this argument, you can consider Ocaml and SML as Haskell with training wheels. I don't agree. At least, it was different for myself. Looking at the line of code above, I can't help it, but I perceive Haskell as being the _simplest_ programming language in the whole world. I had no trouble learning it (step by step from a book), maybe because I've happily thrown away everything I (thought I) knew (about programming). The reward was worth it. Why do people want side effects? Purity is soo much simpler. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Let's do ListT right, finally
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 to propose that mtl switches to a different definition of ListT then please see http://www.haskell.org/haskellwiki/Library_submissions OK, then. This is a major rewrite of this module. So let me open up the topic for discussion even before posting a submission. Do we need to worry about breaking code? Not very much, I suspect. That monad really is broken - it's not a monad at all. The problem and its solution have been well known for years. I personally tried using the standard ListT for a while, just because it's the standard. Until I ran into enough problems that I finally slapped my forehead and said forget it. But just in case: Is there anyone reading this who would be hurt by this change and opposes it? Should we provide a more gradual deprecation path (what is it)? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 languages. But thanks to Haskell, I found the vibes again! Cheers, Peter Verswyvelen Hugh Perkins wrote: 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 who's interested in the language. ___ 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] On the verge of ... giving up!
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, 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 it for Haskell (Lisp+OCaml+Haskell together). 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 like Haskell, and they're supposedly based on the same ideas. 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. They should start with either Ocaml or SML first. If it makes it easier to accept this argument, you can consider Ocaml and SML as Haskell with training wheels. And that the original poster, rather than giving up on Haskell, should instead put Haskell on the backburner and instead learn Ocaml (which is likely to be hard enough). Then, in a year or two, start taking another swing at Haskell. The problem is that Haskell has a lot of big ideas that all come at you pretty much immediately. Learning a new language in a new paradigm is a lot harder than learning in a new language in a paradigm you already know. If you know Java or C#, it's not that hard to learn Python or Ruby, because you already know how to think in objects. The problem with going from a C/Java/Ruby paradigm to Haskell is that Haskell isn't just one paradigm shift, it's several all rolled into one: - Purely functional - Lazy - Monadic - Strongly typed Each one of these has a huge impact in how you think about problems and design programs- I'd argue about as large an impact as Objects have. These are all good things (well, I'd admit to not being 100% sure about pure laziness), and knowing how to think in these paradigms is definately a good thing. And the situation is worse with pure functional languages. When you move from, say C/Pascal/Fortran to Java/Ruby/Python, you don't have to learn new data structures and new algorithms. A doubly linked list is still just a doubly linked list, still has the same properties, and still has more or less the same implementation. In addition to learning Haskell, you also need to relearn basic computer science. You need to learn what a realtime lazy catenable dequeue is, how to implement it, and why you need one, all the while struggling with the syntax, type errors, and all the other problems trying to learning a new language. 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 will reply to this email with a single line of code that does it. But just think for a moment the number of different paradigm shifts that you need to make to write this program in Haskell. I'm not saying that it's impossible to go directly to Haskell, I'm saying that it's just very very hard. Ocaml, meanwhile, is in many ways the C++ of the functional world. C++ was needed for object orientation to take off, because it allowed you to continue to program in plain old procedural C when you needed to get something done, and to play with OO concepts and ideas as you have the time/inclination/need. Then, once people became comfortable with objects and OO thinking, they were ready for the real OO languages. In a similiar fasion, Ocaml allows you to write old fasioned impertive code when you need to just get something working. And as you have the time/inclination/need to, you can start playing with more advanced functional concepts, like purely applicative data structures, lazy evaluation, and even monads. Brian ___ 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] Hosting of Haskell project
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 Ruby (well, Trac is also not Haskell :-) but has support for darcs ;) Just an idea... Sincerely, Gour signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Filesystem questions
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 Directory Or - getting back to the lazy Data.Tree idea - we could define TreeT, analgous to ListT: newtype TreeT m a = NodeT (m (a, TreeT (ListT m) a)) and give it a nice Monad instance. Then you can prune and filter trees in a natural way, inside the monad. apfelmus wrote: Eh, isn't that what ListT is already for? ...allows you to prune the directory tree in whatever way you like it. Here's an example top-down traversal that lists all non-directories: allFiles :: MonadIO m = Directory - m [FilePath] allFiles d = runList $ do f - liftList $ contents d if isDirectory f then allFiles f else return f In other words, ListT is like one of those iterators I keep hearing from the Python/Java/.../imperative world Well, yes, you could also use it that way. And yes, years ago they used to do it that way in Python. Where every user has to build in the logic to discover the tree structure manually, as they iterate along. But it turns out that it is much more natural and convenient to be given the tree structure pre-built, and then just traverse it. You need some laziness to avoid visiting directories that you don't care about and might be costly to visit. Python currently uses generators to get the laziness. Bryan uses unsafe IO, together with his recursion predicates and filter predicates. My first proposal was just a minor modification of Bryan's ideas. I presented the tree pre-traversed - i.e., flattened, like Bryan, and also used his predicates. But I used ListT to provide the laziness instead of unsafe IO. My second proposal is to present the entire tree inside a lazy monad transformer. While the internal plumbing is slightly more complex, I think it will provide the most natural and convenient interface for the end user (who needs not understand all that monad stuff). -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
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 I will reply to this email with a single line of code that does it. Sorry, I can't resist :) 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 differences in amount of documentation. Maybe you could expand on that a bit? Well firstly, I never said that your approach is not good. I was very pleased to see your work on this, and I was inspired by it. I do think that it is much better to provide IO laziness using monad transformers (or whatever) rather than unsafe IO. The basic difference is that with unsafe IO, you relinquish control over the order in which things happen, and leave it to the whims of the compiler/runtime. Besides the fact that it can always lead to bugs (viz. the constant problems people have with readFile and getContents), in this case the exact order of the side effects happens to be a critical and delicate issue, so you really don't want to give up that control here. My second proposal introduces another deviation from your approach in that it presents a full tree view rather than a pre-flattened tree view. I think that is more natural and more flexible - just my own taste. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Let's do ListT right, finally
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 monad any differently from monad in Haskell. And so it's been shoehorned into the wrong type class. The replacement ListT is usually the monad transformer I need when I want a List-like monad transformer, so I'm all for it being in the standard prelude. But it seems sad there isn't a place for the old one to live. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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, seriously. The basic idea was that there used to be about two-dozen languages like Haskell, but all developed by different people and all with different syntax and so on. So they wanted to create a single language suitable for teaching to students. You could say it's the Pascal of the functional world... Hey, maybe that explains the lack of success?) 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 necessarily say that, but it is a widely held and propagated misconception.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
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 a few examples of its use. I'm also interested in a more structured approach to lazy reading of data. I used unsafeInterleaveIO several times (including readFile) and got several problems including too many open files. Problems, that are certainly solved easily if you have more control over the IO laziness. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
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 go to the end of the list to start outputting, so it has to keep all elements in memory somewhere at least in one moment of time. That means that the program has space complexity of O(m) -- the other functions are all O(1) in terms of line count. You may try this version instead: main n = print . sum . map read . head . dropWhile (not . null . drop n) . tails . lines = getContents where I changed (take n . reverse) to (head . dropWhile (not . null . drop n) . tails). Yes, I cheated, I'm using Data.List =). With this version you keep only n lines in memory at any moment, so it has space complexity of O(n). Please anybody correct me if I'm wrong. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Let's do ListT right, finally
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 ListT m is a fully paid up monad, not just in some sense. On a brief definition of commutative monads, and for some examples indicating how common they are, see SPJ's http://research.microsoft.com/~simonpj/papers/haskell-retrospective/HaskellRetrospective-2.pdf OK, do you propose that we keep it and change its name? +1, dump the old one completely because you can't express what kind of thing the old ListT is in Haskell. I just want to make sure it gets a good epitaph. If someone answers SPJ's challenge #2 maybe it'll come back. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 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 languages. But thanks to Haskell, I found the vibes again! Oh, I wont deny Haskell is fun; wouldnt be here otherwise. Useful? Different question ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
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 10/14/07, apfelmus [EMAIL PROTECTED] wrote: 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 will reply to this email with a single line of code that does it. Sorry, I can't resist :) main n = print . sum . map read . take n . reverse . lines = getContents I'm not saying that it's impossible to go directly to Haskell, I'm saying that it's just very very hard. [] 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. They should start with either Ocaml or SML first. If it makes it easier to accept this argument, you can consider Ocaml and SML as Haskell with training wheels. I don't agree. At least, it was different for myself. Looking at the line of code above, I can't help it, but I perceive Haskell as being the _simplest_ programming language in the whole world. I had no trouble learning it (step by step from a book), maybe because I've happily thrown away everything I (thought I) knew (about programming). The reward was worth it. Why do people want side effects? Purity is soo much simpler. Regards, apfelmus ___ 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] Let's do ListT right, finally
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. The problem is that you can't express commutative monad any differently from monad in Haskell. And so it's been shoehorned into the wrong type class. 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. For example, class Monad m = CommutativeMonad m instance (CommutativeMonad m) = Monad (ListT m) where return a = ListT (return [a]) etc. Naturally, it's up to the programmer to guarantee that instances of CommutativeMonad are actually commutative monads. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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 use those SDL bindings to plot pixels with OpenGL and play with 3D stuff in Haskell. ___ 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] Categories in base
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 -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haskell-curry, classical logic, excluded middle
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. Is this error I'm getting
(inline at the end) easily fixed, and what exactly is going on?
code ---
{-# OPTIONS_GHC -fglasgow-exts #-}
module Classic where
{-
Classic logic. (See Intuit.hs first).
In this system propositions all take a continuation. This allows
us to define the law of the excluded middle.
-}
import Control.Monad
-- propositions are functions taking a continuation.
data Prop r p = Prop ((p - r) - r)
run :: Prop r p - (p - r) - r
run (Prop f) k = f k
propCC :: ((p - Prop r q) - Prop r p) - Prop r p
propCC f = Prop (\k - run (f (\a - Prop (\k' - k a))) k)
instance Monad (Prop r) where
return p = Prop (\c - c p)
p = mkq = Prop (\c - run p (\r - run (mkq r) c))
data TRUTH = TRUTH
type FALSE r = Not r TRUTH
data And r p q = And (Prop r p) (Prop r q)
data Or r p q = OrL (Prop r p) | OrR (Prop r q)
data Imp r p q = Imp (Prop r p - Prop r q)
data Equiv r p q = Equiv (Prop r p - Prop r q) (Prop r q - Prop r p)
data Not r p = Not (forall q. (Prop r p - Prop r q))
-- Truth
truth :: Prop r TRUTH
truth = return TRUTH
-- And-Injection
-- P, Q |- P /\ Q
andInj :: Prop r p - Prop r q - Prop r (And r p q)
andInj p q = return (And p q)
-- And-Elimination, left and Right
-- P /\ Q |- P
andElimL :: Prop r (And r p q) - Prop r p
andElimL pq = pq = \(And p q) - p
-- P /\ Q |- Q
andElimR :: Prop r (And r p q) - Prop r q
andElimR pq = pq = \(And p q) - q
-- Or-Injection, left and right
-- P |- P \/ Q
orInjL :: Prop r p - Prop r (Or r p q)
orInjL p = return (OrL p)
-- Q |- P \/ Q
orInjR :: Prop r q - Prop r (Or r p q)
orInjR q = return (OrR q)
-- Or-Elimination.
-- P \/ Q, P - R, Q - R |- R
orElim :: Prop r (Or r p q) - (Prop r p - Prop r s) - (Prop r q - Prop r s)
- Prop r s
orElim pORq p2r q2r = pORq = byCases
where byCases (OrL p) = p2r p
byCases (OrR q) = q2r q
-- Implication-Injection
-- (P |- Q) |- P - Q
impInj :: (Prop r p - Prop r q) - Prop r (Imp r p q)
impInj p2q = return (Imp p2q)
-- Implication-elimination (modus ponen)
-- P, P - Q |- Q
impElim :: Prop r p - Prop r (Imp r p q) - Prop r q
impElim p pIMPq = pIMPq = \(Imp p2q) - p2q p
-- Equivalence-Injection
-- P - Q, Q - P |- P = Q
equivInj :: Prop r (Imp r p q) - Prop r (Imp r q p) - Prop r (Equiv r p q)
equivInj pIMPq qIMPp = do
(Imp p2q) - pIMPq
(Imp q2p) - qIMPp
return (Equiv p2q q2p)
-- Equivalence-Elimination, Left and Right
-- P = Q |- P - Q
equivElimL :: Prop r (Equiv r p q) - Prop r (Imp r p q)
equivElimL pEQq = pEQq = \(Equiv p2q q2p) - return (Imp p2q)
equivElimR :: Prop r (Equiv r p q) - Prop r (Imp r q p)
equivElimR pEQq = pEQq = \(Equiv p2q q2p) - return (Imp q2p)
-- Absurdity
-- False |- P
absurd :: Prop r (FALSE r) - Prop r p
absurd false = false = \(Not true2p) - true2p truth
-- Not-Inj
-- (P |- False) |- ~P
notInj :: forall r p. (Prop r p - Prop r (FALSE r)) - Prop r (Not r p)
notInj p2false = return (Not p2any)
where p2any :: forall q. Prop r p - Prop r q
p2any assumep = absurd (p2false assumep)
-- Not-Elimination
-- P, ~P |- Q
notElim :: Prop r p - Prop r (Not r p) - Prop r q
notElim p np = np = \(Not p2any) - p2any p
-- Excluded-Middle
-- P \/ ~P
exclMiddle :: forall r p. Prop r (Or r p (Not r p))
exclMiddle = propCC func1
where func1 :: (Or r p (Not r p) - Prop r q) - Prop r (Or r p (Not r p))
-- k :: Or r p (Not r p) - Prop r q
func1 k = return (OrR (return (Not func2)))
where func2 :: Prop r p - Prop r q
func2 k' = k (OrL k')
{-
http://www.cse.ogi.edu/~magnus/mdo-callcc-slides.pdf
-- A \/ ~A
excmid :: Either a (a - b)
excmid = callcc (\k. Right (\a.k (Left a)))
-}
{-
Classic2.hs:114:27:
Couldn't match expected type `q' (a rigid variable)
against inferred type `q1' (a rigid variable)
`q' is bound by the type signature for `func2'
at Classic2.hs:113:44
`q1' is bound by the type signature for `func1'
at Classic2.hs:110:45
Expected type: Prop r q
Inferred type: Prop r q1
In the expression: k (OrL k')
In the definition of `func2': func2 k' = k (OrL k')
-}
-- False-Elimination
-- (~P |- False) |- P
Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
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 almost all the way there, but its still not quite right. Is this error I'm getting (inline at the end) easily fixed, and what exactly is going on? I'll admit this is a cursory response, but (to my understanding) excluded middle doesn't hold in the Curry-Howard correspondence. It is an isomorphism between *constructive* logic and types; excluded middle is a nonconstructive axiom. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: On the verge of ... giving up!
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 will buffer up all the lines before it gives any back, which is a well known property of reverse. You could rewrite (take n . reverse) as a function that only requires n lines of buffer. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
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 stuck on the excluded-middle, and I think now I got it almost all the way there, but its still not quite right. Is this error I'm getting (inline at the end) easily fixed, and what exactly is going on? I'll admit this is a cursory response, but (to my understanding) excluded middle doesn't hold in the Curry-Howard correspondence. It is an isomorphism between *constructive* logic and types; excluded middle is a nonconstructive axiom. It's possible to embed the classical propositional logic into the intuitionistic propositional logic. Kolmogorov invented the typed CPS transform long before we even had programming languages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Laziness (was: [Haskell-cafe] Performance problem with random numbers)
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 unevaluated thunks, their forcing will generally be attributed to them, not to functions within the thunks. (Yes, this means profiling lazy programs is a bit of a black art.) After more testing I finally realized how right you are. It appears that my problem is not related to random/randomR but only to laziness. I came up with a test that doesn't use random numbers at all and still needs about 2.5 seconds to complete (it is really just meaningless computations): module Main where import Data.List main :: IO () main = do let n = 100 :: Int print $ foldl' (\x y - seq y x) 0 (take n $ test 1 [1,2..]) test :: Int - [Int] - [Int] test t g = let (n, g') = next t g in n:test t g' next :: Int - [Int] - (Int, [Int]) next x (y:ys) = let n = func y in if n = 0.5 then (x, ys) else (0, ys) where func x = fromIntegral x / (10 ^ len x) where len 0 = 0 len n = 1 + len (n `div` 10) 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 working well enough here? Thanks, Thoralf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Let's do ListT right, finally
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 applications use the new ListT. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
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 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. Is this error I'm getting
(inline at the end) easily fixed, and what exactly is going on?
code ---
{-# OPTIONS_GHC -fglasgow-exts #-}
module Classic where
{-
Classic logic. (See Intuit.hs first).
In this system propositions all take a continuation. This allows
us to define the law of the excluded middle.
-}
import Control.Monad
-- propositions are functions taking a continuation.
data Prop r p = Prop ((p - r) - r)
run :: Prop r p - (p - r) - r
run (Prop f) k = f k
propCC :: ((p - Prop r q) - Prop r p) - Prop r p
propCC f = Prop (\k - run (f (\a - Prop (\k' - k a))) k)
instance Monad (Prop r) where
return p = Prop (\c - c p)
p = mkq = Prop (\c - run p (\r - run (mkq r) c))
data TRUTH = TRUTH
type FALSE r = Not r TRUTH
data And r p q = And (Prop r p) (Prop r q)
data Or r p q = OrL (Prop r p) | OrR (Prop r q)
data Imp r p q = Imp (Prop r p - Prop r q)
data Equiv r p q = Equiv (Prop r p - Prop r q) (Prop r q - Prop r p)
data Not r p = Not (forall q. (Prop r p - Prop r q))
-- Truth
truth :: Prop r TRUTH
truth = return TRUTH
-- And-Injection
-- P, Q |- P /\ Q
andInj :: Prop r p - Prop r q - Prop r (And r p q)
andInj p q = return (And p q)
-- And-Elimination, left and Right
-- P /\ Q |- P
andElimL :: Prop r (And r p q) - Prop r p
andElimL pq = pq = \(And p q) - p
-- P /\ Q |- Q
andElimR :: Prop r (And r p q) - Prop r q
andElimR pq = pq = \(And p q) - q
-- Or-Injection, left and right
-- P |- P \/ Q
orInjL :: Prop r p - Prop r (Or r p q)
orInjL p = return (OrL p)
-- Q |- P \/ Q
orInjR :: Prop r q - Prop r (Or r p q)
orInjR q = return (OrR q)
-- Or-Elimination.
-- P \/ Q, P - R, Q - R |- R
orElim :: Prop r (Or r p q) - (Prop r p - Prop r s) - (Prop r q - Prop
r s) - Prop r s
orElim pORq p2r q2r = pORq = byCases
where byCases (OrL p) = p2r p
byCases (OrR q) = q2r q
-- Implication-Injection
-- (P |- Q) |- P - Q
impInj :: (Prop r p - Prop r q) - Prop r (Imp r p q)
impInj p2q = return (Imp p2q)
-- Implication-elimination (modus ponen)
-- P, P - Q |- Q
impElim :: Prop r p - Prop r (Imp r p q) - Prop r q
impElim p pIMPq = pIMPq = \(Imp p2q) - p2q p
-- Equivalence-Injection
-- P - Q, Q - P |- P = Q
equivInj :: Prop r (Imp r p q) - Prop r (Imp r q p) - Prop r (Equiv r p
q)
equivInj pIMPq qIMPp = do
(Imp p2q) - pIMPq
(Imp q2p) - qIMPp
return (Equiv p2q q2p)
-- Equivalence-Elimination, Left and Right
-- P = Q |- P - Q
equivElimL :: Prop r (Equiv r p q) - Prop r (Imp r p q)
equivElimL pEQq = pEQq = \(Equiv p2q q2p) - return (Imp p2q)
equivElimR :: Prop r (Equiv r p q) - Prop r (Imp r q p)
equivElimR pEQq = pEQq = \(Equiv p2q q2p) - return (Imp q2p)
-- Absurdity
-- False |- P
absurd :: Prop r (FALSE r) - Prop r p
absurd false = false = \(Not true2p) - true2p truth
-- Not-Inj
-- (P |- False) |- ~P
notInj :: forall r p. (Prop r p - Prop r (FALSE r)) - Prop r (Not r p)
notInj p2false = return (Not p2any)
where p2any :: forall q. Prop r p - Prop r q
p2any assumep = absurd (p2false assumep)
-- Not-Elimination
-- P, ~P |- Q
notElim :: Prop r p - Prop r (Not r p) - Prop r q
notElim p np = np = \(Not p2any) - p2any p
-- Excluded-Middle
-- P \/ ~P
exclMiddle :: forall r p. Prop r (Or r p (Not r p))
exclMiddle = propCC func1
where func1 :: (Or r p (Not r p) - Prop r q) - Prop r (Or r p (Not r
p))
-- k :: Or r p (Not r p) - Prop r q
func1 k = return (OrR (return (Not func2)))
where func2 :: Prop r p - Prop r q
func2 k' = k (OrL k')
{-
http://www.cse.ogi.edu/~magnus/mdo-callcc-slides.pdf
-- A \/ ~A
excmid :: Either a (a - b)
excmid = callcc (\k. Right (\a.k (Left a)))
-}
{-
Classic2.hs:114:27:
Couldn't match expected type `q' (a rigid variable)
against inferred type `q1' (a rigid variable)
`q' is bound by the type signature for `func2'
at Classic2.hs:113:44
`q1' is bound by the type signature for `func1'
at Classic2.hs:110:45
Expected type: Prop r q
Inferred type: Prop r q1
In the expression: k (OrL k')
In the definition of `func2': func2 k' = k (OrL k')
-}
-- False-Elimination
-- (~P |- False) |- P
Tim Newsham
http://www.thenewsh.com/~newsham/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Laziness (was: [Haskell-cafe] Performance problem with random numbers)
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 working well enough here? Unfortunately I'm not so good at that myself. Even more unfortunately, my understanding is that randomly using seq and/or $! not only usually doesn't help, but can actually make things slower; and to do it right, you need to refer to the simplified Core Haskell code generated by GHC. And understanding *that* requires rather more familiarity with Core than I have. :/ -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Laziness (was: [Haskell-cafe] Performance problem with random numbers)
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 data structure for my random module and lazy lists are simply not working well enough here? Unfortunately I'm not so good at that myself. Even more unfortunately, my understanding is that randomly using seq and/or $! not only usually doesn't help, but can actually make things slower; and to do it right, you need to refer to the simplified Core Haskell code generated by GHC. And understanding *that* requires rather more familiarity with Core than I have. :/ A lot of times just unfolding a few evaluations by hand (perhaps mentally) will point out issues readily and readily suggest there solution. After a while you will know what kinds of things are problematic and not write such code to begin with. Unfortunately, this is not something widely and well understood and is not part of almost any of the available educational material for Haskell. Programming in a lazy language is more different than programming in an eager one than almost any resource states. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan... (A long speculation)
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), sure. There is no macro processing in R (or S). I know I've been superficial, but, please, *try* to understand my point. Before anyone can try to understand a point, it has to be made. There is a cheap (not always) way of making everything lazy, by rewriting. If an expression is the argument of a function, what is passed is the representation of this expression. This gets evaluated in the context of the caller function, although perhaps in the environment of the argument itself, if there are external references. It is something *similar* to macros, and it is more or less what I understood from my - admittedly weak - knowledge of R, S, etc. (Frankly, I do not know them enough to make the difference). But this is not the same as the laziness - realization of the normal order of evaluation, call by name (need), etc. First off, as someone who has implemented a couple of macro processors, I completely fail to see any similarity between S/R arguments and macro processing. YES an (expression, environment) pair is passed. But can you try to see *my* point? HOW THE THING IS IMPLEMENTED is completely unimportant (except that the approach S and R take makes strictly more things possible than the approach that GHC takes). What matters is WHAT THE BEHAVIOUR IS. And what you get is *precisely* call by need. There is a difference between call by name, and by reference. I know that; the implementors of R (one of whom I know) know that also. The contrast is precisely a contrast against call by *reference* because the *language* contrast that was salient for most S users was the contrast between S and Fortran, and it is pass by reference that Fortran has, not call by name. Right. But then, laziness *AND* side effects may put you in a nice mess... Indeed it does. I didn't say I thought it was a *good* mix, just that it *exists*. Now, the discussion began with ideas how to advertize *functional* languages, not packages with dangerous, non-formalizable semantics, I do not know where you get the idea that S semantics is not formalisable. The principal S reference contains a meta-circular interpreter. Can lead the unwary into traps is not at all the same as cannot be formalised. OF COURSE, there are untyped languages with suspended evaluation. Snobol had unevaluated expressions, Icon has co-expressions, etc. This is once again to evade the point. (As it happens, I have, and occasionally use, both Icon and SNOBOL. I wonder how many other SNOBOL users remain.) In SNOBOL and Icon these things are *exceptions*; the normal argument passing convention is otherwise. In S (and therefore R), there is, as in Haskell, only ONE way to pass arguments, and that is call by need. Call by need in R is *not* exceptional. It isn't even just the norm. It is the *only* argument passing technique on offer. But if the merits of FL include some protection against errors, issued from enforcing a concrete programming discipline, R doesn't seem to me a good example. I was on the R mailing list for a couple of years. What a torrent of messages that was! Interestingly, the troubles you fear (with a mix of imperative actions and call by need) do not seem to be troublesome in practice. There really doesn't seem to be much if any need to protect against *those* errors. One of the commonest mistakes is using (or |) where (or ||) should have been used, and this is something that a type system might have helped with. But it is precisely a dynamically typed lazy language you were after, so the lack of a static type system has more to do with errors than the possibility of mixing imperative actions with laziness is probably something you do not want to hear. I wrote: I don't know what co-inductive constructions are. OK, try to code in R the list [0,1,2,3, ...] using a co-recursive data definition, You can safely assume that someone who doesn't know what co-inductive constructions are also doesn't know what co-recursive data definitions are. (doesn't know as in is unfamiliar with the jargon, not as in has never met the concept.) in Haskell: integs = 0 : (ones + integs) where ones = 1 : ones and where (+) acts on lists element-wise. I believe I already explained the reason that this is hard in R: it doesn't evaluate *arguments* but it does fully evaluate *results*. I think that's a much more insightful thing to say about R than to go on misleadingly about macros. Let's leave R behind. 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
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
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 postings with attention, since I disagree jerzy with spreading such atmosphere. And A.C. additionally wrote jerzy that all this theory has nothing to do with Haskell, and jerzy submitted three more postings, one more dubious than the jerzy other, I found that a warning seems suitable, not for him, jerzy but for his readers! I'm an (almost) complete newbie to FP and for a beginner I don't see some right in myself to criticize theory being hard. I'm a CS guy without any background in Category Theory and related ideas, but when I see something elegant, I think I recognize it, and monads seem to be much elegant way of doing things than usual I/O. (And because of this elegance I couldn't persuade myself to learn OCam'l etc. first) Currently I can't say I understand monads, but as Von Neumann put it, Young man, in mathematics you don't understand things. You just get used to them. ;) jerzy Mathematics is beautiful and useful. The commutativity of jerzy some categorical diagrams can be translated into the jerzy optimization of Haskell constructs, say, showing that there jerzy is a canonical isomorphism between jerzy (map f) . (map g) and: map (f . g) jerzy etc. So, why dump the theory away, which suggests jerzy additionally that the conceptors of Haskell are jerzy irresponsible dreamers, living on some crystal jerzy mountain?... The language is not trivial to learn, that's jerzy it. If somebody feels discouraged, my own students often jerzy are, then the recipe is simple: ask CONCRETE questions, get jerzy CONCRETE answer. THEN generalize. I asked Paul Hudak a few days ago about an exercise in his Haskell SOE book and I got more than I expected. (Prior to that, I asked in #haskell and also got more than I expected, though not understood all of them ;)) jerzy But if some people offer general answers, they must be jerzy based on a real competence and experience, otherwise they jerzy easily become harmful. Being friendly is one thing, but being sensitive about the information is much more valuable IMO. I thank you for deciding to post this disclaimer instead of overlooking, which is perhaps the easier way. jerzy == jerzy David48 points out that if a list returns the reader to jerzy the docs which he has already seen, and which is poor, then jerzy it doesn't work at all. OK, then, once more, don't say I jerzy cannot understand monads, or rewriting, or whatever, but jerzy say plainly: I read XYZ in the ABC tutorial, and the jerzy example PQR remains too difficult. And say WHAT doesn't jerzy work. jerzy Go ahead, criticize *concrete* documentation, don't say jerzy that docs are lousy! Almost all Haskell documentation has jerzy been written by people who *beg* constantly for comments, jerzy for criticism; let's help them instead of shouting at them. jerzy Of course, the repeated, ever and ever again questions mean jerzy that one day it will be absolutely necessary to make a true jerzy FABQ, proposed a few times, and still in statu nascendi... I'm 27 years old and somehow programming for ~12 years in almost all major imperative languages. (I have some Scheme Lisp experience also.) As another poster mentioned, this language gave me long forgotten excitement of programming again. Though I feel myself too lazy to cope with problems (and obstacles in learning and changing mindset) sometimes, and I usually don't understand topics in this mailing list most of the time, I don't attribute these to difficulty of the language. This is my laziness, not Haskell's. If I would like to program in more understandable ways, I know there are lots and lots of other languages that I can use, but trying to come up with a solution and seeing how succint it can be amazes me in this language and I don't know if I can be a successful Haskell programmer (and write those haikus you write here and there), but at least I'll try to be and if I can't, this will be my laziness, not Haskell's. Thanks and best regards, E. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 necessarily say that, but it is a widely held and propagated misconception.) I'd argue that you're kind of both right. The purpose of Haskell (i.e. Haskell 89) was to unify all of those Miranda-like systems into a single language that everyone could share. However, arguably the biggest imperatives for Haskell 98 was to remove features that would confuse undergraduates. Even though we may not like to admit it, H98 really is primarily a teaching/research language. If we were doing H98 today, I don't think that would happen. The research part is bigger and better than ever, but we seem to weight applications, including building large systems more highly than teaching now. Having said that, in retrospect, the clean break was probably for the best. H98 gave us a simpler core on which to add the glasgow-exts. 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. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pixel plotter
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 nowhere fast with this. Anybody have any suggestions? Despite having a large API gtk2hs is pretty easy to use for these kind of tasks. You can look at this library [1] (for plotting charts) to see simple examples of opening windows, saving images etc. It uses the (nice) 2D cairo API for drawing, though it's not too hard to work with raw pixels via the functions in Graphics.UI.Gtk.Gdk.Pixbuf. You'll need to restrict your drawing calls to a single thread - most GUI toolkits will require this. Haskell makes this easy through its ability to pass drawing actions from thread to thread. Tim [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Chart-2007.8.8 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan... (A long speculation)
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 doesn't unveil his name. Just OK as login, even since 1979, is still anonymous, whatever you may say. It might the be anything, for example Richard O'Keefe, or something else. Or perhaps I am again completely wrong, as in the case of R not being something I ever wanted? 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 show that the thing can be done. Well, puisque Catherine Recanati est Française, I should have heard about that thesis... (1986 if I am not mistaken). Seems abandoned. And also another French lazy Scheme called Help, of Thomas Schiex, also a PhD work... (1992, unless I am wrong) Also abandoned, at least according to what Thomas S. told me some time ago. So, if you really insist, you may safely say that claiming that there are no dynamically typed functional languages, I lied as a dog. Still, if you look around you, there are no dynamically typed functional languages. You may now continue this hair-splitting discussion, chapeau bas. Yours, J.K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
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? :-) http://homepage.mac.com/sigfpe/Computing/peano.html Having switched from C++ to Haskell (at least in my spare time) I thought I'd escaped that kind of type hackery but it seems to be following me... The way I see, we are trying to come up with a clean way of providing type-level computations (ie, we use and extend the standard theory of HM type systems). C++ embedded a functional language in the type systems mostly by accident, whereas we do it on purpose. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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, what I regret, but just a tiny bit, is that (:) is not an operator as any other, but a syntactic construct. (Well, who cares, unless you try to make your own lists, with different precedence, etc...) Also, monadic comprehensions, which disappeared in order to remove too much of ambiguity... Anything else worth mentioning? What *negative* has been suppressed? Frankly, I regret the times when Mark Jones made his revolutions within Gofer, proposing constructor classes, etc. At that time we knew that Haskell was for the brave, not for people making money... Almost everybody was a newbie. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan... (A long speculation), To: haskell-cafe Cafe haskell-cafe@haskell.org
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 show that the thing can be done. There is also the Lazy Scheme language level in recent releases of DrScheme. http://www.ccs.neu.edu/scheme/pubs/fdpe05-bc.pdf It is syntactic sugar over promises, so its primary use would be in education. It would make a lovely segue between Scheme and Haskell. --PR ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 ignorance. I think the only difference is that object is a more accessible name than monad. instance WarmFuzzyThing IO where ... Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 page. It's better than most of the tutorials out there. (I think you have to luck out with the right topic.) Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan... (A long speculation)
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, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 punning (slightly) For me, from the ancient times, what I regret, but just a tiny bit, is that (:) is not an operator as any other, but a syntactic construct. I agree with that in principle; it's unfortunate that lists are built in as much as they are. But I can't say I really miss this. Also, monadic comprehensions, which disappeared in order to remove too much of ambiguity... Five years ago, I would have agreed. I'm over that now, and do-notation is more useful. Anything else worth mentioning? What *negative* has been suppressed? I mentioned the un-generalising of map above. That probably needs some justification. I think that the best evidence of why this was a mistake is the fact that many modules implement a namespace-overloaded map. Data.Map.map springs to mind, but there are others. People want to write map instead of fmap. We could have come up with an alternative name for the list-version of map and not showed map to newbies. (Having said that, some of the un-overloading was good. I'm happy, for example, to reserve concat for lists and use join for monads.) Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 with pure functional languages. When you move from, say C/Pascal/Fortran to Java/Ruby/Python, you don't have to learn new data structures and new algorithms. A doubly linked list is still just a doubly linked list, still has the same properties, and still has more or less the same implementation. In addition to learning Haskell, you also need to relearn basic computer science. You need to learn what a realtime lazy catenable dequeue is, how to implement it, and why you need one, all the while struggling with the syntax, type errors, and all the other problems trying to learning a new language. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 authors carefully bypass any mention of categories. It's like talking about electricity without using calculus. Good enough to replace a fuse, not good enough to design an amplifier. /quote It is true that Haskell Monads are inspired by category theory. It is also true that all the operations you need for something to be a category theoretic monad are available for Haskell Monads. HOWEVER You don't need to know that. Many Haskell programmers not only don't understand anything much about categories, they will never understand anything much about categories, and it doesn't matter. (After years of study, I can now get *to* chapter 3 in the typical introduction to category theory* book, but not *through* it.) 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 might do in another language) goes like this: A type constructor that belongs to the Monad class can be used to sequence actions over some kind of hidden state. Each of these actions has an effect and a value. For example, getChar has the effect of reading a character from standard input, and the character it read as its value. For example, putChar x has the effect of writing a character to standard output, and () as its value because there isn't anything else useful to return. All monad instances must provide fail msgmsg is an error message; this reports an error. return valuean action with value as its value and no effect act1 act2 the effect of (act1 then act2) and the value of act. THIS IS JUST LIKE SEMICOLON IN TRADITIONAL LANGUAGES. act1 = actf2the effect of (act1 then (act2f x)) with the value of act2f x, where x is the value of act1. Each monad also typically comes with a function that takes an action and an initial state and performs the action and returns its value. That function's name usually starts with run. For the IO monad, the hidden state is the state of the world, including I/O devices, and the run step is done just outside your 'main' function. In order to have an I/O action performed you should ensure that it is chained into the sequence actions starting from main and linked by and = . That's really all you have to know. The I/O actions in Haskell look uncommonly like C, and if you can do I/O in C you *can* do I/O in Haskell without even knowing how to spell 'Category Theory'. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: On the verge of ... giving up!
[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 Kalman filters: http://www.cs.unc.edu/~welch/kalman/maybeck.html -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Inspired by http://www.xkcd.com/327/, I am considering changing my name to Chung-chieh ');DROP TABLE EMPLOYEES;-- Shan to see if anything breaks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up!
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 might do in another language) goes like this: (...) I like an explanation dons gave once the best: A Monad is a programmable semicolon. That pretty much sums it up, nice and simple. Everything else is just scaffolding. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
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 spreading such atmosphere. And A.C. additionally wrote that all this theory has nothing to do with Haskell, and submitted three more postings, one more dubious than the other, I found that a warning seems suitable, not for him, but for his readers! I hope we can agree on several things here: (1) The mathematical background of Haskell is one of the things that makes Haskell a beautiful and useful programming language. It may even be one of the most important factors. (2) The mathematical background of Haskell is extremely important for implementations. Some important data structures and techniques are practical in large part because of the kinds of optimisations that are only straightforward in a language that has such foundations. (3) Beginners do not need to understand all the mathematics behind Haskell to use it. I really really hope we can agree on the next two points: (4) It is not unfair to describe Category Theory as The mathematical study of sound analogies between mathematical structures; it leads to concepts of great generality and power, and encourages a consistent use of terminology which makes it easier to transfer ideas and techniques from one area of mathematics to another. It's about *consistently* pushing generality rather hard. (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 may in fact be eminently practical) tend to be presented in a way which people trying to study by themselves have trouble with. So people can be scared off by what _ought_ to be a big help to them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
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 p)) Yup! That did it, thanks! Now that that works, one more question. Is it possible to hide the r that is attached to every single type? For example to do something like this (which doesn't compile): data Prop p = Prop (forall r. (p - r) - r) run :: Prop p - (p - r) - r run (Prop f) k = f k propCC :: ((forall q. p - Prop q) - Prop p) - Prop p propCC f = Prop (\k - run (f (\a - Prop (\k' - k a))) k) Zun. Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell-curry, classical logic, excluded middle
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 . Or r p (Not r p) - Prop r q) - Prop r (Or r p (Not r p)) Yup! That did it, thanks! Now that that works, one more question. Is it possible to hide the r that is attached to every single type? For example to do something like this (which doesn't compile): data Prop p = Prop (forall r. (p - r) - r) run :: Prop p - (p - r) - r run (Prop f) k = f k propCC :: ((forall q. p - Prop q) - Prop p) - Prop p propCC f = Prop (\k - run (f (\a - Prop (\k' - k a))) k) This interesting paper, http://pllab.is.ocha.ac.jp/~asai/papers/tr07-1abs.html suggests that that might actually not be ideal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
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 may in fact be eminently practical) tend to be presented in a way which people trying to study by themselves have trouble with. So people can be scared off by what _ought_ to be a big help to them. I agree, but I don't think it needs to be this way. Books on category theory tend to be written for mathematicians or computer scientists who already grok the things that need generalising, even understand in a general sense how they're similar, and really just need to learn the language to express what they already know. In one respect, this makes sense (you learn the concrete, then you learn how to abstract away the details), but it also raises the barrier to the point where in learning mathematics, you're really learning history. Mathematics isn't immune from this, of course. Many scientists in disparate fields have complained that textbooks for their fields are really history books in disguise, and the material is more confused and tedious than it needs to be as a result. Example complaints: http://insti.physics.sunysb.edu/~siegel/history.html http://jchemed.chem.wisc.edu/journal/issues/1998/jul/abs817.html Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] On the verge of ... giving up! [OT]
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, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
