Re: [Haskell-cafe] Implicit concatenation in list comprehensions
On Sun, 2009-07-19 at 23:07 +0100, Thomas Schilling wrote: 2009/7/19 Max Bolingbroke batterseapo...@hotmail.com Dear Cafe, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] Given that this can easily be simulated via: [ x | (k, v) - [(foo, 1), (bar, 2)], x - [k, =, v, ]] [foo,=,1, ,bar,=,2, ] I believe that the added syntax (which every complete tool operating on Haskell code would have to support) is not worth its price. Except that it's ugly compared to the proposed extension. With the extension you can put things in the same, right place: renderGhcOptions opts = ghcOptExtraPre opts -- source search path ++ [ -i | not (null (ghcOptSearchPath opts)) ] ++ [ -i, dir | dir - ghcOptSearchPath opts ] or using your syntax: ++ [ opt | dir - ghcOptSearchPath opts | opt - [ -i, dir ] ] or another not-so-nice alternative: ++ concat [ [ -i, dir ] | dir - ghcOptSearchPath opts ] When looking down a bunch of these cases, using the extension means we can put the most important bit --- the flag names and arguments --- in the same position rather than sometime having to put them at the end in an extra generator, or having to use extra brackets and a concat. So yes you can certainly simulate it but it does not read nearly so well. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
Except that it's ugly compared to the proposed extension. With the extension you can put things in the same, right place: renderGhcOptions opts = ghcOptExtraPre opts -- source search path ++ [ -i | not (null (ghcOptSearchPath opts)) ] ++ [ -i, dir | dir - ghcOptSearchPath opts ] Following the discussions, I now support this extension too - I keep seeing more and more places in my code where it would be very useful. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Implicit concatenation in list comprehensions
Hello Neil, Tuesday, July 21, 2009, 1:26:55 PM, you wrote: ++ [ -i | not (null (ghcOptSearchPath opts)) ] ++ [ -i, dir | dir - ghcOptSearchPath opts ] Following the discussions, I now support this extension too - I keep seeing more and more places in my code where it would be very useful. ++[ -i | not (null (ghcOptSearchPath opts)) ] ++ concat [ [-i, dir] | dir - ghcOptSearchPath opts ] -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re[2]: [Haskell] TABI 0.1: a typeful tagged cross-language calling convention
Hello Felipe, Tuesday, July 21, 2009, 7:38:44 PM, you wrote: * passing complex datastructures between various languages forth and back, providing faster alternative to serialization approach I've read the code and I don't see how tabi manages to do this. it's not yet implemented :))) my idea is to provide one more basic type, TABI_TABLE=6, that allows to nest TABI_MAPs recursively. also arrays of TABI_* types may be supported It is serializing as well but it is including the type and name information, so it seems that at best it would have the same overhead as just serializing the data without any metadata. my first approach was to use just serialization (it was implemented in Lua sources included). but then i realized that it is monkey work - most time will be spent copying data to buffer, from buffer, searching for delimiters, processing type conversion. i'm pretty sure that C implementation of TABI_MAP will do its work (filling 3-4 words per parameter) an order of magnitude faster than serialization approach. also, serialized data anyway will be need to converted to datastructure like TABI_MAP in order to be used by calls like _str and _int for Haskell code, good optimized serialization library should have comparable speed. moreover, my current approach with malloc() calls probably makes encoding operations much slower if you have any specific needs, we can discuss it. my own needs is mainly combination of first and third clauses of quoted list, so second claim is somewhat artificial :) it is possible but only partially implemented -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
I'm not convinced ugly is a good reason to add more complexity to the language syntax. I am not aware of a good metric to measure the costs/beneficts of new syntactic constructs. Part of the costs are the number of tools that need to be adapted and the extend of their loss of utility if they are not adopted. Granted, we don't have that many tools working on Haskell code, but perhaps the feature-creep is part of the reason (cf. HaRe). Sure, the eagerness of new features added to Haskell (well, GHC mostly) is part reason of Haskell's success. Since we don't have an objective measure, all I can do is to ask people to consider that new syntax is not as cheap as it many seem to think it is. 2009/7/20 Duncan Coutts duncan.cou...@worc.ox.ac.uk: On Sun, 2009-07-19 at 23:07 +0100, Thomas Schilling wrote: 2009/7/19 Max Bolingbroke batterseapo...@hotmail.com Dear Cafe, For fun, I spent a few hours yesterday implement support for this syntax in GHC, originally propsed by Koen Claessen: [k, =, v, | (k, v) - [(foo, 1), (bar, 2)] [foo, =, 1, , bar, =, 2, ] Given that this can easily be simulated via: [ x | (k, v) - [(foo, 1), (bar, 2)], x - [k, =, v, ]] [foo,=,1, ,bar,=,2, ] I believe that the added syntax (which every complete tool operating on Haskell code would have to support) is not worth its price. Except that it's ugly compared to the proposed extension. With the extension you can put things in the same, right place: renderGhcOptions opts = ghcOptExtraPre opts -- source search path ++ [ -i | not (null (ghcOptSearchPath opts)) ] ++ [ -i, dir | dir - ghcOptSearchPath opts ] or using your syntax: ++ [ opt | dir - ghcOptSearchPath opts | opt - [ -i, dir ] ] or another not-so-nice alternative: ++ concat [ [ -i, dir ] | dir - ghcOptSearchPath opts ] When looking down a bunch of these cases, using the extension means we can put the most important bit --- the flag names and arguments --- in the same position rather than sometime having to put them at the end in an extra generator, or having to use extra brackets and a concat. So yes you can certainly simulate it but it does not read nearly so well. Duncan -- Push the envelope. Watch it bend. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] TABI 0.1: a typeful tagged cross-language calling convention
On Tue, Jul 21, 2009 at 08:11:47PM +0400, Bulat Ziganshin wrote: if you have any specific needs, we can discuss it. my own needs is mainly combination of first and third clauses of quoted list, so second claim is somewhat artificial :) it is possible but only partially implemented I was just curious, because it seems to me that the only way of avoiding serialization costs would be having the same representation in memory for all languages and just passing pointers around instead of peek'ing and poke'ing everytime. Thanks, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] TABI 0.1: a typeful tagged cross-language calling convention
On Jul 21, 2009, at 10:37 AM, Felipe Lessa wrote: it seems to me that the only way of avoiding serialization costs would be having the same representation in memory for all languages and just passing pointers around instead of peek'ing and poke'ing everytime. Alternately, a whole slew of point-to-point translators might do the trick. Haskell to Lua (and back), Lua to Ocaml (and back), Ocaml to Ruby (and back), Ruby to Lua, etc., etc. That's a great deal of overhead beyond the canonical representation method, but it would achieve translation without explicit serialization. -johnn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
Bulat Ziganshin wrote:
Hello Neil,
Tuesday, July 21, 2009, 1:26:55 PM, you wrote:
++ [ -i | not (null (ghcOptSearchPath opts)) ]
++ [ -i, dir | dir - ghcOptSearchPath opts ]
Following the discussions, I now support this extension too - I keep
seeing more and more places in my code where it would be very useful.
++[ -i| not (null (ghcOptSearchPath opts)) ]
++ concat [ [-i, dir] | dir - ghcOptSearchPath opts ]
[a | c ] = concat $ do { c; return [a] }
[a,b | c ] = concat $ do { c; return [a,b] }
This would mean that
[ | c ] = concat $ do { c; return [] }
The right is legal Haskell and gives []. The left is (not yet) legal.
Should it be?
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cheap in-repo local branches (just needs implementation)
Hi everyone, Max Battcher had an idea that I thought I should post on the mailing list. The idea is about making branches in darcs. Right now, we take the view that a darcs branch is a darcs repository plain and simple. If you want to create a branch, all you have to do is darcs get (darcs get --lazy to be faster). While this is very simple, a lot of us think that it's inconvenient (one because it's slow, and two because you have to think of where to put the branch). So darcs users have been asking about in-repo branches for a while. And now, Max has come up with a way to implement them. What's nice about his approach is that it lets us keep the simplicity of darcs, while giving more demanding users a chance to work with branches. It also takes advantage of the Petr Ročkai's Summer of Code project to make darcs faster in our daily lives and for the matter, paves the way for a possible darcs plugin system in the future. On Max's advice, I'm cross-posting to Haskell Cafe. Haskellers: here's a nice chance for you get a cool Darcs feature without not very much effort or Darcs hacking experience :-) More info on: http://bugs.darcs.net/issue555 Max's write-up Here's a quick primer: Basically, darcs = 2.0 uses a hashed pristine store that acts as a file object cache. An interesting artifact of the pristine.hashed store, which is being pushed into a useful third-party accessible library named hashed-storage, however, is that it does (for many reasons, most co-evolutionary) resemble the git object store. There are several differences, but one of the key differences that applies to the topic at hand is that darcs generally garbage collects pristine.hashed objects much faster than git. Darcs is very quick to garbage collect old objects partly because many aren't all that useful, but mostly because the primary representation for a repository state is the patch store (and inventory), so there is only one root pointer in the pristine store. Petr, the author of the hashed-storage library, briefly discusses this in his most recent design post about the future of hashed-storage: http://mornfall.net/blog/designing_storage_for_darcs.html Here's where the primer meets the topic at hand: A darcs branch consists of three major components: an inventory store, a patch store, and a pristine store. To store multiple branches in the same place you need to take care of: 1) storing the alternate inventories, and 2) if you want it to be relatively fast, storing additional objects in the pristine store. (The patch store will already happily hold more patches than are referenced in the current inventory.) (1) is mostly a matter of naming alternate inventories and swapping between them. Thanks to the *ahem* git-like nature of pristine.hashed/hashed-storage: darcs could easily archive (many) more pristine objects, than it will during normal operation, in pristine.hashed and it may be as simple as storing additional, useful root pointers visible to hashed-storage so that it knows not to garbage collect the objects from other branches. Here's where the fun happens: It seems to me that a branch switching tool, utilizing darcs' existing repository data stores, could be built almost purely on top of mostly just the hashed-storage library (which has been designed for reuse), as it exists today or hopefully with only minor tweaking, and with only minimal interaction with darcs itself. That is, in-repo branching could be provided entirely, today or soon, as a second/third-party tool to darcs. (!) I think this is great from a darcs perspective: darcs itself remains conceptually simple (1 repository == 1 branch), which is something that I for one love about darcs, and doesn't need additional commands in darcs iteslf. But yet, power users (and git escapees) would have easy access to a ``darcs-branch`` tool that provides simple and powerful in-repo switching. Potentially, such a tool is also a great candidate to be an earlier adopter for the darcs library support and can help better define and enhance darcs' public API. (It's also interesting in that it mirrors that hg's support for branches is an addon, and that both hg and git have darcs-like patch queues as addons.) I think this is even better from a hashed-storage perspective: ``darcs-branch`` would be a strong (new) use case for hashed-storage as a public API. The tool would provide good incentive to keep hashed-storage's API clean, and better incentive (than darcs' normal operation) to keep hashed-storage's garbage collection and object compaction strong. (With the 'cheap' cost of in-repo branches primarily a consequence of how well hashed-storage stores the additional objects of multiple branches. As a bonus, normal darcs operations should benefit as well from the gc/compaction optimizations that
Re: [Haskell-cafe] cheap in-repo local branches (just needs implementation)
I like it. git branches are nice to work with, and they don't the conceptual pain of creating an new repository. Things that make them nice: * When switching branches, all your files magically update (if they have not been modified). * Easy to maintain multiple branches, say stable and experimental. That helps me avoid getting clobbered by other's changes to APIs I depend on. Things that are a pain: * Comparing commits (patches) between branches. Its hard to tell what is one and what is in another. * When you have modified files, git is super picky about switching branches. * Once a remote branch is pushed to a public repo, its scary to remove it. You don't want to break somebody, but you don't want that old junk hanging around either. I don't mean to write about git, but if darcs was to have branches, thats the kind of stuff I would love to see. On Tue, Jul 21, 2009 at 2:23 PM, Eric Kowko...@darcs.net wrote: Hi everyone, Max Battcher had an idea that I thought I should post on the mailing list. The idea is about making branches in darcs. Right now, we take the view that a darcs branch is a darcs repository plain and simple. If you want to create a branch, all you have to do is darcs get (darcs get --lazy to be faster). While this is very simple, a lot of us think that it's inconvenient (one because it's slow, and two because you have to think of where to put the branch). So darcs users have been asking about in-repo branches for a while. And now, Max has come up with a way to implement them. What's nice about his approach is that it lets us keep the simplicity of darcs, while giving more demanding users a chance to work with branches. It also takes advantage of the Petr Ročkai's Summer of Code project to make darcs faster in our daily lives and for the matter, paves the way for a possible darcs plugin system in the future. On Max's advice, I'm cross-posting to Haskell Cafe. Haskellers: here's a nice chance for you get a cool Darcs feature without not very much effort or Darcs hacking experience :-) More info on: http://bugs.darcs.net/issue555 Max's write-up Here's a quick primer: Basically, darcs = 2.0 uses a hashed pristine store that acts as a file object cache. An interesting artifact of the pristine.hashed store, which is being pushed into a useful third-party accessible library named hashed-storage, however, is that it does (for many reasons, most co-evolutionary) resemble the git object store. There are several differences, but one of the key differences that applies to the topic at hand is that darcs generally garbage collects pristine.hashed objects much faster than git. Darcs is very quick to garbage collect old objects partly because many aren't all that useful, but mostly because the primary representation for a repository state is the patch store (and inventory), so there is only one root pointer in the pristine store. Petr, the author of the hashed-storage library, briefly discusses this in his most recent design post about the future of hashed-storage: http://mornfall.net/blog/designing_storage_for_darcs.html Here's where the primer meets the topic at hand: A darcs branch consists of three major components: an inventory store, a patch store, and a pristine store. To store multiple branches in the same place you need to take care of: 1) storing the alternate inventories, and 2) if you want it to be relatively fast, storing additional objects in the pristine store. (The patch store will already happily hold more patches than are referenced in the current inventory.) (1) is mostly a matter of naming alternate inventories and swapping between them. Thanks to the *ahem* git-like nature of pristine.hashed/hashed-storage: darcs could easily archive (many) more pristine objects, than it will during normal operation, in pristine.hashed and it may be as simple as storing additional, useful root pointers visible to hashed-storage so that it knows not to garbage collect the objects from other branches. Here's where the fun happens: It seems to me that a branch switching tool, utilizing darcs' existing repository data stores, could be built almost purely on top of mostly just the hashed-storage library (which has been designed for reuse), as it exists today or hopefully with only minor tweaking, and with only minimal interaction with darcs itself. That is, in-repo branching could be provided entirely, today or soon, as a second/third-party tool to darcs. (!) I think this is great from a darcs perspective: darcs itself remains conceptually simple (1 repository == 1 branch), which is something that I for one love about darcs, and doesn't need additional commands in darcs iteslf. But yet, power users (and git escapees) would have easy access to a ``darcs-branch`` tool that provides
Re: [Haskell-cafe] Implicit concatenation in list comprehensions
On Tue, Jul 21, 2009 at 12:29:18PM -0700, Dan Weston wrote:
This would mean that
[ | c ] = concat $ do { c; return [] }
The right is legal Haskell and gives []. The left is (not yet)
legal. Should it be?
Please, please, do not allow that.
People wanting [] should write [].
Thanks!
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] System.Mem.performGC leaks?
main = forever performGC The OS reported memory usage skyrockets. If i enable +RTS -S the GC statistics show the heap live bytes being constant. Is it accumulating statistics even when profiling is disabled (and can you turn that off), or is there something going on with the FFI call to performGC. Compiled with ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields -threaded btw. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: System.Mem.performGC leaks?
Neal Alexander wrote: Compiled with ghc -O2 -fvia-C -optc-O2 -funbox-strict-fields -threaded btw. GHC 6.10.3 on 64bit windows7. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Simple quirk in behavior of `mod`
Hello haskell-cafe; I'm fiddling with thishttp://cdsmith.wordpress.com/2009/07/20/calculating-multiplicative-inverses-in-modular-arithmetic/blog post about inverting elements of Z/(p), trying to write the inversion function in pointfree style. This led me to try executing statements like n `mod` 0 which in the ring theoretic sense should be n, at least for integers*. (MathWorld agrees. http://mathworld.wolfram.com/Congruence.html) But Hugs gives a division by zero error! I'm more of a recreational haskell user and not too familiar with how the Prelude works. But I dug around a bit and saw this inGHC.Real: ( linkhttp://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-Real.html#mod ) a `mod` b | b == 0 = divZeroError | a == minBound b == (-1) = overflowError | otherwise = a `modInt` b Is there a reason why n `mod` 0 is undefined in Haskell? Maybe this has already been considered for Haskell' and I'm just unaware. I did some digging in the archives and this discussion http://markmail.org/message/5dmehw4lhu56x4zw#query:haskell%20%22%60mod%60%200%22+page:1+mid:7alg3hdlndapyxg6+state:results http://markmail.org/message/5dmehw4lhu56x4zw from 2002 is the most relevant one I could find; it is suggested there that n `mod` 0 should be an error. Thanks all- Nathan Bloomfield *- The mod function is defined in the Integral class, and I'm not even sure how to interpret that. It looks kind of like a Euclidean domain. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
Eric Kow ko...@darcs.net writes: [...] a branch switching tool, utilizing darcs' existing repository data stores, could be built [...] today [...] as a second/third-party tool to darcs. I heartily approve of this approach. In-repo branches are occasionally useful to me, but the pollution of the VCS' interface has always been a major turn-off. The proposed solution allows new users to start with a Darcs that has a one-to-one correspondence between repos and branches. When I give Darcs to someone who has been using tar(1) for version control, I do not need to explain up-front the difference between a branch and a repo. Later, when that user has developed VCS habits and is trusted to work on larger group projects, I can introduce the additional complexity of in- repo branching without overwhelming him. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
