Re: [Haskell-cafe] Re: Zippers
On 3/5/09, Ryan Ingram ryani.s...@gmail.com wrote: ... Here is the problem with your update: tree = Fork (Leaf 1) (Leaf 2) ztree = initZ tree test = fromJust $ do z1 - moveLeft ztree let z2 = update z1 3 z3 - moveUp z2 z4 - moveLeft z3 this z4 I'd expect test to equal 3, but I believe with your code that it still equals 1. As apfelmus said, update needs to completely re-construct the zipper structure with the tied knot, which defeats the purpose of using a zipper in the first place. I got it. I dont't know what your expression tied knot is referring to but I got the point. Thanks. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help optimizing memory usage for a program
Don Stewart ha scritto: manlio_perillo: Hi. After some work I have managed to implement two simple programs that parse the Netflix Prize data set. For details about the Netflix Prize, there was a post by Kenneth Hoste some time ago. I have cabalized the program, and made available here: http://haskell.mperillo.ath.cx/netflix-0.0.1.tar.gz [...] Seems like a useful benchmark of a number of things. Any chance you'll upload it to hackage? Not the package as it is now. And I first need to write a program that generates a reasonable data set. But, yes, I will upload it to hackage, if it can be useful. What name should I use? How should I categorize it? Regards Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Zippers
Cristiano Paris wrote: Ryan Ingram wrote: ... Here is the problem with your update: tree = Fork (Leaf 1) (Leaf 2) ztree = initZ tree test = fromJust $ do z1 - moveLeft ztree let z2 = update z1 3 z3 - moveUp z2 z4 - moveLeft z3 this z4 I'd expect test to equal 3, but I believe with your code that it still equals 1. As apfelmus said, update needs to completely re-construct the zipper structure with the tied knot, which defeats the purpose of using a zipper in the first place. I got it. I dont't know what your expression tied knot is referring to but I got the point. In doInitZ , you're basically using the s itself to define the moveLeft and moveRight fields of s . You could as well write it as initZ t = doInitZ Nothing t where doInitZ c (Leaf a) = ZContext c Nothing Nothing $ Just a doInitZ c t@(Fork l r) = s where s = ZContext c (Just $ doInitZ (Just s) l) (Just $ doInitZ (Just s) r) Nothing Such self-reference is usually called tying the knot, see also http://www.haskell.org/haskellwiki/Tying_the_Knot Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monadic MapReduce
Anish Muttreja ha scritto: [...] How about this. Is there a reason why I can't replace the variables b and c in the type signature of mapReduce with with (IO b') and (IO c'). b and c can be any types. mapReduce :: Strategy (IO b')-- evaluation strategy for mapping - (a - IO b') -- map function - Strategy (IO c')-- evaluation strategy for reduction - ([IO b'] - (IO c'))-- reduce function - [a] -- list to map over - (IO c') Just remember to wrap all values back in the IO monad. The other day I found, with google, a definizion of mapReduce, that make use of forkIO to execute piece of IO actions on separate threads. I can't find it anymore... Anish Manlio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Zippers
On Thu, Mar 5, 2009 at 11:21 AM, Heinrich Apfelmus apfel...@quantentunnel.de wrote: ... Such self-reference is usually called tying the knot, see also http://www.haskell.org/haskellwiki/Tying_the_Knot I didn't know. Would you call this Tying the knot as well? http://yi-editor.blogspot.com/2008/12/prototypes-encoding-oo-style.html Thank you. Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] possible memory leak in uvector 0.1.0.3
Bulat Ziganshin ha scritto: Hello Manlio, Tuesday, March 3, 2009, 5:35:33 PM, you wrote: There are 100,000,000 ratings, so I create 100,000,000 arrays containing only one element. every array needs ~30 bytes - it's a minimal memory block ghc can alloc for variable-sized objects. multiple this by 3 to account for copying GC behavior Ok, this explains memory usage; thanks. IMHO, this informations should go in the wiki; they may be insignificant for normal applications, but when one starts to deal with huge amount of data, 10 bytes per item make an important difference. Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On Thursday 05 March 2009 09:45:51 Magicloud Magiclouds wrote: I am confused. Code like this works in other WM, except xmonad. You code does not set _NET_WM_STRUT property. And because of that xmonad doesn't treat it specifically. You can inspect you window properties using `xprop' utility. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
Hi Gwern, I get String/Data.Binary issues too. My suggestion would be to change your strings to ByteString's, serisalise, and then do the reverse conversion when reading. Interestingly, a String and a ByteString have identical Data.Binary reps, but in my experiments converting, including the cost of BS.unpack, makes the reading substantially cheaper. Thanks Neil On Thu, Mar 5, 2009 at 2:33 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen spencerjans...@gmail.com wrote: On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen gwe...@gmail.com wrote: So recently I've been having issues with Data.Binary Data.Sequence; I serialize a 'Seq String' You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs The relevant function seems to be: -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. readDB :: YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (\_ - return empty) where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x -- We read in with strict bytestrings to guarantee the file is closed, -- and then we convert it to the lazy bytestring data.binary expects. -- This is inefficient, but alas... My current serialized file is about 9.4M. I originally thought that the issue might be the recent upgrade in Yi to binary 0.5, but I unpulled patches back to past that, and the problem still manifested. Whenever yi tries to read the articles.db file, it stack overflows. It actually stack-overflowed on even smaller files, but I managed to bump the size upwards, it seems, by the strict-Bytestring trick. Unfortunately, my personal file has since passed whatever that limit was. I've read carefully the previous threads on Data.Binary and Data.Map stack-overflows, but none of them seem to help; hacking some $!s or seqs into readDB seems to make no difference, and Seq is supposed to be a strict datastructure already! Doing things in GHCi has been tedious, and hasn't enlightened me much: sometimes things overflow and sometimes they don't. It's all very frustrating and I'm seriously considering going back to using the original read/show code unless anyone knows how to fix this - that approach may be many times slower, but I know it will work. -- gwern Have you tried the darcs version of binary? It has a new instance which looks more efficient than the old. Cheers, Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern ___ 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: Theory about uncurried functions
Ha. There's even a wiki page on the paradoxes of set theory http://en.wikipedia.org/wiki/Paradoxes_of_set_theory If I recall correctly, a math professor once told me that it is not yet proven if the cardinality of the power set of the natural numbers is larger or smaller or equal than the cardinality of the real numbers... But that is many many years ago so don't shoot me if I'm wrong :) 2009/3/4 Luke Palmer lrpal...@gmail.com On Wed, Mar 4, 2009 at 3:38 PM, Achim Schneider bars...@web.de wrote: There's not much to understand about CT, anyway: It's actually nearly as trivial as set theory. You mean that theory which predicts the existence of infinitely many infinities; in fact for any cardinal, there are at least that many cardinals? That theory in which aleph_1 and 2^aleph_0 are definitely comparable, but we provably cannot compare them? The theory which has omega_0 omega_1 omega_2 ... omega_omega ..., where obviously omega_a is much larger than a... except for when it catches its tail and omega_alpha = alpha for some crazy-ass alpha. I don't think set theory is trivial in the least. I think it is complicated, convoluted, often anti-intuitive and nonconstructive. Category theory is much more trivial, and that's what makes it powerful. (Although training yourself to think categorically is quite difficult, I'm finding) One part of the benefit starts when you begin to categorise different kind of categories, in the same way that understanding monads is easiest if you just consider their difference to applicative functors. It's a system inviting you to tackle a problem with scrutiny, neither tempting you to generalise way beyond computability, nor burdening you with formal proof requirements or shackling you to some other ball and chain. Sadly, almost all texts about CT are absolutely useless: They tend to focus either on pure mathematical abstraction, lacking applicability, or tell you the story for a particular application of CT to a specific topic, loosing themselves in detail without providing the bigger picture. That's why I liked that Rosetta stone paper so much: I still don't understand anything more about physics, but I see how working inside a category with specific features and limitations is the exact right thing to do for those guys, and why you wouldn't want to do a PL that works in the same category. Throwing lambda calculus at a problem that doesn't happen to be a DSL or some other language of some sort is a bad idea. I seem to understand that for some time now, being especially fond of automata[1] to model autonomous, interacting agents, but CT made me grok it. The future will show how far it will pull my thinking out of the Turing tarpit. [1] Which aren't, at all, objects. Finite automata don't go bottom in any case, at least not if you don't happen to shoot them and their health drops below zero. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 13:09 schrieb Peter Verswyvelen: Ha. There's even a wiki page on the paradoxes of set theory http://en.wikipedia.org/wiki/Paradoxes_of_set_theory If I recall correctly, a math professor once told me that it is not yet proven if the cardinality of the power set of the natural numbers is larger or smaller or equal than the cardinality of the real numbers... But that is many many years ago so don't shoot me if I'm wrong :) In standard NBG set theory, it is easy to prove that card(P(N)) == card(R). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Finding the Convex Hull (Problem 12 of Real World Haskell)
I wrote a solution to this problem, but it appears to return incorrect results. There's a pastebin of the code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2121 and a picture of the inputs, outputs, and expected results graphed at http://img510.imageshack.us/img510/9971/resultsg.jpg I'm wondering if this is a flaw in my code, my understanding of the problem, or both. Any ideas on how to track this one down would be very much appreciated. Thank you! -- ヽ(^o^)ノ -rob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
Lennart Augustsson wrote:
I don't see any breaking of referential transparence in your code.
Every time you do an IO operation the result is basically
non-deterministic since you are talking to the outside world.
You're assuming the IO has some kind of semantics that Haskell makes
no promises about.
I'm not saying that this isn't a problem, because it is.
But it doesn't break referential transparency, it just makes the
semantics of IO even more complicated.
(I don't have a formal proof that unsafeInterleaveIO cannot break RT,
but I've not seen an example where it does yet.)
So the argument is something like: we can think of the result of a call to
unsafeInterleaveIO as having been chosen at the time we called
unsafeInterleaveIO, rather than when its result is actually evaluated.
This is on dodgy ground, IMO: either you admit that the IO monad contains
an Oracle, or you admit it can time-travel. I don't believe in either of
those things :-)
Cheers,
Simon
-- Lennart
On Thu, Mar 5, 2009 at 2:12 AM, o...@okmij.org wrote:
We demonstrate how lazy IO breaks referential transparency. A pure
function of the type Int-Int-Int gives different integers depending
on the order of evaluation of its arguments. Our Haskell98 code uses
nothing but the standard input. We conclude that extolling the purity
of Haskell and advertising lazy IO is inconsistent.
Henning Thielemann wrote on Haskell-Cafe:
Say I have a chain of functions: read a file, ... write that to a file,
all of these functions are written in a lazy way, which is currently
considered good style
Lazy IO should not be considered good style. One of the common
definitions of purity is that pure expressions should evaluate to the
same results regardless of evaluation order, or that equals can be
substituted for equals. If an expression of the type Int evaluates to
1, we should be able to replace every occurrence of the expression with
1 without changing the results and other observables.
The expression (read s) where s is the result of the (hGetContents h1)
action has the pure type, e.g., Int. Yet its evaluation does more than
just producing an integer: it may also close a file associated with
the handle h1. Closing the file has an observable effect: the file
descriptor, which is a scarce resource, is freed. Some OS lock the
open file, or prevent operations such as renaming and deletion on the
open file. A file system whose file is open cannot be
unmounted. Suppose I use an Haskell application such as an editor to
process data from a removable drive. I mount the drive, tell the
application the file name. The (still running) application finished
with the file and displayed the result. And yet I can't unplug the
removable drive, because it turns out that the final result was
produced without needing to read all the data from the file, and the
file remains unclosed.
Some people say: the programmer should have used seq. That is the
admission of guilt! An expression (read s)::Int that evaluates to 1 is
equal to 1. So, one should be able substitute (read s) with 1. If the
result of evaluating 1 turns out not needed for the final outcome,
then not evaluating (read s) should not affect the outcome. And yet it
does. One uses seq to force evaluation of an expression even if the
result may be unused. Thus the expression of a pure type
has *side-effect*.
The advice about using seq reminds me of advice given to C programmers
that they should not free a malloc'ed pointer twice, dereference a
zero pointer and write past the boundary of an array. If lazy IO is
considered good style given the proper use of seq, then C should be
considered safe given the proper use of pointers and arrays.
Side affects like closing a file are observable in the external
world. A program may observe these effects, in an IO monad. One can
argue there are no guarantees at all about what happens in the IO
monad. Can side-effects of lazy IO be observable in _pure_ Haskell
code, in functions with pure type? Yes, they can. The examples are
depressingly easy to write, once one realizes that reading does have
side effects, POSIX provides for file descriptor aliasing, and sharing
becomes observable with side effects. Here is a simple Haskell98 code.
{- Haskell98! -}
module Main where
import System.IO
import System.Posix.IO (fdToHandle, stdInput)
-- f1 and f2 are both pure functions, with the pure type.
-- Both compute the result of the subtraction e1 - e2.
-- The only difference between them is the sequence of
-- evaluating their arguments, e1 `seq` e2 vs. e2 `seq` e1
-- For really pure functions, that difference should not be observable
f1, f2:: Int - Int - Int
f1 e1 e2 = e1 `seq` e2 `seq` e1 - e2
f2 e1 e2 = e2 `seq` e1 `seq` e1 - e2
read_int s = read . head . words $ s
main = do
let h1 = stdin
h2 - fdToHandle stdInput
s1 - hGetContents h1
s2 - hGetContents h2
print $ f1 (read_int s1) (read_int s2)
-- print $ f2 (read_int
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On Wed, Mar 04, 2009 at 10:59:53PM -0500, Brandon S. Allbery KF8NH wrote: On 2009 Mar 4, at 21:40, Magicloud Magiclouds wrote: Could someone give me a sample or something I could learn from? Thanks. (xmobar is open source, you could look through its source) xmobar is not open source. xmobar is FREE software! here's the relevant bits (from Xmobar.hs) setProperties :: Rectangle - Config - Display - Window - [Rectangle] - IO () setProperties r c d w srs = do a1 - internAtom d _NET_WM_STRUT_PARTIALFalse c1 - internAtom d CARDINAL False a2 - internAtom d _NET_WM_WINDOW_TYPE False c2 - internAtom d ATOM False v - internAtom d _NET_WM_WINDOW_TYPE_DOCK False changeProperty32 d w a1 c1 propModeReplace $ map fi $ getStrutValues r (position c) (getRootWindowHeight srs) changeProperty32 d w a2 c2 propModeReplace [fromIntegral v] hope this helps. Best, Andrea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding the Convex Hull (Problem 12 of Real World Haskell)
Whenever I'm looking for a bug in Haskell code, I find it helpful to start by seeing if I can simplify the code any first. In this case, there are a couple of things I notice: - validPointsOf is just a filter. It would be easier to write valid :: MyDirection - Bool and then validPointsOf = filter (valid . snd) - Similarly, there's no need to write your own minimum-finder and call it lowestY. Instead, write (or derive!) an Ord instance, and then use the standard prelude function minimum - a small simplification of sortByCoTan: sortByCoTan pivot = sortBy (comparing (coTan pivot)) Hope this helps! 2009/3/5 Rob Crowther weila...@gmail.com I wrote a solution to this problem, but it appears to return incorrect results. There's a pastebin of the code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2121 and a picture of the inputs, outputs, and expected results graphed at http://img510.imageshack.us/img510/9971/resultsg.jpg I'm wondering if this is a flaw in my code, my understanding of the problem, or both. Any ideas on how to track this one down would be very much appreciated. Thank you! -- ヽ(^o^)ノ -rob ___ 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: Theory about uncurried functions
On 5 Mar 2009, at 13:29, Daniel Fischer wrote: In standard NBG set theory, it is easy to prove that card(P(N)) == card(R). No, it is an axiom: Cohen showed in 1963 (mentioned in Mendelson, Introduction to Mathematical Logic) that the continuum hypothesis (CH) is independent of NBG+(AC)+(Axiom of Restriction), where AC is the axiom of choice. Thus you can assume CH or its negation (which is intuitively somewhat strange). AC is independent of NGB, so you can assume it or its negation (also intuitively strange), though GHC (generalized CH, for any cardinality) + NBG implies AC (result by Sierpinski 1947 and Specker 1954). GHC says that for any set x, there are no cardinalities between card x and card 2^x (the power-set cardinality). Since card ω card R by Cantors diagonal method, and card R = card 2^ω since R can be constructed out of binary sequences (and since the interval [0, 1] and R can be shown having the same cardinalities), GHC implies card R = card 2^ω. (Here, ω is a lower case omega, denoting the first infinite ordinal.) Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding the Convex Hull (Problem 12 of Real World Haskell)
Am Donnerstag, 5. März 2009 13:40 schrieb Rob Crowther: I wrote a solution to this problem, but it appears to return incorrect results. There's a pastebin of the code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2121 and a picture of the inputs, outputs, and expected results graphed at http://img510.imageshack.us/img510/9971/resultsg.jpg I'm wondering if this is a flaw in my code, my understanding of the problem, or both. Definitely flawed code, probably based on incorrect understanding of the algorithm. Any ideas on how to track this one down would be very much appreciated. To track it down, it would be helpful to look at the intermediate results and see where they differ in what way from your expectations. *ConvexHull let pointlist :: [Point2D]; pointlist = [(0,0), (2,0), (4,0), (6,0), (5,-2), (5,2), (0,4), (6,4), (5,6)] *ConvexHull lowestY pointlist (5.0,-2.0) *ConvexHull sortByCoTan it pointlist [(0.0,0.0),(2.0,0.0),(0.0,4.0),(4.0,0.0),(5.0,2.0),(5.0,6.0),(6.0,4.0),(5.0,-2.0),(6.0,0.0)] *ConvexHull let sortedpoints = it *ConvexHull listOfTurns sortedpoints [MyRight,MyLeft,MyRight,MyRight,MyLeft,MyLeft,MyRight] *ConvexHull zip sortedpoints (MyStraight:MyStraight:it) [((0.0,0.0),MyStraight),((2.0,0.0),MyStraight),((0.0,4.0),MyRight),((4.0,0.0),MyLeft),((5.0,2.0),MyRight),((5.0,6.0),MyRight),((6.0,4.0),MyLeft),((5.0,-2.0),MyLeft),((6.0,0.0),MyRight)] *ConvexHull validPointsOf it Thank you! *ConvexHull let ly = lowestY pointlist *ConvexHull coTan ly ly NaN First, you'd want to separate the point with lowest y-coordinate from the rest, like lowestY :: [Point2D] - (Point2D,[Point2D]) lowestY (x:xs) = foldr update (x,[]) xs where update a (b,cs) = -- left as an exercise Then it might be a good idea to make sortByCoTan insensitive to other points with the same lowest y-coordinate, and of course, sort only the points other than the starting point. Also, the way the points are sorted, you'll walk clockwise around the boundary, so you'd never turn left, only proceed straight or turn right. But the turn at each point does not depend on its neighbours in the list sorted by cotangent, but on which points have so far been chosen, so you have to compute the turn based on that. The selection of points is considerably more complicated than just looking at the turn, consider e.g. [(0,0), (-2,2), (-2,3),(-1,3),(0,4),(1,4),(2,6),(3,9)]. When you have three points a, b and c, and you go from a via b to c, the turn at b is right, iff crossProduct a b c 0 left, iff crossProduct a b c 0. HTH, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 14:58 schrieb Hans Aberg: On 5 Mar 2009, at 13:29, Daniel Fischer wrote: In standard NBG set theory, it is easy to prove that card(P(N)) == card(R). No, it is an axiom: Cohen showed in 1963 (mentioned in Mendelson, Introduction to Mathematical Logic) that the continuum hypothesis (CH) is independent of NBG+(AC)+(Axiom of Restriction), where AC is the axiom of choice. Yes, but the continuum hypothesis is 2^Aleph_0 == Aleph_1, which is quite something different from 2^Aleph_0 == card(R). You can show the latter easily with the Cantor-Bernstein theorem, independent of CH or AC. Thus you can assume CH or its negation (which is intuitively somewhat strange). AC is independent of NGB, so you can assume it or its negation (also intuitively strange), though GHC (generalized CH, for any cardinality) + NBG implies AC (result by Sierpinski 1947 and Specker 1954). GHC says that for any set x, there are no cardinalities between card x and card 2^x (the power-set cardinality). Since card ω card R by Cantors diagonal method, and card R = card 2^ω since R can be constructed out of binary sequences (and since the interval [0, 1] and R can be shown having the same cardinalities), GHC implies card R = card 2^ω. (Here, ω is a lower case omega, denoting the first infinite ordinal.) Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
2009/3/5 Hans Aberg hab...@math.su.se: GHC says that for any set x, there are no cardinalities between card x and No it doesn't. It says there is a syntax error in my code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 15:12 schrieb Daniel Fischer:
Yes, but the continuum hypothesis is 2^Aleph_0 == Aleph_1, which is quite
something different from 2^Aleph_0 == card(R).
You can show the latter easily with the Cantor-Bernstein theorem,
independent of CH or AC.
Just to flesh this up a bit:
let f : P(N) - R be given by f(M) = sum [2*3^(-k) | k - M ]
f is easily seen to be injective.
define g : (0,1) - P(N) by
let x = sum [a_k*2^(-k) | k in N (\{0}), a_k in {0,1}, infinitely many a_k =
1]
and then g(x) = {k | a_k = 1}
again clearly g is an injection.
Now the Cantor-Bernstein theorem asserts there is a bijection between the two
sets.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
On 5 Mar 2009, at 15:12, Daniel Fischer wrote: No, it is an axiom: Cohen showed in 1963 (mentioned in Mendelson, Introduction to Mathematical Logic) that the continuum hypothesis (CH) is independent of NBG+(AC)+(Axiom of Restriction), where AC is the axiom of choice. Yes, but the continuum hypothesis is 2^Aleph_0 == Aleph_1, which is quite something different from 2^Aleph_0 == card(R). Yes, right, card R = 2^Aleph_0, as you said, and Aleph_1 is defined as the smallest cardinal greater than Aleph_0. Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] missing support to Data.Binary for uvector package
Hi. I'm still having problems with the uvector package. I have an IntMap (UArr xxx) data type, and I want to serialize it to disk, in binary format. I'm using the uvector package from http://patch-tag.com/repo/pumpkin-uvector/home The problem is with missing instance declarations, for Hyperstrict data type and Data.Array.Vector.UArr.UPrim. For the former, the instance is simple, but for the latter I have no idea about what to do. The full error message (GHC 6.8.2): No instance for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) arising from a use of `encode' at bin/process-data-1.hs:72:18-36 Possible fix: add an instance declaration for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
You're assuming that IO operations have semantics. From the Haskell program's point of view, and when reasoning about Haskell programs (not their interaction with the world) you should assume that every IO operation returns a random result. The way Oleg's program behaves does not break RT under the random result assumption. What could break RT is if you could do this f :: Int - Int - someIOoperation let x = f 0; y = f 0 and end up with x and y not being equal. It's (of course) easy to construct someIOoperation that has this behaviour (using FFI), but I don't think you can construct it just using the normal IO operations and unsafeInterleaveIO. But as I said, I think this is a problem anyway, because IO without semantics is rather useless. -- Lennart On Thu, Mar 5, 2009 at 1:08 PM, Simon Marlow marlo...@gmail.com wrote: Lennart Augustsson wrote: I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) Cheers, Simon -- Lennart On Thu, Mar 5, 2009 at 2:12 AM, o...@okmij.org wrote: We demonstrate how lazy IO breaks referential transparency. A pure function of the type Int-Int-Int gives different integers depending on the order of evaluation of its arguments. Our Haskell98 code uses nothing but the standard input. We conclude that extolling the purity of Haskell and advertising lazy IO is inconsistent. Henning Thielemann wrote on Haskell-Cafe: Say I have a chain of functions: read a file, ... write that to a file, all of these functions are written in a lazy way, which is currently considered good style Lazy IO should not be considered good style. One of the common definitions of purity is that pure expressions should evaluate to the same results regardless of evaluation order, or that equals can be substituted for equals. If an expression of the type Int evaluates to 1, we should be able to replace every occurrence of the expression with 1 without changing the results and other observables. The expression (read s) where s is the result of the (hGetContents h1) action has the pure type, e.g., Int. Yet its evaluation does more than just producing an integer: it may also close a file associated with the handle h1. Closing the file has an observable effect: the file descriptor, which is a scarce resource, is freed. Some OS lock the open file, or prevent operations such as renaming and deletion on the open file. A file system whose file is open cannot be unmounted. Suppose I use an Haskell application such as an editor to process data from a removable drive. I mount the drive, tell the application the file name. The (still running) application finished with the file and displayed the result. And yet I can't unplug the removable drive, because it turns out that the final result was produced without needing to read all the data from the file, and the file remains unclosed. Some people say: the programmer should have used seq. That is the admission of guilt! An expression (read s)::Int that evaluates to 1 is equal to 1. So, one should be able substitute (read s) with 1. If the result of evaluating 1 turns out not needed for the final outcome, then not evaluating (read s) should not affect the outcome. And yet it does. One uses seq to force evaluation of an expression even if the result may be unused. Thus the expression of a pure type has *side-effect*. The advice about using seq reminds me of advice given to C programmers that they should not free a malloc'ed pointer twice, dereference a zero pointer and write past the boundary of an array. If lazy IO is considered good style given the proper use of seq, then C should be considered safe given the proper use of pointers and arrays. Side affects like closing a file are observable in the external world. A program may observe these effects, in an IO monad. One can argue there are no guarantees at all about what happens in the IO monad. Can side-effects of lazy IO be observable in _pure_ Haskell code, in functions with pure type? Yes, they can. The examples are depressingly easy to write, once one realizes
Re: [Haskell-cafe] Re: Theory about uncurried functions
On 5 Mar 2009, at 15:23, Daniel Fischer wrote:
Just to flesh this up a bit:
let f : P(N) - R be given by f(M) = sum [2*3^(-k) | k - M ]
f is easily seen to be injective.
define g : (0,1) - P(N) by
let x = sum [a_k*2^(-k) | k in N (\{0}), a_k in {0,1}, infinitely
many a_k =
1]
and then g(x) = {k | a_k = 1}
again clearly g is an injection.
Now the Cantor-Bernstein theorem asserts there is a bijection
between the two
sets.
I think one just defines an equivalence relation of elements mapped to
each other by a finite number of iterations of f o g and g o f. The
equivalence classes are then at most countable. So one can set up a
bijection on each equivalence class: easy for at most countable sets.
Then paste it together. The axiom of choice probably implicit here.
Hans Aberg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
On Thu, 2009-03-05 at 13:08 +, Simon Marlow wrote: Lennart Augustsson wrote: I don't see any breaking of referential transparence in your code. Every time you do an IO operation the result is basically non-deterministic since you are talking to the outside world. You're assuming the IO has some kind of semantics that Haskell makes no promises about. I'm not saying that this isn't a problem, because it is. But it doesn't break referential transparency, it just makes the semantics of IO even more complicated. (I don't have a formal proof that unsafeInterleaveIO cannot break RT, but I've not seen an example where it does yet.) So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) That's the charm of denotational semantics --- you're outside the laws of physics. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
Am Donnerstag, 5. März 2009 16:55 schrieb Hans Aberg:
On 5 Mar 2009, at 15:23, Daniel Fischer wrote:
Just to flesh this up a bit:
let f : P(N) - R be given by f(M) = sum [2*3^(-k) | k - M ]
f is easily seen to be injective.
define g : (0,1) - P(N) by
let x = sum [a_k*2^(-k) | k in N (\{0}), a_k in {0,1}, infinitely
many a_k =
1]
and then g(x) = {k | a_k = 1}
again clearly g is an injection.
Now the Cantor-Bernstein theorem asserts there is a bijection
between the two
sets.
I think one just defines an equivalence relation of elements mapped to
each other by a finite number of iterations of f o g and g o f. The
equivalence classes are then at most countable. So one can set up a
bijection on each equivalence class: easy for at most countable sets.
Then paste it together. The axiom of choice probably implicit here.
Cantor-Bernstein doesn't require choice (may be different for intuitionists).
http://en.wikipedia.org/wiki/Cantor-Bernstein_theorem
Hans Aberg
Cheers,
Daniel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
On Thu, Mar 5, 2009 at 2:08 PM, Simon Marlow marlo...@gmail.com wrote: So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) As it turns out, time-travel as a vehicle for computation has a long tradition in the more advanced systems; see http://www.frc.ri.cmu.edu/~hpm/project.archive/general.articles/1991/TempComp.html for an example. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Theory about uncurried functions
On 5 Mar 2009, at 17:06, Daniel Fischer wrote: Cantor-Bernstein doesn't require choice (may be different for intuitionists). http://en.wikipedia.org/wiki/Cantor-Bernstein_theorem Yes, that is right, Mendelson says that. - I find it hard to figure out when it is used, as it is so intuitive. Mendelson says AC is in fact equivalent proving all x, y: card x = card y or card y = card x Hans Aberg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] missing support to Data.Binary for uvector package
Hi Manlio, I'm not sure the whole list wants to hear about bugs in my modifications to an alpha library! :-) But basically, I haven't added a Binary instance for productions like that yet. This isn't trivial, but shouldn't be hard. Otherwise, using the unsafe serialization functions I provide in that same module might give you better luck (at the cost of some safety). But uvector, no matter how awesome the fusion work Don and others did on it, is definitely not finished yet. Be prepared to hack a lot (and maybe crash a fair amount) if you want to use it. Hope this helps, Dan On Thu, Mar 5, 2009 at 9:54 AM, Manlio Perillo manlio_peri...@libero.it wrote: Hi. I'm still having problems with the uvector package. I have an IntMap (UArr xxx) data type, and I want to serialize it to disk, in binary format. I'm using the uvector package from http://patch-tag.com/repo/pumpkin-uvector/home The problem is with missing instance declarations, for Hyperstrict data type and Data.Array.Vector.UArr.UPrim. For the former, the instance is simple, but for the latter I have no idea about what to do. The full error message (GHC 6.8.2): No instance for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) arising from a use of `encode' at bin/process-data-1.hs:72:18-36 Possible fix: add an instance declaration for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) Thanks Manlio Perillo ___ 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: [Haskell] Lazy IO breaks purity
On Thu, Mar 5, 2009 at 7:08 AM, Simon Marlow marlo...@gmail.com wrote: So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) Surely there's a quantum mechanical metaphor waiting to happen here. getCat :: IO Cat If getCat appears in a program text, does it denote or not? Or both? If it does, is the cat alive or dead? (Apologies to Schrodingerhttp://en.wikipedia.org/wiki/Schr%C3%B6dinger%27s_cat). -gregg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On 2009 Mar 5, at 8:21, Andrea Rossato wrote: On Wed, Mar 04, 2009 at 10:59:53PM -0500, Brandon S. Allbery KF8NH wrote: On 2009 Mar 4, at 21:40, Magicloud Magiclouds wrote: Could someone give me a sample or something I could learn from? Thanks. (xmobar is open source, you could look through its source) xmobar is not open source. xmobar is FREE software! I don't do fundamentalist religion... -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: MPI
On Wed, Mar 4, 2009 at 5:03 PM, FFT fft1...@gmail.com wrote: Are MPI bindings still the best way of using Haskell on Beowulf clusters? It's my feeling that the bindings stagnated, or are they just very mature? What's the story with distributed memory multiprocessing? Are Haskell programmers uninterested in it, or are things other than MPI used with it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monadic MapReduce
On Tue, Mar 03, 2009 at 07:27:35AM -1000, Tim Newsham wrote: How about this. Is there a reason why I can't replace the variables b and c in the type signature of mapReduce with with (IO b') and (IO c'). b and c can be any types. mapReduce :: Strategy (IO b')-- evaluation strategy for mapping - (a - IO b') -- map function - Strategy (IO c')-- evaluation strategy for reduction - ([IO b'] - (IO c'))-- reduce function - [a] -- list to map over - (IO c') Just remember to wrap all values back in the IO monad. Remember, the idea of map-reduce is to provide a very restrictive programming interface so that you have a lot of flexibility in your execution strategy. If you start loosening the interface you will still be able to execute the program, but you may not be able to perform all the great optimizations you want to perform. For example, if you are using IO actions that are stateful, what are the semantics? Can one map action affect other map actions? Does this imply an ordering of the map functions? Does this imply they all run on the same machine or at least have state communicated between the machines on which they run? Yes, IO actions in mapReduce will introduce all these questions. I thought Manlio's example was a case where the IO actions consist only of reading an entire file into a string and no ordering or dependence between map actions is implied. I have a similar application where this, unsafe as it is, might be useful. I need to read in a large number of CSV files, with numeric columns, and group columns with high correlation together. I have yet to try my own suggestion though. I have tried the first approach I suggested, read in the contents into strings and work with the normal map-reduce. That does keep the handles open till map-reduce is done. The austere interface precludes any of these issues, and therein lies the beauty. Anish Btw. I prefer the sawzall formulation over the map-reduce formulation. A sawzall program just specifies how to map some data to a monoid and the system is free to mappend the monoid values in whatever order it wants (by applying associativity). Thanks for the tip, I wasn't aware of this. At least in the map-reduce formulation in this thread, the fold is completely specified by the user and not optimized further. So the sawazall formulation seems promising, because sometimes the fold action is more expensive than the map action. And while we are talking about different formulations, the code here http://article.gmane.org/gmane.comp.lang.haskell.cafe/41944 splits the list of operands into chunks and does the fold action in parallel on each chunk. This actually works well for me, though I find the semantics a little hard to remember. Anish Tim Newsham http://www.thenewsh.com/~newsham/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hint and Ambiguous Type issue
I've been working on a little project, and one of the things I need to
do is dynamically compile and import a Haskell Source file containing
filtering definitions. I've written a small monad called Filter which is
simply:
type Filter a = Reader (Config, Email) a
To encompass all the email filtering. The method I need to import,
filterMain, has type:
filterMain :: Deliverable a = Filter a
where Deliverable is a type class which abstracts over delivery to a
path in the file system. The notion is that I can write a type like:
data DEmail = {email :: Email, path :: FilePath}
newtype Maildir = MD DEmail
instance Deliverable Maildir where
{- ... omitted -}
However, Filter a should not be restricted to Deliverable types- it also
encompasses the results of regular expression matching, etc, which are
not -- in general -- Deliverable instances.
My question is this, when importing the file containing the definitions
of filterMain, I have the following code to grab filterMain and return
it as a function.
getFilterMain :: Deliverable a = FilePath - Interpreter (Filter
a)
getFilterMain fMainLoc =
do
loadModules [fMainLoc]; setTopLevelModules [(takeWhile
(/='.') fMainLoc)]
fMain - (interpret (filterMain) (as :: Deliverable a =
Filter a))
return
(fMain)
However, when I try to compile this, I get the type error:
Hackmain.hs:70:43:
Ambiguous type variable `a' in the constraint:
`Deliverable a'
arising from a use of `getFilterMainStuff' at
Hackmain.hs:70:43-60
Probable fix: add a type signature that fixes these type variable(s)
My understanding is that a type like Foo a = Bar a (where Foo is a
class and Bar is a datatype) would simply restrict
the values of a to only those implementing Foo. But evidently I'm wrong.
Is there a good (read, easy... :) ) fix to this?
Any help would be greatly appreciated.
/Joe
PS. All the actual code is on patch-tag, here
http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that
directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs,
and Deliverable.hs
begin:vcard
fn:Joseph Fredette
n:Fredette;Joseph
adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America
email;internet:jfred...@gmail.com
tel;home:1-508-966-9889
tel;cell:1-508-254-9901
x-mozilla-html:FALSE
url:lowlymath.net, humbuggery.net
version:2.1
end:vcard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Test if a file is empty or stat in haskell
I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Am Donnerstag, 5. März 2009 19:48 schrieb Joseph Fredette:
getFilterMain :: Deliverable a = FilePath - Interpreter (Filter
a)
getFilterMain fMainLoc =
do
loadModules [fMainLoc]; setTopLevelModules [(takeWhile
(/='.') fMainLoc)]
fMain - (interpret (filterMain) (as :: Deliverable a =
Filter a))
Without looking at more code, the type variable a here is a fresh type
variable, not the one from getFilterMain's signature.
return
(fMain)
Maybe bringing the type variable a into scope in the function body by
{-# LANGUAGE ScopedTypeVariables #-}
getFilterMain :: forall a. Deliverable a = FilePath - Interpreter (Filter,
a)
would suffice.
However, when I try to compile this, I get the type error:
Hackmain.hs:70:43:
Ambiguous type variable `a' in the constraint:
`Deliverable a'
arising from a use of `getFilterMainStuff' at
Hackmain.hs:70:43-60
Probable fix: add a type signature that fixes these type
variable(s)
My understanding is that a type like Foo a = Bar a (where Foo is a
class and Bar is a datatype) would simply restrict
the values of a to only those implementing Foo. But evidently I'm wrong.
Is there a good (read, easy... :) ) fix to this?
Any help would be greatly appreciated.
/Joe
PS. All the actual code is on patch-tag, here
http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at
that directly, the relevant files are in Src, namely, Hackmain.hs,
Filter.hs, and Deliverable.hs
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
Am Donnerstag, 5. März 2009 19:56 schrieb Anish Muttreja: I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? If you're on a *nixy OS, System.Posix.Files getFileStatus, fileSize ... dunno if Windows has similar functionality. A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
On Thu, 05 Mar 2009 19:56:42 +0100, Anish Muttreja anishmuttr...@gmail.com wrote: I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish Searching for size with Hoogle lead me to System.IO.hFileSize: hFileSize :: Handle - IO Integer For a handle hdl which attached to a physical file, hFileSize hdl returns the size of that file in 8-bit bytes. -- Regards, Henk-Jan van Tuyl -- http://functor.bamikanarie.com http://Van.Tuyl.eu/ -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
On Thu, Mar 05, 2009 at 08:15:03PM +0100, Daniel Fischer wrote: Am Donnerstag, 5. März 2009 19:56 schrieb Anish Muttreja: I am looking for a way to test if a file is empty. Something like isFileEmpty along the lines of System.Directory.doesFileExist? If you're on a *nixy OS, System.Posix.Files getFileStatus, fileSize ... Great, thanks. dunno if Windows has similar functionality. I am on Linux. BTW, Hoogle does not seem to know about System.Posix.Files, though it did point me to System.IO.FileSize which would also have served the purpose. http://www.haskell.org/hoogle/?hoogle=fileSize Thanks, Anish A function that wraps stat would also serve the purpose. I get the feeling that someone must have felt the need for this before me, but Google search not yield anything, hence the question. Thanks! Anish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
Avoid unpack! ndmitchell: Hi Gwern, I get String/Data.Binary issues too. My suggestion would be to change your strings to ByteString's, serisalise, and then do the reverse conversion when reading. Interestingly, a String and a ByteString have identical Data.Binary reps, but in my experiments converting, including the cost of BS.unpack, makes the reading substantially cheaper. Thanks Neil On Thu, Mar 5, 2009 at 2:33 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen spencerjans...@gmail.com wrote: On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen gwe...@gmail.com wrote: So recently I've been having issues with Data.Binary Data.Sequence; I serialize a 'Seq String' You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs The relevant function seems to be: -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. readDB :: YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (\_ - return empty) where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x -- We read in with strict bytestrings to guarantee the file is closed, -- and then we convert it to the lazy bytestring data.binary expects. -- This is inefficient, but alas... My current serialized file is about 9.4M. I originally thought that the issue might be the recent upgrade in Yi to binary 0.5, but I unpulled patches back to past that, and the problem still manifested. Whenever yi tries to read the articles.db file, it stack overflows. It actually stack-overflowed on even smaller files, but I managed to bump the size upwards, it seems, by the strict-Bytestring trick. Unfortunately, my personal file has since passed whatever that limit was. I've read carefully the previous threads on Data.Binary and Data.Map stack-overflows, but none of them seem to help; hacking some $!s or seqs into readDB seems to make no difference, and Seq is supposed to be a strict datastructure already! Doing things in GHCi has been tedious, and hasn't enlightened me much: sometimes things overflow and sometimes they don't. It's all very frustrating and I'm seriously considering going back to using the original read/show code unless anyone knows how to fix this - that approach may be many times slower, but I know it will work. -- gwern Have you tried the darcs version of binary? It has a new instance which looks more efficient than the old. Cheers, Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] missing support to Data.Binary for uvector package
manlio_perillo: Hi. I'm still having problems with the uvector package. I have an IntMap (UArr xxx) data type, and I want to serialize it to disk, in binary format. I'm using the uvector package from http://patch-tag.com/repo/pumpkin-uvector/home The problem is with missing instance declarations, for Hyperstrict data type and Data.Array.Vector.UArr.UPrim. For the former, the instance is simple, but for the latter I have no idea about what to do. The full error message (GHC 6.8.2): No instance for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) arising from a use of `encode' at bin/process-data-1.hs:72:18-36 Possible fix: add an instance declaration for (uvector-0.2:Data.Array.Vector.UArr.UPrim (Word32 uvector-0.2:Data.Array.Vector.Prim.Hyperstrict.:*: Word8)) uvector is alpha/experimental. You should expect to write instances/patches if you chose to use it! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make a dock window for xmonad using gtk2hs?
On Thu, Mar 05, 2009 at 12:50:20PM -0500, Brandon S. Allbery KF8NH wrote: On 2009 Mar 5, at 8:21, Andrea Rossato wrote: xmobar is not open source. xmobar is FREE software! I don't do fundamentalist religion... qualifying as fundamentalism the avoidance of cheap marketing strategies is just a ... cheap marketing strategy. cheers, andrea ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary stack overflow with Data.Sequence String
Avoid massive reductions in runtime while maintaining the same API? I did move to using ByteString's internally for those bits later on, but reading String's from Data.Binary with a ByteString+unpack went much more quickly than reading String's On Thu, Mar 5, 2009 at 7:35 PM, Don Stewart d...@galois.com wrote: Avoid unpack! ndmitchell: Hi Gwern, I get String/Data.Binary issues too. My suggestion would be to change your strings to ByteString's, serisalise, and then do the reverse conversion when reading. Interestingly, a String and a ByteString have identical Data.Binary reps, but in my experiments converting, including the cost of BS.unpack, makes the reading substantially cheaper. Thanks Neil On Thu, Mar 5, 2009 at 2:33 AM, Gwern Branwen gwe...@gmail.com wrote: On Tue, Mar 3, 2009 at 11:50 PM, Spencer Janssen spencerjans...@gmail.com wrote: On Tue, Mar 3, 2009 at 10:30 PM, Gwern Branwen gwe...@gmail.com wrote: So recently I've been having issues with Data.Binary Data.Sequence; I serialize a 'Seq String' You can see the file here: http://code.haskell.org/yi/Yi/IReader.hs The relevant function seems to be: -- | Read in database from 'dbLocation' and then parse it into an 'ArticleDB'. readDB :: YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (\_ - return empty) where r x = fmap (decode . BL.fromChunks . return) $ B.readFile x -- We read in with strict bytestrings to guarantee the file is closed, -- and then we convert it to the lazy bytestring data.binary expects. -- This is inefficient, but alas... My current serialized file is about 9.4M. I originally thought that the issue might be the recent upgrade in Yi to binary 0.5, but I unpulled patches back to past that, and the problem still manifested. Whenever yi tries to read the articles.db file, it stack overflows. It actually stack-overflowed on even smaller files, but I managed to bump the size upwards, it seems, by the strict-Bytestring trick. Unfortunately, my personal file has since passed whatever that limit was. I've read carefully the previous threads on Data.Binary and Data.Map stack-overflows, but none of them seem to help; hacking some $!s or seqs into readDB seems to make no difference, and Seq is supposed to be a strict datastructure already! Doing things in GHCi has been tedious, and hasn't enlightened me much: sometimes things overflow and sometimes they don't. It's all very frustrating and I'm seriously considering going back to using the original read/show code unless anyone knows how to fix this - that approach may be many times slower, but I know it will work. -- gwern Have you tried the darcs version of binary? It has a new instance which looks more efficient than the old. Cheers, Spencer Janssen I have. It still stack-overflows on my 9.8 meg file. (The magic number seems to be somewhere between 9 and 10 megabytes.) -- gwern ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
Hi I am on Linux. BTW, Hoogle does not seem to know about System.Posix.Files, though it did point me to System.IO.FileSize which would also have served the purpose. To build the Hoogle libraries I need to build the packages. I run Windows not Linux, so its a bit difficult to index System.Posix - but I am trying to shortly. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
This doesn't seem to do it, same type error... Maybe I need to use some
kind of witness type -- to inform the compiler
of the type of a @ runtime?
Daniel Fischer wrote:
Am Donnerstag, 5. März 2009 19:48 schrieb Joseph Fredette:
getFilterMain :: Deliverable a = FilePath - Interpreter (Filter
a)
getFilterMain fMainLoc =
do
loadModules [fMainLoc]; setTopLevelModules [(takeWhile
(/='.') fMainLoc)]
fMain - (interpret (filterMain) (as :: Deliverable a =
Filter a))
Without looking at more code, the type variable a here is a fresh type
variable, not the one from getFilterMain's signature.
return
(fMain)
Maybe bringing the type variable a into scope in the function body by
{-# LANGUAGE ScopedTypeVariables #-}
getFilterMain :: forall a. Deliverable a = FilePath - Interpreter (Filter,
a)
would suffice.
However, when I try to compile this, I get the type error:
Hackmain.hs:70:43:
Ambiguous type variable `a' in the constraint:
`Deliverable a'
arising from a use of `getFilterMainStuff' at
Hackmain.hs:70:43-60
Probable fix: add a type signature that fixes these type
variable(s)
My understanding is that a type like Foo a = Bar a (where Foo is a
class and Bar is a datatype) would simply restrict
the values of a to only those implementing Foo. But evidently I'm wrong.
Is there a good (read, easy... :) ) fix to this?
Any help would be greatly appreciated.
/Joe
PS. All the actual code is on patch-tag, here
http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at
that directly, the relevant files are in Src, namely, Hackmain.hs,
Filter.hs, and Deliverable.hs
begin:vcard
fn:Joseph Fredette
n:Fredette;Joseph
adr:Apartment #3;;6 Dean Street;Worcester;Massachusetts;01609;United States of America
email;internet:jfred...@gmail.com
tel;home:1-508-966-9889
tel;cell:1-508-254-9901
x-mozilla-html:FALSE
url:lowlymath.net, humbuggery.net
version:2.1
end:vcard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Test if a file is empty or stat in haskell
getFileStatus, fileSize ... Great, thanks. BTW, Hoogle does not seem to know about System.Posix.Files, though it did point me to System.IO.FileSize which would also have served the purpose. Yep, this was discussed in a Hoogle and Network.Socket thread I started last week. There is a wiki for summarizing thoughts [1]. Some time this weekend or next week I intend to submit a Hoogle ticket proposing what I see as an agreeable outcome. At that point I hope Neil will accept and maybe even find time to write code. The final step would involve me buying Neil a beer - I've lots of beer-debt to the Haskell community. [1] http://haskell.org/haskellwiki/Hoogle/Packages ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
So, by using the Haskell interpreter, you're using the
not-very-well-supported dynamically-typed subset of Haskell. You can
tell this from the type signature of interpret:
interpret :: Typeable a = String - a - Interpreter a
as :: Typeable a = a
as = undefined
(from
http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html)
In particular, the as argument to interpret is specifying what type
you want the interpreted result to be typechecked against; the
interpretation fails if it doesn't match that type. But you need the
result type to be an instance of Typeable; (forall a. Deliverable a =
Filter a) most certainly is not.
Off the top of my head, you have a couple of directions you can take this.
(1) Make Typeable a superclass of Deliverable, saying that all
deliverable things must be dynamically typeable. Then derive Typeable
on Filter, and have the result be of type Filter a using
ScopedTypeVariables as suggested before. (You can also pass infer to
the interpreter and let the compiler try to figure out the result type
instead of passing (as :: SomeType).)
(2) Make a newtype wrapper around Filter and give it an instance of
Typeable, and add a constraint to filterMain that the result type in
the filter is also typeable. Then unwrap the newtype after the
interpreter completes.
Good luck; I've never tried to use the Haskell interpreter before, so
I'm curious how well it works and what problems you have with it!
-- ryan
2009/3/5 Joseph Fredette jfred...@gmail.com:
I've been working on a little project, and one of the things I need to do is
dynamically compile and import a Haskell Source file containing filtering
definitions. I've written a small monad called Filter which is simply:
type Filter a = Reader (Config, Email) a
To encompass all the email filtering. The method I need to import,
filterMain, has type:
filterMain :: Deliverable a = Filter a
where Deliverable is a type class which abstracts over delivery to a path in
the file system. The notion is that I can write a type like:
data DEmail = {email :: Email, path :: FilePath}
newtype Maildir = MD DEmail
instance Deliverable Maildir where
{- ... omitted -}
However, Filter a should not be restricted to Deliverable types- it also
encompasses the results of regular expression matching, etc, which are not
-- in general -- Deliverable instances.
My question is this, when importing the file containing the definitions of
filterMain, I have the following code to grab filterMain and return it as a
function.
getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a)
getFilterMain fMainLoc = do
loadModules
[fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)]
fMain - (interpret (filterMain) (as :: Deliverable a
= Filter a)) return (fMain)
However, when I try to compile
this, I get the type error:
Hackmain.hs:70:43:
Ambiguous type variable `a' in the constraint:
`Deliverable a'
arising from a use of `getFilterMainStuff' at Hackmain.hs:70:43-60
Probable fix: add a type signature that fixes these type variable(s)
My understanding is that a type like Foo a = Bar a (where Foo is a class
and Bar is a datatype) would simply restrict
the values of a to only those implementing Foo. But evidently I'm wrong. Is
there a good (read, easy... :) ) fix to this?
Any help would be greatly appreciated.
/Joe
PS. All the actual code is on patch-tag, here
http://patch-tag.com/repo/Hackmail/home -- if anyone prefers to look at that
directly, the relevant files are in Src, namely, Hackmain.hs, Filter.hs, and
Deliverable.hs
___
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: Theory about uncurried functions
Luke Palmer lrpal...@gmail.com wrote: I don't think set theory is trivial in the least. I think it is complicated, convoluted, often anti-intuitive and nonconstructive. Waaagh! I mean trivial in the mathematical sense, as in how far away from the axioms you are. The other kind of triviality of set theory just proves the point I made about CT vs. lambda calculus. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Theory about uncurried functions
To wrap up: While formalising, there is always a tradeoff between complexity of the theory you're using and the complexity of it being applied to some specific topic. Category theory hits a very, very sweet spot there. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
So, I tried both of those things, both each alone and together. No dice.
Same error, so I reverted back to the
original. :(
However, I was, after some random type signature insertions, able to
convert the problem into a different one, via:
getFilterMain :: Deliverable a = FilePath - Interpreter (Filter
a)
getFilterMain MainLoc = do
loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.')
fMainLoc)]
fMain - (interpret (filterMain) infer)
return (fMain :: Deliverable a = Filter a)
Inferred type is less polymorphic than expected
Quantified type variable `a' is mentioned in the environment:
fMain :: Filter a (bound at Hackmain.hs:77:1)
In the first argument of `return', namely
`(fMain :: (Deliverable a) = Filter a)'
In the expression: return (fMain :: (Deliverable a) = Filter a)
In the expression:
do loadModules [fMainLoc]
setTopLevelModules [(takeWhile (/= '.') fMainLoc)]
fMain - (interpret (filterMain) infer)
return (fMain :: (Deliverable a) = Filter a)
I'm thinking that this might be more easily solved -- I do think I
understand the issue. somehow, I need to tell the compiler
that the 'a' used in the return statement (return (fMain :: ...)) is the
same as the 'a' in the type sig for the whole function.
While I ponder this, and hopefully receive some more help -- thanks
again Dan, Ryan -- Are there any other options besides Hint that might
-- at least in the short term -- make this easier? I'd really like to
finish this up. I'm _so_ close to getting it done.
Thanks,
/Joe
Ryan Ingram wrote:
So, by using the Haskell interpreter, you're using the
not-very-well-supported dynamically-typed subset of Haskell. You can
tell this from the type signature of interpret:
interpret :: Typeable a = String - a - Interpreter a
as :: Typeable a = a
as = undefined
(from
http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html)
In particular, the as argument to interpret is specifying what type
you want the interpreted result to be typechecked against; the
interpretation fails if it doesn't match that type. But you need the
result type to be an instance of Typeable; (forall a. Deliverable a =
Filter a) most certainly is not.
Off the top of my head, you have a couple of directions you can take this.
(1) Make Typeable a superclass of Deliverable, saying that all
deliverable things must be dynamically typeable. Then derive Typeable
on Filter, and have the result be of type Filter a using
ScopedTypeVariables as suggested before. (You can also pass infer to
the interpreter and let the compiler try to figure out the result type
instead of passing (as :: SomeType).)
(2) Make a newtype wrapper around Filter and give it an instance of
Typeable, and add a constraint to filterMain that the result type in
the filter is also typeable. Then unwrap the newtype after the
interpreter completes.
Good luck; I've never tried to use the Haskell interpreter before, so
I'm curious how well it works and what problems you have with it!
-- ryan
2009/3/5 Joseph Fredette jfred...@gmail.com:
I've been working on a little project, and one of the things I need to do is
dynamically compile and import a Haskell Source file containing filtering
definitions. I've written a small monad called Filter which is simply:
type Filter a = Reader (Config, Email) a
To encompass all the email filtering. The method I need to import,
filterMain, has type:
filterMain :: Deliverable a = Filter a
where Deliverable is a type class which abstracts over delivery to a path in
the file system. The notion is that I can write a type like:
data DEmail = {email :: Email, path :: FilePath}
newtype Maildir = MD DEmail
instance Deliverable Maildir where
{- ... omitted -}
However, Filter a should not be restricted to Deliverable types- it also
encompasses the results of regular expression matching, etc, which are not
-- in general -- Deliverable instances.
My question is this, when importing the file containing the definitions of
filterMain, I have the following code to grab filterMain and return it as a
function.
getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a)
getFilterMain fMainLoc = do
loadModules
[fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)]
fMain - (interpret (filterMain) (as :: Deliverable a
= Filter a)) return (fMain)
However, when I try to compile
this, I get the type error:
Hackmain.hs:70:43:
Ambiguous type variable `a' in the constraint:
`Deliverable a'
[Haskell-cafe] Haskell Logo Voting will start soon!
Hi there! It's been quiet for a while around the 'new logo' competition, but here is how it is going to work: The list with options can be found here (for now): http://community.haskell.org/~eelco/poll.html Notice that some (very) similar logos are grouped as one option (thanks to Ian Lynagh) All submissions compete, so that still makes more than a 100 options! The voting system we'll use is the Condorcet Internet Voting System (http://www.cs.cornell.edu/andru/civs.html ). The poll won't be public, but every subscriber to Haskell-Cafe will get a (private) voting ballot by email. The poll will (probably) start March 16 and run for about a week (don't worry, there will be a strict deadline communicated). When the poll is over, the results will be viewable by everybody. The CIVS allows easy grouping and ordering, so the task of ordering 100 options should be doable within 5-10 minutes. If you're in a hurry you can do it a lot faster, just pick your favorite and put it first. If you want to learn more about condorcet voting, the CIVS site and Wikipedia are your friends. I'll supervise the poll and make sure it's started, stopped and all Haskell-Cafe subscribers get a ballot (Simon Marlow provided the email addresses). Since I'm going on a (probably internet deprived) holiday for a week _and_ to make sure I haven't overlooked anything, I'm announcing it now but won't start the poll till March 16. Of course, I'd love to hear about anything that I missed and/or that might influence the voting process in a significant way. (There are probably some people subscribed with multiple addresses, but I'll be using the subscriber list from yesterday, so signing up now with lots of addresses won't get you more ballots ;) -- Regards, Eelco Lempsink PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?
On Wed, 4 Mar 2009, John Lato wrote: John A. De Goes schrieb: Elsewhere, laziness can be a real boon, so I don't understand your question, Why have laziness in Haskell at all? As I have written, many libaries process their data lazily (or could be changed to do so without altering their interface) but their interface can forbid application to data that is fetched from the outside world. Say you are used to 'map', 'filter', 'foldr' - you cannot use them on data fetched by the iteratee/enumerator approach. Thank you for replying to this; it's good to see what features people would like to make iteratees more useful. Where did you get the idea that you can't use 'map'? What I meant was, that you cannot just use the functions you are used from Data.List. You need functions adapted to Iteratee. This also implies that all libraries written in terms of Data.List functions cannot be used as they are. Maybe it's a good time to review those libraries, whether they need lists at all, or whether they would also work with functionality that can be provided by Iteratees. The question, whether libraries should be bound to lists and Strings did already arise with ByteStrings. So Iteratees may be just one more reason to generalize the libraries. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell Logo Voting will start soon!
Eelco Lempsink ee...@lempsink.nl wrote: The poll won't be public, but every subscriber to Haskell-Cafe will get a (private) voting ballot by email. What about us gmane users? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Logo Voting will start soon!
eelco: Hi there! It's been quiet for a while around the 'new logo' competition, but here is how it is going to work: The list with options can be found here (for now): http://community.haskell.org/~eelco/poll.html Notice that some (very) similar logos are grouped as one option (thanks to Ian Lynagh) All submissions compete, so that still makes more than a 100 options! The voting system we'll use is the Condorcet Internet Voting System (http://www.cs.cornell.edu/andru/civs.html). The poll won't be public, but every subscriber to Haskell-Cafe will get a (private) voting ballot by email. The poll will (probably) start March 16 and run for about a week (don't worry, there will be a strict deadline communicated). When the poll is over, the results will be viewable by everybody. The CIVS allows easy grouping and ordering, so the task of ordering 100 options should be doable within 5-10 minutes. If you're in a hurry you can do it a lot faster, just pick your favorite and put it first. If you want to learn more about condorcet voting, the CIVS site and Wikipedia are your friends. I'll supervise the poll and make sure it's started, stopped and all Haskell-Cafe subscribers get a ballot (Simon Marlow provided the email addresses). Since I'm going on a (probably internet deprived) holiday for a week _and_ to make sure I haven't overlooked anything, I'm announcing it now but won't start the poll till March 16. Of course, I'd love to hear about anything that I missed and/or that might influence the voting process in a significant way. (There are probably some people subscribed with multiple addresses, but I'll be using the subscriber list from yesterday, so signing up now with lots of addresses won't get you more ballots ;) Excellent work Eelco, and thanks for pushing this forward! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do you have to use fix with forkio?
In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. fix $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. \loop - do (nr', line) - readChan chan' when (nr /= http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:/= nr') $ http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:. hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? -- Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, 2009-03-05 at 16:12 -0800, Jonathan Cast wrote: On Thu, 2009-03-05 at 15:36 -0800, Daryoush Mehrtash wrote: In this chat server implementation http://www.haskell.org/haskellwiki/Implement_a_chat_server forkIO is used with fix as in: reader - forkIO $ fix $ \loop - do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop Do you have to use fix? Or is there a way to write this with a let? You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Both are poorish style. reader - forkIO $ forever $ do (nr', line) - readChan; when (nr /= nr') $ putStrLn hdl line ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Hi I've downloaded Hackmain from patch-tag, but I'm getting a different error. The error I get is: Hackmain.hs:63:10: No instance for (Data.Typeable.Typeable2 Control.Monad.Reader.Reader) arising from a use of `interpret' at Hackmain.hs:63:10-67 Hint requires the interpreted values to be an instance of Typeable in order to check, in runtime, that the interpreted value matches the type declared at compile. Therefore, you need to make sure that (Filter a) is indeed an instance of Typeable. Since you have Filter a = Reader (Config, Email) a, you probably need to - Derive Config and Email instances for Filter, - Manually provide Typeable instances for Reader a b, something along the lines of: instance (Typeable a, Typeable b) = Typeable (Reader a b) where... (I don't know why this isn't done in the mtl) - Change the signature to: getFilterMain :: (Typeable a, Deliverable a) = FilePath - Interpreter (Filter a) Also, you can try using infer instead of as :: Hope that helps Daniel On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of Typeable; (forall a. Deliverable a = Filter a) most certainly is not. Off the top of my head, you have a couple of directions you can take this. (1) Make Typeable a superclass of Deliverable, saying that all deliverable things must be dynamically typeable. Then derive Typeable on Filter, and have the result be of type Filter a using ScopedTypeVariables as suggested before. (You can also pass infer to the interpreter and let the compiler try to figure out the result type instead of passing (as :: SomeType).) (2) Make a newtype wrapper around Filter and give it an instance of Typeable, and add a constraint to filterMain that the result type in the filter is also typeable. Then unwrap the newtype after the interpreter completes. Good luck; I've never tried to use the Haskell interpreter before, so I'm curious how well it works and what problems you have with it! -- ryan 2009/3/5 Joseph Fredette jfred...@gmail.com: I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad called Filter which is simply: type Filter a = Reader (Config, Email) a To encompass all the email filtering. The method I need to import, filterMain, has type: filterMain :: Deliverable a = Filter a where Deliverable is a type class which abstracts over delivery to a path in the file system. The notion is that I can write a type
Re: [Haskell-cafe] Re: Left fold enumerator - a real pearl overlooked?
On Thu, 2009-03-05 at 23:52 +0100, Henning Thielemann wrote: On Wed, 4 Mar 2009, John Lato wrote: John A. De Goes schrieb: Elsewhere, laziness can be a real boon, so I don't understand your question, Why have laziness in Haskell at all? As I have written, many libaries process their data lazily (or could be changed to do so without altering their interface) but their interface can forbid application to data that is fetched from the outside world. Say you are used to 'map', 'filter', 'foldr' - you cannot use them on data fetched by the iteratee/enumerator approach. Thank you for replying to this; it's good to see what features people would like to make iteratees more useful. Where did you get the idea that you can't use 'map'? What I meant was, that you cannot just use the functions you are used from Data.List. You need functions adapted to Iteratee. This also implies that all libraries written in terms of Data.List functions cannot be used as they are. Maybe it's a good time to review those libraries, whether they need lists at all, or whether they would also work with functionality that can be provided by Iteratees. The question, whether libraries should be bound to lists and Strings did already arise with ByteStrings. So Iteratees may be just one more reason to generalize the libraries. In most cases we can get the list version from a continuation based version. A continuation based version can also be used to implement an iterator version. Leaving aside the amount of work, I've been trying to think of how to do a iterator version at all for some libs. Specifically, my zlib binding. Currently the zlib package provides functions on lazy bytestrings: compress, decompress :: ByteString - ByteString This hides all the complications of blocks and filling and draining buffers. However since it uses lazy bytestrings it is most naturally used with lazy io. The question is can I make an interface that also keeps the devotees of iterator based IO happy and also lets me implement the existing api above. I cannot see how to do it. Note that compress and decompress are pure. This is something that I want to keep. I don't want to go back to using IO for a pure operation like compression just for the sake of iterator IO. The problem of course is that while zlib compression is pure overall, there is an internal state thread. That must be threaded linearly. We cannot hand out a continuation that can be run multiple times. Lining up the zlib state thread with the memoising lazy list works perfectly. I cannot see how we do the same with an iterator interface. I'm not saying it cannot be done. On the contrary, I would like to see it done. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficulties in accessing inner elements of data types
Hi David, I'm working on a Haskell library for interacting with emacs org files. For those that do not know, an org file is a structured outline style file that has nested headings, text, tables and other elements. Great! Sounds like fun. :) Now, this all works as expected (files are correctly being parsed and written), however I am having a lot of trouble trying to come up with a decent API to work with this. While writing an OrgFile is fairly easy, reading (and accessing inner parts) of an org file is very tedious, and modifying them is horrendous. I can imagine. However, I don't know if this is even possible, how to do it, or if there is a better alternative to this. I would really apreciate any hints with regards to this. It would be useful to know if there are other libraries that also face this problem, and how they solved it. I definite agree with Neil: I think generic programming is exactly what you are looking for. Fortunately, there are a number of libraries available to help you solve your problem. The next problem is figuring out which one and learning how to it. For this purpose, a comparison of libraries for generic programming in Haskell was recently published: http://www.cs.uu.nl/wiki/Alexey/ComparingLibrariesForGenericProgrammingInHaskell That should give you an idea of what's out there and the pros and cons of each library. I found your example particularly interesting, so I decided to try out a solution in EMGM (Extensible and Modular Generics for the Masses). I wrote up my experiment here: http://splonderzoek.blogspot.com/2009/03/experiments-with-emgm-emacs-org-files.html More information on EMGM is here: http://www.cs.uu.nl/wiki/GenericProgramming/EMGM I'd be happy to help you figure out if EMGM is appropriate for other things you want to do. Good luck with your library! Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Oh, crap- I must have never pushed the latest patches, I did put the typeable instances in all the appropriate places. And provided a (maybe incorrect? Though I'm fairly sure that shouldn't affect the bug I'm having now) Typeable implementation for Reader, but I still get this ambiguous type. I'll push the current version asap. Thanks. /Joe Daniel Gorín wrote: Hi I've downloaded Hackmain from patch-tag, but I'm getting a different error. The error I get is: Hackmain.hs:63:10: No instance for (Data.Typeable.Typeable2 Control.Monad.Reader.Reader) arising from a use of `interpret' at Hackmain.hs:63:10-67 Hint requires the interpreted values to be an instance of Typeable in order to check, in runtime, that the interpreted value matches the type declared at compile. Therefore, you need to make sure that (Filter a) is indeed an instance of Typeable. Since you have Filter a = Reader (Config, Email) a, you probably need to - Derive Config and Email instances for Filter, - Manually provide Typeable instances for Reader a b, something along the lines of: instance (Typeable a, Typeable b) = Typeable (Reader a b) where... (I don't know why this isn't done in the mtl) - Change the signature to: getFilterMain :: (Typeable a, Deliverable a) = FilePath - Interpreter (Filter a) Also, you can try using infer instead of as :: Hope that helps Daniel On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of Typeable; (forall a. Deliverable a = Filter a) most certainly is not. Off the top of my head, you have a couple of directions you can take this. (1) Make Typeable a superclass of Deliverable, saying that all deliverable things must be dynamically typeable. Then derive Typeable on Filter, and have the result be of type Filter a using ScopedTypeVariables as suggested before. (You can also pass infer to the interpreter and let the compiler try to figure out the result type instead of passing (as :: SomeType).) (2) Make a newtype wrapper around Filter and give it an instance of Typeable, and add a constraint to filterMain that the result type in the filter is also typeable. Then unwrap the newtype after the interpreter completes. Good luck; I've never tried to use the Haskell interpreter before, so I'm curious how well it works and what problems you have with it! -- ryan 2009/3/5 Joseph Fredette jfred...@gmail.com: I've been working on a little project, and one of the things I need to do is dynamically compile and import a Haskell Source file containing filtering definitions. I've written a small monad
Re: [Haskell-cafe] do you have to use fix with forkio?
Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. Thanks, Donn cave PS - granted that forever is a fine alternative to either, I suppose it doesn't affect the style comparison above. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do you have to use fix with forkio?
On Thu, Mar 5, 2009 at 6:27 PM, Donn Cave d...@avvanta.com wrote: Quoth Jonathan Cast jonathancc...@fastmail.fm: You can certainly use let: reader - forkIO $ let loop = do (nr', line) - readChan chan' when (nr /= nr') $ hPutStrLn hdl line loop in loop But the version with fix is clearer (at least to people who have fix in their vocabulary) and arguably better style. Would you mind presenting the better style argument? To me, the above could not be clearer, so it seems like the version with fix could be only as clear, at best. I like using fix when it's simple rather than let, because it tells me the purpose of the binding. eg., when I see let foo = ... Where ... is fairly long, I'm not sure what the purpose of foo is, or what its role is in the final computation. It may not be used at all, or passed to some modifier function, or I don't know what. Whereas with: fix $ \foo - ... I know that whatever ... is, it is what is returne, and the purpose of foo is to use that return value in the expression itself. I know that it's a simple matter of scanning to the corresponding in, but let can be used for a lot of things, where as fix $ \foo is basically only for simple knot-tying. Now, that doesn't say anything about the use of fix without an argument (passed to an HOF) or with a tuple as an argument or many other cases, which my brain has not chunked nearly as effectively. I think fix is best with a single, named argument. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Calculating with list comprehension
I can calculate non-nested list comprehensions without a problem, but am unable to calculate nested comprehensions involving, for example, the generation of a list of pairs where the first and separate elements are drawn from two separate lists, as in: [(a, b) | a - [1..3], b - [1..2]] How does one calculate the expansion of this list? The two rules for expanding list comprehensions are: 1. Generator rule: [e | x - xs, Q] = concat (map f xs) where f x = [e | Q] 2. Guard rule: [e | p, Q]= if p then [e | Q] else [] There is a third rule that I've seen on the Internet, not in an authoritative text: [e | Q1 , Q2] = concat [ [e | Q 2] | Q1 ] I don't understand what this third rule means, or whether it's relevant. Concat and map are defined as: concat :: [[a]] - [a] concat []= [] concat (xs:xss) = xs ++ concat xss map :: (a - b) - [a] - [b] map f [] = [] map f (x:xs) = f x : (map f xs) Any help is appreciated. _ Windows Live™: Life without walls. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_032009___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calculating with list comprehension
Keep in mind this is a *lexical* rewrite. In the generator rule x and e are not independent: x is a pattern (which introduces a bind variable) and e is an expression (with free variables, one of which may be bound by x) After one application of the generator rule, we get (using a lambda expression instead of introducing a fresh function name f): concatMap (\a - [(a,b) | b - [1..2]]) [1..3] After another: concatMap (\a - concatMap (\b - [(a,b)]) [1..2]) [1..3] Note that the a - and b - map into \a - and \b - and bind the free variables a and b in the expression (a,b). Dan R J wrote: I can calculate non-nested list comprehensions without a problem, but am unable to calculate nested comprehensions involving, for example, the generation of a list of pairs where the first and separate elements are drawn from two separate lists, as in: [(a, b) | a - [1..3], b - [1..2]] How does one calculate the expansion of this list? The two rules for expanding list comprehensions are: 1. Generator rule: [e | x - xs, Q] = concat (map f xs) where f x = [e | Q] 2. Guard rule: [e | p, Q]= if p then [e | Q] else [] There is a third rule that I've seen on the Internet, not in an authoritative text: [e | Q1 , Q2] = concat [ [e | Q 2] | Q1 ] I don't understand what this third rule means, or whether it's relevant. Concat and map are defined as: concat :: [[a]] - [a] concat []= [] concat (xs:xss) = xs ++ concat xss map :: (a - b) - [a] - [b] map f [] = [] map f (x:xs) = f x : (map f xs) Any help is appreciated. Windows Live™: Keep your life in sync. Check it out. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1b_explore_032009 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hint and Ambiguous Type issue
Ok, so I've pulled the latest version and the error I get now is: Hackmain.hs:70:43: Ambiguous type variable `a' in the constraint: `Deliverable a' arising from a use of `getFilterMainStuff' at Hackmain.hs: 70:43-60 Probable fix: add a type signature that fixes these type variable(s) Function getFilterMainStuff compiles just fine . The offending line is in buildConf and reads: (inboxL, fMain) - runUnsafeInterpreter . getFilterMainStuff $ filterMainL The problem is that GHC can't figure out the type of fMain. It infers (Filter a), but doesn't know what is a and therefore how to build a proper dictionary to pass to getFilterMainStuff. Observe that you would get a similar error message if you just defined: f = show . read I can get it to compile by providing a type annotation for fMain: (inboxL, fMain) - runUnsafeInterpreter . getFilterMainStuff $ filterMainL let _ = fMain :: Filter MaildirEmail So once you use fMain somewhere and GHC can infer it's type, everything should work fine. Daniel On Mar 5, 2009, at 11:26 PM, Joseph Fredette wrote: Oh, crap- I must have never pushed the latest patches, I did put the typeable instances in all the appropriate places. And provided a (maybe incorrect? Though I'm fairly sure that shouldn't affect the bug I'm having now) Typeable implementation for Reader, but I still get this ambiguous type. I'll push the current version asap. Thanks. /Joe Daniel Gorín wrote: Hi I've downloaded Hackmain from patch-tag, but I'm getting a different error. The error I get is: Hackmain.hs:63:10: No instance for (Data.Typeable.Typeable2 Control.Monad.Reader.Reader) arising from a use of `interpret' at Hackmain.hs:63:10-67 Hint requires the interpreted values to be an instance of Typeable in order to check, in runtime, that the interpreted value matches the type declared at compile. Therefore, you need to make sure that (Filter a) is indeed an instance of Typeable. Since you have Filter a = Reader (Config, Email) a, you probably need to - Derive Config and Email instances for Filter, - Manually provide Typeable instances for Reader a b, something along the lines of: instance (Typeable a, Typeable b) = Typeable (Reader a b) where... (I don't know why this isn't done in the mtl) - Change the signature to: getFilterMain :: (Typeable a, Deliverable a) = FilePath - Interpreter (Filter a) Also, you can try using infer instead of as :: Hope that helps Daniel On Mar 5, 2009, at 8:47 PM, Joseph Fredette wrote: So, I tried both of those things, both each alone and together. No dice. Same error, so I reverted back to the original. :( However, I was, after some random type signature insertions, able to convert the problem into a different one, via: getFilterMain :: Deliverable a = FilePath - Interpreter (Filter a) getFilterMain MainLoc = do loadModules [fMainLoc]; setTopLevelModules [(takeWhile (/ ='.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: Deliverable a = Filter a) Inferred type is less polymorphic than expected Quantified type variable `a' is mentioned in the environment: fMain :: Filter a (bound at Hackmain.hs:77:1) In the first argument of `return', namely `(fMain :: (Deliverable a) = Filter a)' In the expression: return (fMain :: (Deliverable a) = Filter a) In the expression: do loadModules [fMainLoc] setTopLevelModules [(takeWhile (/= '.') fMainLoc)] fMain - (interpret (filterMain) infer) return (fMain :: (Deliverable a) = Filter a) I'm thinking that this might be more easily solved -- I do think I understand the issue. somehow, I need to tell the compiler that the 'a' used in the return statement (return (fMain :: ...)) is the same as the 'a' in the type sig for the whole function. While I ponder this, and hopefully receive some more help -- thanks again Dan, Ryan -- Are there any other options besides Hint that might -- at least in the short term -- make this easier? I'd really like to finish this up. I'm _so_ close to getting it done. Thanks, /Joe Ryan Ingram wrote: So, by using the Haskell interpreter, you're using the not-very-well-supported dynamically-typed subset of Haskell. You can tell this from the type signature of interpret: interpret :: Typeable a = String - a - Interpreter a as :: Typeable a = a as = undefined (from http://hackage.haskell.org/packages/archive/hint/0.2.1/doc/html/src/Language-Haskell-Interpreter-GHC.html) In particular, the as argument to interpret is specifying what type you want the interpreted result to be typechecked against; the interpretation fails if it doesn't match that type. But you need the result type to be an instance of
Re: [Haskell-cafe] Re: [Haskell] Lazy IO breaks purity
On 2009 Mar 5, at 8:08, Simon Marlow wrote: So the argument is something like: we can think of the result of a call to unsafeInterleaveIO as having been chosen at the time we called unsafeInterleaveIO, rather than when its result is actually evaluated. This is on dodgy ground, IMO: either you admit that the IO monad contains an Oracle, or you admit it can time-travel. I don't believe in either of those things :-) ...hasn't sigfpe demonstrated time travel using comonads? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficulties in accessing inner elements of data types
Well thanks to everyone that has replied so far - I've had an interesting time
trying out different ideas.
Firstly, for Neil Mitchell's suggestions regarding uniplate:
I read through both uniplate and scrap your boilerplate libraries (found the
second after reading about uniplate). For whatever reason, I understood syb
better than uniplate (but thats probably just me). This actually worked quite
well (note that I've changed the data types slightly, but it doesn't change
the code that much):
eitherOr :: Either a b - Either a b - Either a b
eitherOr x@(Right _) _ = x
eitherOr _ y = y
getP14Desc :: OrgElement - Either ErrString String
getP14Desc org = everything eitherOr (Left descError `mkQ` findDesc) =
everything eitherOr (Left findError `mkQ` findP14) org
where
findP14 h@(Heading {headingName=name})
| name == Project14 = Right h
findP14 _ = Left findError
findDesc (Paragraph {paragraphText=text})
| text =~ Description = Right text
findDesc _ = Left findError
descError = Couldn't find description for project
findError = Couldn't find project.
While it isn't that many less loc than my original code, it was much simpler
to get working. Also, the find methods could easily be factored out. My second
problem, adding the tag Hard to Project2 was also fairly simple:
addHardTag org = everywhere (mkT addTagToP2) org where
addTagToP2 h@(Heading {headingName=name})
| name == Project 2 = everywhere (mkT addTag) h
addTagToP2 x = x
addTag text
| text =~ Tags: = text ++ ,newtag
However, I also wanted to try out Tim Docker's suggestion for using data-
accessor. That seemed to also be very promising, except for one thing - data-
accessor doesn't seem to be able to cope with multiple constructors! The code
for this was faily simple though, so I went about making it work for multiple
constructors.
The original definition for an Accessor d f (where d is the datatype and f is
the type of the field) was
Cons {decons :: d - f - (d, f)} -- (this wasn't exported by the module
though)
There is a problem with that for multiple constructors though - its possible
that there will be no return for a given accessor. Eg running get headingName'
(Paragraph some text) would not be possible. So I changed the code to this:
newtype Accessor1 d f = Accessor (d - Maybe f, f - d - d)
If the getter failed, Nothing is returned. If the setter failed, it acts like
id.
After using that for a while I realized there was potential to have an
accessor automatically access all the children of a data type. This could be
achieved by changing the return type of the getter to [f], and changing the
setter function to a modifier function:
newtype MultiConAccessor d f = MultiConAccessor ((d - [f]),((f - f) - d -
d))
I also wrote the chain function, which joins to accessors together
After a lot of definitions (although most should be able to be automated with
template haskell), I could use the code:
projectAccessor name = headingChildren' `chain` -- top level elements
headingChildren' `chain` -- level 2
liftFilterS (== name) headingName'
getP14Desc2 = getVal $
projectAccessor Project14 `chain`
headingChildren' `chain`
liftFilterS (=~ Description:) paragraphText' `chain`
paragraphText'
addHardTag2 = modVal
(projectAccessor Project 2 `chain`
headingChildren' `chain`
liftFilterS (=~ Tags:) paragraphText' `chain`
paragraphText') (++ ,newtag)
I've posted all the code at
http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=1778#a1778
It isn't very well documented, as I was just experimenting with this.
Finally, thanks Sean for your response. That blog post was very nice! Your
solution also looks good (especially since most of the code was automated). I
haven't had a chance to have a close look at EMGM but will in the next couple
of days.
So I've gone from having no solution a few days ago to having 3 or 4 now! Not
sure which solution I will stick with, any seem to do the job.
So thanks everyone!
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
