Re: [Haskell-cafe] Re: optimization help
Hello apfelmus, Thursday, October 12, 2006, 4:42:14 PM, you wrote: A better solution would be to begin output before the the whole input is read, thus making things more lazy. This can be done the following way: from the input, construct a lazy list of (date,line) pairs. Then, let foldM thread a map from dates to corresponding output file pointers through the list and, at the same time, use the file pointers to output the line in question via appendFile. This way, every line consumed is immediately dispatched to its corresponding output file and things should only require memory for the different dates, besides buffering. In a setting without IO, the task corresponds to the Optimization Problem discussed at length in September on this list. The problem here is that writeFile currently cannot be interleaved lazily, this has to be simulated with appendFile. We can read files lazily but we cannot output them lazily. Can this be remedied? Can there be a version of writeFile which is, in a sense, dual to getContents? this can be solved in other way. here is a program that reads stdin and puts to stdout lines starting with '' and to stderr the rest. note that our main processing function is pure: main = do a - getContents let b = map (processing stdout stderr) (lines a) mapM_ (\(file,line) - hPutStrLn file line) b processing file1 file2 line = if `isPrefixOf` line then (file1,line) else (file2,line) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Howto Haskell in PocketPC?
Hi. Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: optimization help
Paul Hudak wrote: In fact avoiding space leaks was one of the motivations for our moving to an arrow framework for FRP (now called Yampa). Arrows amount to a point-free coding style, although with arrow syntax the cumbersomeness of programming in that style is largely alleviated. I think that's an entirely different thing. You changed representation of signal transformers from newtype SF a b = SF ([a] - [b]) to data SF a b = SF (a - (b, SF a b)) By enforcing a synchronous processing, you avoid leaking Signals. The latter cannot be isomorphic to a function type (Signal a - Signal b) for an appropriate Signal, so this implies a point-free style as there is no way to hold stuff of type (Signal a) in variable bindings. This does not mean that there is no point-wise syntax for arrows, it just means that point-wiseness cannot be achieved via variables in the context of function application, i.e. via lambda abstraction. In fact, the main point about Arrows is not that they are an abstraction for computations but that they allow a point-wise syntactic sugar (which stems from their computational being, of course)! The optimization problem here uses (almost) one and the same representation (pure (a - b), sometimes packed in (a - IO b)) and point-free turns out to be space friendlier than point-wise. That's very puzzling and i think ghc -O2 should eliminate this. Regards, afpelmus PS: IMHO the semantics of (SF a b) need a real cleanup. (Time - a) - (Time - b) is too crude, because these map transformers even cannot be made an instance of ArrowChoice. Also, Dirac-like peaks (that is Events) do not fit in. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: [GHC] #939: Possible bug building wxhaskell
Hi Jason, Jun Mukai aka. jmuk already tried and successed to build wxhaskell on GHC 6.6. Here is his install log. http://sequence.complete.org/node/214 And I made patch for ghc 6.6 from it. Attached solves a few problem ... but you must be careful to your permission. This patch solve package's interface problem with separated build and install process support. And make (make all) depend on installing wxcore. So you have to use sudo other than Windows. I don't know what is the best approach. But advantage is We can make binary (easy install) package for Windows and Mac OS X user. http://www.haskell.org/pipermail/glasgow-haskell-users/2006-September/011043.html You can build binary package following command. make make before-dist make bindist Note that attached fix only GHC 6.6 problem, doesn't fix other - no GHC 6.6 reason - problems. If you will failure to build from other problems, you must see this page first. http://www.haskell.org/haskellwiki/WxHaskell/Install Best Regards, On Sat, 14 Oct 2006 09:29:45 +0900, Jason Dagit [EMAIL PROTECTED] wrote: I reported the following bug and received the response below. Any wxhaskell hackers up to the challenge? I'd really love to see the makefiles go away and see wxhaskell just use cabal but I don't know if that's possible given the wxhaskell build requirements. Any help is much appreciated. Thanks Jason -- Forwarded message -- From: GHC [EMAIL PROTECTED] Date: Oct 13, 2006 5:21 PM Subject: Re: [GHC] #939: Possible bug building wxhaskell To: [EMAIL PROTECTED] #939: Possible bug building wxhaskell -+-- Reporter: [EMAIL PROTECTED] |Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.6 Severity: normal| Resolution: invalid Keywords:| Difficulty: Unknown Architecture: x86 | Os: Unknown -+-- Changes (by duncan): * resolution: = invalid * status: new = closed Comment: It's not a GHC bug. It's a problem with the way wxHaskell is built. Admitidedly this is due to a slight change in the way GHC manages packages but it's not a bug as such, wxHaskell just needs fixing. What needs to happen is that the packages must be registered locally before they get used in other packages. Also, instead of importing the modules from the other package directly from the directory with -i foo/, it must be via -package foo. So you'll need to get in contact with someone who knows enough about wxHaskell's build system to fix it. Try asking on the ghc-users or haskell-cafe mailing lists. The bug report: I appologize if this isn't a GHC bug but since it started happening after a GHC upgrade I suspect it's a GHC bug. After upgrading to ghc6.6 on windows (using the release binary) I tried to install the current wxhaskell release found here: http://wxhaskell.sourceforge.net/download.html (version wxhaskell-src-0.9.4-1.zip) I have used wxhaskell on this machine before with older version of ghc (including ghc6.5, specifically visual haskell) so my environment for building the wxhaskell source was already setup. When I first got the error below I thought maybe my version of wxhaskell was messed up so I redownloaded the above zip file and unzipped a fresh copy. I unziped the source then I typed: configure make Things went along fairly smoothly for a while then suddenly I got this error message: ghc -c wx/src/Graphics/UI/WX/Types.hs -o out/wx/imports/Graphics/UI/WX/Types.o -iout/wx/imports -odir out/wx/imports -hidir out/wx/imports -fvia-C -package-name wx -iout/wx/imports wx/src/Graphics/UI/WX/Types.hs:94:0: Bad interface file: out/wx/imports/Graphics/UI/WXCore/Types.hi Something is amiss; requested module wx:Graphics.UI.WXCore.Types differs from name found in the interface file wxcore:Graphics.UI.WXCore.Types make: *** [out/wx/imports/Graphics/UI/WX/Types.o] Error 1 -- shelarcy shelarcycapella.freemail.ne.jp http://page.freett.com/shelarcy/ fix_building_ghc-6.6.diff Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fwd: [GHC] #939: Possible bug building wxhaskell
On Sat, 2006-10-14 at 20:32 +0900, shelarcy wrote: Hi Jason, Jun Mukai aka. jmuk already tried and successed to build wxhaskell on GHC 6.6. Here is his install log. http://sequence.complete.org/node/214 And I made patch for ghc 6.6 from it. Attached solves a few problem ... but you must be careful to your permission. This patch solve package's interface problem with separated build and install process support. And make (make all) depend on installing wxcore. So you have to use sudo other than Windows. Ah, that's shame. I was being lazy and hoping someone would provide a fix that we can use for distro packages. :-) At the moment it looks like -- in Gentoo at least -- wxHaskell is going to be the only package left behind in the transition to GHC-6.6. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: function result caching
G'day all. Carl Witty wrote: Instead of using an infinite list, you can use an infinite binary tree, with a cached result at every node. Quoting [EMAIL PROTECTED]: This, also known as patricia tree, is indeed the canonical answer. A Patricia tree is but one infinite tree data structure. There's another (which is actually an infinite list of balanced binary trees) at http://haskell.org/hawiki/MemoisingCafs Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Automatic fixity allocation for symbolic operators
Hi - I'm wondering if it is possible to construct a methodical procedure to assign a fixity to symbolic operators so that we could get rid of the need for user defined fixites. User defined fixities are an enormous problem for an interactive editor, because it is not possible to construct a parse tree of some code if you don't know what the fixities are, and an editor must be able to do something useful with a code fragment without having to look inside other modules (because the other modules may not yet have even been written!). Also, the programmer or reader of code needs to be able to understand each code fragment independently as well. From the Haskell98 report, the Prelude defines: infixr 9 ., !! infixr 8 ^, ^^, ** infixl 7 *, /, `quot`, `rem`, `div`, `mod` infixl 6 +, - infixr 5 :, ++ infix 4 ==, /=, , =, =, infixr 3 infixr 2 || infixl 1 , = infixr 1 = infixr 0 $, $!, `seq` Suppose we ignore the varid operators and just consider the symbolic ops. What I'm trying to find is a systematic way to assign fixities to all other possible sequences of symbol characters that is consistent with what we've already got in the Prelude. As a first step, we could say that mirrored operators must share the same precedence ie: == For associativity, we could assign each character an associativity weight: -1 left associative 0neutral 1right associative and say that the associativity is simply the sign of the sum of the associativity weights of the characters thus: -1 =0 1 =0 + 1 + 1ie infixr Note that I don't care about non-associative ops since the non-associativity of something should be a question for the type checker not the parser imho - ideally we should be able to create a parse tree for any possible operator expression. To form the precedence, we could assign each character a precedence value eg: 9 .! 8^ 7*/ 6+- 5: 4= 3 2| 1 0$ A first attempt might be to say that the precedence is simply the decimal expansion of the precedence values eg = has precedence 1.14 and $! has precedence 0.9. However, as noted above, mirrored ops must share the same precedence so an alternative is to create some ordering of characters such that when the set of characters in an operator is sorted according to this ordering, the decimal expansion of the precedence digits will give the same relative ordering for operator precedences as the Prelude. For example, using $ | + - * / ^ . ! : = as the ordering, we'd get: infixr 9 .!! 99.9 infixr 8 ^, ^^, **8 8.87.7 infixl 7 *, /,77 infixl 6 +, -6 6 infixr 5 : , ++ 56.6 infix 4 ==, /=, , =, =, 4.4 7.4 11.41.41 infixr 3 3.3 infixr 2 ||2.2 infixl 1 , =1.11.14 infixr 1 =1.14 infixr 0 $, $!00.9 Although most existing ops get a similar precedence (eg ^ ^^ and ** are all still in the same group relative to the other ops despite the fact that within the group there is now an ordering) the main problem seems to be that = = get precedences that bind too loosely and /= is totally wrong. This problem aside, the above algorithm would give sensible precedences for such things as: :: 5.1 +*6.116.11 where the use of neutralizes the associativity contribution of or respectively (since (-1) + 1 == 0), giving us the intuitive associativity we'd expect from the interesting character in the middle. (The problem of /= getting 7.4 could be solved by putting / after = in the order, to get 4.7, but unfortunately this would mean that since must be before =, would be before / so / would get the wrong precedence compared to *) Another issue is that there is no assignment of associativity weights such that * is infixl but ** is infixr (ditto + and ++) so perhaps we'd need to associate each character with an associativity function. Similar to precedences, we then define an associativity ordering and let the resulting associativity be the sign of the composition of the sorted functions applied to 1 eg: ^ const (-1) * \x - x * (-1) = id const (-1) (+1) (+ (-1)) Then *(\x - x * (-1)) 1===-1 ie left ** (\x - x * (-1)) . (\x - x * (-1)) $ 1 === +1 ie right = = (+ (-1)) . (+ (-1)) . id$ 1 === -1 *-- remember ordering
Re: [Haskell-cafe] Howto Haskell in PocketPC?
This has been around for some time already. It used to work with PPC2003, hopefully it'll still do: http://www.comp.nus.edu.sg/~luzm/ppchugs/ Enjoy it :) On 14/10/2006, at 8:24, Iván Pérez Domínguez wrote: Hi. Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC? ___ 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] Howto Haskell in PocketPC?
Hi, Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC? If you want to port Yhc [1] it shouldn't take more than a couple of hours. Thanks Neil 1: http://www.haskell.org/haskellwiki/Yhc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
Robert Dockins [EMAIL PROTECTED] writes: slowFunctionCacheList= [slowFunction (i) | i -[0..500]] and use slowFunctionCacheList !! i instead of slowFunction (i) Not much different in principle, but better in practice - you could use an array rather than a list. O(1) lookups should make things (a lot) faster. Well, this is true only if the range of the domain function is small and fairly dense. I don't think so. With 500 elements, you're looking at allocating about 20Mb of memory On the other hand, the lists allocates the 20Mb of pointers, *and* another 20Mb of cons cells for the lists. to hold pointers to closures_ and then allocating and filling out 500 closures, all before you get down to doing any real work! If I interpret you correctly, you want to make the array's contents strict? Not a good idea when the domain is sparse, but on the other hand it would let you unbox the contents, which means you'd only need to store the actual values. For boolean values, I think GHC stores one bit per value, i.e. less than a MB for this range. Little-endian patricia trees [...] Yes, sure, if you can't afford a 20Mb index. On the other hand, changing the function to use an array is a very small modification, and probably more than good enough in many cases. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
Brian Hulley wrote: infixr 9 .!! 99.9 infixr 8 ^, ^^, **8 8.87.7 infixl 7 *, /,77 infixl 6 +, -6 6 infixr 5 : , ++ 56.6 infix 4 ==, /=, , =, =, 4.4 7.4 11.41.41 infixr 3 3.3 infixr 2 ||2.2 infixl 1 , =1.11.14 infixr 1 =1.14 infixr 0 $, $!00.9 Ouch. Really, the first priority in the language should be human readability. Looking up a fixity isn't that hard, but remembering a rule like this is pretty awful. You also restrict the freedom of library designers for no good reason. Precedences aren't usually random ... As far as editors go I have little sympathy. I also see nothing wrong with forcing a coder to have at least a module stub that defines its interface and the operator precedences, to make the parsing work reliably. You'll have to deal with the case where parsing fails anyway, and it shouldn't be too hard between failures due to unsufficient information (which shouldn't be tagged as errors, but maybe give some other indication) and real errors. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
On Saturday 14 October 2006 13:13, Ketil Malde wrote: Robert Dockins [EMAIL PROTECTED] writes: slowFunctionCacheList= [slowFunction (i) | i -[0..500]] and use slowFunctionCacheList !! i instead of slowFunction (i) Not much different in principle, but better in practice - you could use an array rather than a list. O(1) lookups should make things (a lot) faster. Well, this is true only if the range of the domain function is small and fairly dense. I don't think so. With 500 elements, you're looking at allocating about 20Mb of memory On the other hand, the lists allocates the 20Mb of pointers, *and* another 20Mb of cons cells for the lists. True, but only if you access deeply into the tail of the list. If one access only the first several hundred elements, say, then you'll only allocate the space needed for those. Of course, if you only want to access a small portion at the begining, then why create such a big list in the first place? Moral: lists will lose this contest in almost all cases. to hold pointers to closures_ and then allocating and filling out 500 closures, all before you get down to doing any real work! If I interpret you correctly, you want to make the array's contents strict? Not a good idea when the domain is sparse, but on the other hand it would let you unbox the contents, which means you'd only need to store the actual values. For boolean values, I think GHC stores one bit per value, i.e. less than a MB for this range. No, I didn't suggest that the elements be strict. That would involve precomputing the entire table. You _could_ do that if you anticipate a LOT of access to sufficient to outweigh the initial cost. But that seems unlikely for a sparse domain, as you mentioned. However, even non-strict arrays are created all at once (ie, they are strict in their _structure_), and the closures have to be allocated as the array is being created. Creating a closure isn't terribly expensive, but creating 500 closures might take awhile and cost a lot of memory if the closure has a large number of free variables (which depends on the function definition and the exact details of the lambda lifter). Also, large arrays tend to play havoc with GHC's garbage collector; it has to scan all elements on every major GC, IIRC. That alone may offset any advantages won. In the end, the only way to be sure which method is best is to test it against your usage profile. My guess is that the array method will have enough overhead that it will lose against a tree. However I may be wrong, especially if the program will have a very long runtime and if a warm-up period is acceptable. Little-endian patricia trees [...] Yes, sure, if you can't afford a 20Mb index. On the other hand, changing the function to use an array is a very small modification, and probably more than good enough in many cases. I completely agree; it is good for many cases, and can be a very useful technique. I just don't think it will be good for _this_ case (large, sparse domain where f(n) doesn't depend on all f(m) where m n). That probability is positively correlated with the size of the domain. Again, the only way to really know is to implement and benchmark. Thankfully, caching techniques are completely local and can be changed easily. -k -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
Perhaps the editor could assume a default precedence when the user-defined precedence is not yet available. Preferably, the editor would also somehow yell at the user to indicate that it is making such an assumption. I think it's unreasonable to tie programmers' hands for the sake of off-loading rather trivial tasks to editors. Nick On 10/14/06, Bertram Felgenhauer [EMAIL PROTECTED] wrote: Brian Hulley wrote: infixr 9 .!! 99.9 infixr 8 ^, ^^, **8 8.87.7 infixl 7 *, /,77 infixl 6 +, -6 6 infixr 5 : , ++ 56.6 infix 4 ==, /=, , =, =, 4.4 7.4 11.41.41 infixr 3 3.3 infixr 2 ||2.2 infixl 1 , =1.11.14 infixr 1 =1.14 infixr 0 $, $!00.9 Ouch. Really, the first priority in the language should be human readability. Looking up a fixity isn't that hard, but remembering a rule like this is pretty awful. You also restrict the freedom of library designers for no good reason. Precedences aren't usually random ... As far as editors go I have little sympathy. I also see nothing wrong with forcing a coder to have at least a module stub that defines its interface and the operator precedences, to make the parsing work reliably. You'll have to deal with the case where parsing fails anyway, and it shouldn't be too hard between failures due to unsufficient information (which shouldn't be tagged as errors, but maybe give some other indication) and real errors. Bertram ___ 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: Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
On 10/14/06, Nicolas Frisby [EMAIL PROTECTED] wrote: Perhaps the editor could assume a default precedence when the user-defined precedence is not yet available. Preferably, the editor would also somehow yell at the user to indicate that it is making such an assumption. Perhaps it could even assume the fixity that is specified in the prelude for operators without fixity declarations, thus behaving exactly like the compiler would: Any operator lacking a fixity declaration is assumed to be infixl 9 (4.4.2) I agree that changing the language in such an unintuitive way - breaking existing code in the process - to suit an editor is counterproductive and ridiculous. /g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What's going on in our courses?
Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Indeed, I'd be interested as well. I'm actually looking for a good textbook for a concepts of programming language course. All the books I can find tend to emphasize OO or imperative programming too much for my taste. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What's going on in our courses?
monnier: Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Indeed, I'd be interested as well. I'm actually looking for a good textbook for a concepts of programming language course. All the books I can find tend to emphasize OO or imperative programming too much for my taste. You might want to look at : http://cgi.cse.unsw.edu.au/~cs3161/docs/references.php We use: Bob Harper's book, Programming Languages: Theory and Practice http://www-2.cs.cmu.edu/~rwh/plbook/ and Types and Programming Languages, Benjamin Pierce Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What's going on in our courses?
dons: monnier: Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Also, http://haskell.org/haskellwiki/Haskell_in_education -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error detection in GLR Happy grammar
Hi! I'm trying to detect parse errors in a happy GLR grammar, but I can't! I insert the special token 'error', and call the error function when an error is found. However, the program prints no error messages, and simply returns a ParseError at the end. Does any of you have an good example of a GLR parser with error detection and, if possible, error recovery as well? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] function result caching
thank you for all the answersi was aware lists are is not the best solution, but i was too keen to see the actual result I'll do some tests though using different variants, because i have the feeling that in my next program I'll face the strong form of this problem. On 10/13/06, Silviu Gheorghe [EMAIL PROTECTED] wrote: it does, thank you very much for the quick answer, unfortunately as I understand it, it doesn't work well on ints :(for just now i created a list slowFunctionCacheList= [slowFunction (i) | i -[0..500]] and use slowFunctionCacheList !! i instead of slowFunction (i)it helped alot (i mean i stoped the program after 3 hours still working and got the result in 2 minutes :)) i am still curious about a better method (and a general one), because this is ugly, and it only works on ints as i see it.but then again thank you for telling me it doesn't do it, because i had the false impresion it does and i wouldn't stop it otherwise On 10/13/06, Tom Phoenix [EMAIL PROTECTED] wrote: On 10/12/06, Silviu Gheorghe [EMAIL PROTECTED] wrote: I'd like to know if the results are cachedby the compiler Hardly ever, as I understand things. if they are not I'd like to know what is the best way to cache them manually, and where can I read more about this, and the optimizations the compiler does, because I've searched the web before and i found very little on this topic.You need to search for the word memoize (or memoise). Here's apage about a memo function for GHC. http://www.haskell.org/ghc/docs/6.4.2/html/hslibs/memo-library.htmlHope this helps!--Tom Phoenix ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Automatic fixity allocation for symbolic operators
On 10/14/06, Brian Hulley [EMAIL PROTECTED] wrote: User defined fixities are an enormous problem for an interactive editor This is the second or third time you've proposed a language change based on the editor you're writing. I don't think this is a fruitful avenue. There are three ways to change Haskell's lexical structure: 1. DIY on an open-source compiler/interpreter of your choice. 2. Write your own compiler/interpreter. 3. Get the change into Haskell''. If the Haskell'' procedure is like the Haskell' procedure, you'll have to do 1 or 2 before you do 3. It's possible that you will convince someone that your syntax changes are worth doing, and that this person will do step 1 or step 2 for you, but I don't think so. I haven't done the research myself, but I think if you look at the source control logs for Your Favorite Haskell Compiler/interpreter and the HCAR, you will find very few commits/projects devoted to syntax. I think this is because Haskellers are much more interested in semantics. Proposing changes that break existing code or segment the Haskell code base just doesn't seem like a win. Jim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error detection in GLR Happy grammar
Hello, error isn't implemented yet in GLR mode - it is ignored. Note that yacc-style error handling can't be transplanted directly into GLR, since the nature of parse errors is not the same. In LR(k) errors mean that the single parse can't continue and hence some remedial action is needed. In GLR, it could mean this (when following one unique parse), or with multiple parses that some are being dropped because further input has ruled them out. Recovery on the latter probably isn't correct - they should be discarded. I might try allowing an explicit error token which acts only when one parse is live, and follow standard Happy behaviour for this. If you have an example to test on, it might be useful. Note that for failed parses, you are given a list of unconsumed tokens and the partial parses constructed so far, so some diagnosis is possible. Paul ps. I've almost fixed the module header problem you mentioned before. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [off-topic / administrative] List Reply-to
Antti-Juhani Kaijanaho wrote: Robert Dockins wrote: I think (pure speculation) the haskell.org mail server is set up to omit people from mail it sends if they appear in the To: or Cc: of the original mail. Yes, this is a feature of recent Mailmans. Finally, I agree that reply-to munging is a bad idea, but I don't think appealing to a definition of 'reasonable mailer' that doesn't match a large portion of mail clients currently in the wild is a good way to argue the point. Gnus might have been the first one to have it, but mutt (very popular in hackerdom) was perhaps the one that popularized it. I am currently using Mozilla Thunderbird, for which it is available as an extension (unfortunately, it also requires a patch for Thunderbird; but Debian sid has already applied it). KMail (at least in KDE 3.5.4) has it, too. Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: optimization help
Hello, Yet, I'm a bit astonished. I thought that when compiling with -O2, cosmetic changes should become negligible. Perhaps the strict foldl' has an effect? Perhaps... but I doubt that is the main reason. At the moment I have no idea why there is such a discrepancy between the heap usages... A big part of why the solutions you crafted work so efficiently is that they take advantage of the fact that the rows will be written out exactly as they are read in. I wanted to see if a more general code could maintain the same efficiency. Here is some code to read in a file, write out a file, and do selections-- the idea is that CSV files are internally represented and manipulated as [[ByteString]]. readCSV file = do v - B.readFile file return $ map (B.split ',') $ B.lines v writeCSV file tbl = do h - openFile file WriteMode let writeRow = mapM_ (B.hPut h) . (++ [nl]) . intersperse comma mapM_ writeRow tbl hClose h where comma = B.singleton ',' nl = B.singleton '\n' select targs test (cols : rows) = map narrow (cols : passTest rows) where myFilter = map snd . filter fst passTest = myFilter . map (\row - (runReader test (zip cols [0..], row), row)) narrow = myFilter . zip (map (`elem` targs) cols) col x = do (cols,row) - ask let Just i = lookup (B.pack x) cols return $ row!!i This code runs reasonably fast-- around 13 seconds to read in a 120MB file (~75 rows), select half the columns of around 22000 rows randomly distributed throughout the input table, and write a new CSV file. It takes around 90 seconds to just remove some columns from every row in the table and write a new file. So the slow part of the program is probably the writeCSV function. Do you think these times can be improved upon? -Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
