Re: [Haskell-cafe] Can I have a typeclass for topological spaces?
You may want to, instead, check out the methods of point-free topology (also known as pointless topology) where you, basically, study topological spaces in terms of their open-set lattices. This allows you to use a more algebraic language which probably fits better into Haskell (I think this is used, for example, when studying topology within type theories). A search for stone-duality should give you somewhere to start (I know there are a sequence of posts on http://topologicalmusings.wordpress.com/ on the subject). Somewhat less known is the theory of formal topology (see for example n-lab http://ncatlab.org/nlab/show/formal+topology). Which might also be an approach to doing some topology in Haskell. Hope that's of some help :) On 11/08/2011, Grigory Sarnitskiy sargrig...@ya.ru wrote: Hello! I just wonder whether it is possible to have a typeclass for topological spaces? ___ 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] Re: Fwd: Semantics of iteratees, enumerators, enumeratees?
On 26/08/2010, Daniel Fischer daniel.is.fisc...@web.de wrote: [...] Well, I just gave an example where one would want chunking for reasons other than performance. That iteratees don't provide the desired functionality is a different matter. [...] In the case of hashing, wouldn't it be more reasonable to consider iterators over streams of fixed (or at least predictable) sized chunks (where a set of chunks can themselves be chunked), with the chunking behaviour being given by another iteratee over the original stream? It seems to me that one of the major points of iteratees is to provide an abstraction from the kind of chunking irrelevant to the parsing logic, otherwise I fail to see any difference (at least relevant to chunking) to plain strict IO. I'm not particularly well read on anything here, so I could just totally miss what is going on, in which case I apologise. //Tilo Wiklund ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Heavy lift-ing
I think the point that was being made is that:
liftM2 (flip f) /= flip (liftM2 f)
This is because the former (well: liftM2 (flip f) a b) effectively does:
do {x - a; y - b; return (f y x)}
Whereas the latter (flip (liftM2 f) a b) effectively does:
do {y - b; x - a; return (f y x)}
That is, the order of the arguments to liftM2 matters because they are
executed in that order. So lifting the flipped function has a different
effect to flipping the lifted function.
Thanks,
Neil.
Thanks, I can see how that could lead to confusion.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Heavy lift-ing
On 24/07/2010, aditya siram aditya.si...@gmail.com wrote: Perhaps I'm being unclear again. All I was trying to say was that: liftM2 (-) [0,1] [2,3] /= liftM2 (-) [2,3] [0,1] -deech I'm sorry if I'm bumping an old thread, but why should liftM2 f be commutative when f isn't? (I hope I'm not responding incorrectly) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Iteratee rest and monad instance
I've mostly been studying the Iteratee IO slides (with notes), so these things may already have been noted elsewhere (though I have not been able to find them with my cursory search). Also excuse my probably somewhat confused terminology, I hope I get the point across anyway. In both the slides and the current hackage package finished iteratees carry with them (in the constructor) the rest of the stream. I may miss something obvious here, but this seems to lead to some fishy details in the monad instance of iteratees presented in the slides. Firstly the iteratee given by return/pure has to carry with it a rest before a stream comes into the picture, though I guess one could argue that (Chunk ) is some kind of identity but this does not seem to be enforced in any way. Furthermore in the bind operator the rest of the iteratee from the bound (RHS) function seems to be ignored at some times and not at others (depending on the rest of the bound LHS value). I am probably missing something obvious or something relating to optimisation/server software but defining iteratees as Iteratee s a = Cont (s - Either (s, a) (Iteratee s a)) seems to lead to a more natural monad instance, and does not suffer from (what seems to me to be an issue) having to make predictions about the stream it will be passed. My question is thus, why the rest stream has to be carried by an Iteratee constructor, rather then be part of the value of the continuation function. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Float instance of 'read'
Wouldn't that make it hard to parse lists of floats? On Tue, 2008-09-16 at 09:29 -0300, Mauricio wrote: Hi, A small annoyance some users outside english speaking countries usually experiment when learning programming languages is that real numbers use a '.' instead of ','. Of course, that is not such a problem except for the inconsistence between computer and free hand notation. Do you think 'read' (actually, 'readsPrec'?) could be made to also read the international convention (ie., read 1,5 would also work besides read 1.5)? I'm happy to finaly use a language where I can use words of my language to name variables, so I wonder if we could also make that step. Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
