July 2009 - Haskell-Cafe

is closing a class this easy?
by Conor McBride 23 Jul '09

23 Jul '09

Friends Is closing a class this easy? -------------------------------------- module Moo ( Public(..) ) where class Private x => Public x where blah :: ... class Private x where instance Private A where instance Public A where blah = ... instance Private B where instance Public B where blah = ... -------------------------------------- Modules importing Moo get Public and its instances, but cannot add new ones: any such instances must be accompanied by Private instances, and Private is out of scope. Does this work? If not, why not? If so, is this well known? It seems to be just what I need for a job I have in mind. I want a class with nothing but hypothetical instances. It seems like I could write -------------------------------------- module Noo ( Public(..) , public ) where class Private x => Public x where blah :: ... blah = ... class Private x where public :: (forall x. Public x => x -> y) -> y public f = f Pike data Pike = Pike instance Private Pike instance Public Pike -------------------------------------- But if I don't tell 'em Pike, I've ensured that blah can only be used in the argument to public. Or is there a hole? Cures youriously Conor

7 13

Mixing C and Haskell code in the same file
by Maurício 23 Jul '09

23 Jul '09

Is it possible to insert C code directly to, say, .hsc files? I see this construct in ghc user docs: #def ... which should insert definitions, but I could not find examples of usage in Hackage. My goal is to write some cpp macros that build both a C function and its 'foreign import ccall' wrapper in the same file. Thanks for your help, Maurício

4 5

ANN: Semantic Web
by Vasili I. Galchin 23 Jul '09

23 Jul '09

I. Swish-0.2.1(Semantic Web Inference uSing Haskell) is a semantic web toolkit designed and implemented by Graham Klyne - GK(a)ninebynine.org: 1) http://www.ninebynine.org/RDFNotes/Swish/Intro.html 2) http://www.ninebynine.org/Software/swish-0.2.1.html I am personally very excited about Graham's work and the role of Haskell in his toolkit! II.) My role I "cabalized" Swish-0.2.1, brought namespace issues up to 6.8.2 standards and fixed many compiler warnings. There are still numerous warnings mostly related to lack of function type signatures. Swish-0.2.1 however does build and the tests that Graham wrote do run ok. Currently Swish-0.2.1 is currently hosted on Hackage but will most likely move to another site in the future. The downloader will find that there are TBDs in the swish.cabal file and other places. Please be patient. Kind regards, Vasili

2 1

Implicit concatenation in list comprehensions
by Max Bolingbroke 22 Jul '09

22 Jul '09

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", " "] This is a generalisation of list comprehensions that allows several items to be concatenated onto the result list at once, by having several comma-separated items before the pipe. One situation where I have found this to be useful is when you are writing Haskell programs that call lots of external programs and you need to set the flags based on some tests, like so: rawSystem "myProgram" $ ["foo" | fooing_enabled] ++ ["bar1", "bar2" | baring_enabled] I have submitted a ticket to GHC HQ with the patch (http://hackage.haskell.org/trac/ghc/ticket/3380#comment:5) but as it is just a small convenience it most likely won't make it in unless there is more demand for the feature. So, now is the time to speak up in favour of (or indeed, against) the added syntax! All the best, Max P.S. I also implemented tuple sections (http://hackage.haskell.org/trac/ghc/ticket/3377#comment:3) which are a lot more useful: >>> (, True, "Hello", ) 1 "World" (1, True, "Hello", "World")

16 21

Re: cheap in-repo local branches (just needs implementation)
by Petr Rockai 22 Jul '09

22 Jul '09

Grant Husbands <darcsusers(a)grant.x43.net> writes: > The original note that I should have quoted was from Max Battcher: > : Additionally, there would be other useful management tools > : (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think > : that these four commands could be done with no darcs interaction at all > : (unless the branch being switched to has an incomplete/lazy pristine). Ah, OK. This is mistake on Max's part, since there's no such thing as incomplete/lazy pristine. I.e. this is a non-issue. > Overall, I'd say this just feeds back into my original point, though; > I fully expected that many points could be answered, and I think I can > raise more, given a bit of thought. (I won't unless I'm asked to, > though, as I'm trying to raise a useful point, not trying to wield > pedantry to kill a project.) Well, the problem with that point is that maybe half of your points were trivially untrue, which sort of puts a dent into the argument itself. :) > However, take even just the above into account and things are now more > complicated. We're no longer simply switching a pristine and an > inventory here and there, we're applying and unapplying patches for > the working copy (which is non-trivial if you want to get the contexts > correct), and rolling back on failure (something even Darcs has > historically had trouble with). We're extending the added GC roots to > include the full inventory chain (and whatever else comes up). We're > doing something interesting with a new kind of context to make patch > migration between branches work. I think it will become at least as > much work as it would take to implement the right mechanisms in Darcs > itself. No-one says it is going to be less or more work to do this within or outside of darcs. No doubt, some darcslib usage is quite likely (for patch application and unapplication, eg.). However, it is still relatively manageable, and in a limited form also relatively easy (but that's true of almost anything, the 80/20 rule). > There's also the strong possibility that the system would get mostly > implemented, with a few gotchas here and there and a few incomplete > features, and then there'd less impetus for writing a good, integral > branching system. You are probably overdoing the "integral" part of the equation, given that the only difference is administrative. You can import parts of darcs from outside of darcs just fine, these days. Anyway, the 80/20 problem is equivalently applicable to in-darcs as it is to out-of-darcs implementation. Yours, Petr.

1 0

Re: [darcs-users] cheap in-repo local branches (just needs implementation)
by Eric Kow 22 Jul '09

22 Jul '09

On Wed, Jul 22, 2009 at 16:48:39 +0100, Grant Husbands wrote: > Overall, I'd say this just feeds back into my original point, though; > I fully expected that many points could be answered, and I think I can > raise more, given a bit of thought. (I won't unless I'm asked to, > though, as I'm trying to raise a useful point, not trying to wield > pedantry to kill a project.) I think it's quite useful that you're doing this, thanks. The hope was to solicit discussion, after all! I'd particularly appreciate it if we could summarise any results from this on the bug tracker in the end http://bugs.darcs.net/issue555 > However, take even just the above into account and things are now more > complicated. We're no longer simply switching a pristine and an > inventory here and there, we're applying and unapplying patches for > the working copy (which is non-trivial if you want to get the contexts > correct), and rolling back on failure (something even Darcs has > historically had trouble with). We're extending the added GC roots to > include the full inventory chain (and whatever else comes up). We're > doing something interesting with a new kind of context to make patch > migration between branches work. I think it will become at least as > much work as it would take to implement the right mechanisms in Darcs > itself. Another option to consider: though this may be straying from the idea of implementing a standalone tool, but it seems that darcs-branch could outsource any clever bits to the Darcs library (and that we'd have to think carefully through extensions to the Darcs library and not just hashed-storage to make this work). -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

1 0

Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
by Kalman Noel 22 Jul '09

22 Jul '09

Thomas ten Cate schrieb: > There are two ways of looking at the mod operator (on integers): > > 1. As a map from the integers Z to Z/pZ. > [...] > 2. As the remainder under division by p. > Since n mod 0 would be the remainder under division by 0, this > correctly gives a division by zero error. > > I used to think that the definitions were equivalent... apparently not. They are if you don't disallow division by zero with remainder. Namely, the definition of “division with remainder” works as in (1).

1 0

what about adding a HIDE pragma ?
by Marc Weber 22 Jul '09

22 Jul '09

I know about module Foo ( exportedFuncA, ExportedType(..) ) where exportedFuncA :: .. exportedFuncA = .. data ExportedType = ExportedType It's great that you can only export a subset of all functions defined in a module. However this kind of declaration causes some work when merging branches etc. Its not a big deal but takes time. So does it make sense to add this information using pragmas? {-# HIDE logInfo, logError #-} logInfo :: Int -> String -> (Bool, Double) logInfo = logM INFO "this.module" logError :: Int -> String -> (Bool, Double) logInfo = logM ERROR "this.module" Adding a pragma like HIDE, EXPORT is only a small change but can make a big difference in everyday life ? Can template haskell add those pragmas as well? Marc Weber

3 3

Re: cheap in-repo local branches (just needs implementation)
by Petr Rockai 22 Jul '09

22 Jul '09

Hi, Grant Husbands <darcsusers(a)grant.x43.net> writes: > 1. When you unpull old patches or reorder patches, Darcs alters > existing patch files. This will break other branches that share the > same files. Not true, since the filenames are fully determined by the file content. Hashed repositories will just create a new file for the modified patch. > 2. Similarly, when you pull patches in different contexts, you end up > with slightly-different patches with the same name. Same as above. > 3. With enough unpulling on one branch, you probably break the root > for another branch, by removing the shared inventory behind the head. This can be addressed by a GC policy. It's probably not feasible with current darcs, but keeping around "root" pointers to inventories is not much different from keeping extra roots for pristine. > 4. Pushing and pulling between branches would be very hard to > implement without heavy Darcs involvement. The method in the proposal > will not work, as Darcs in either branch can't necessarily understand > the context produced by the other branch. I'm not sure I follow your argument here. The proposed thing is the exact mechanism behind "darcs push" -- grab context of remote repository, commute patches you have to a common point and create a bundle, then use apply on that bundle... > 5. Updating the working copy correctly for many branch operations > entails knowing how to handle all of the darcs patches that are > different between the branches. Even if you force the user to have no > working copy changes, what about the unversioned extra files, > especially in renamed folders? The "switch" problem wouldn't be any easier whether implemented inside or outside of darcs. This basically entails unapplying patches up to a common point and then applying missing ones. This may or may not work, depending on how much changed the working copy is. I presume we would abort without doing any changes may this break. > 6. As noted in the proposal, it's not known how to make it play nicely > with lazy fetching. I don't expect any problems here. I also don't see the original note? > 7. The branch-knowledge synchronisation requires almost as much > knowledge about how to handle remote Darcs repos as Darcs has. This is likely true. Yours, Petr.

1 0

cheap in-repo local branches (just needs implementation)
by Eric Kow 22 Jul '09

22 Jul '09

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 darcs-branch operations may make more obvious.) At a high-level, a ``darcs-branch`` tool would provide core commands to: 1) Store the current repository state as a new branch by copying the current inventory and inserting a new pristine root for the branch. (``darcs-branch new`` or ``darcs-branch freeze``, perhaps) 2) Switch to a previously stored branch, by making the branch's inventory the new current inventory and the branch's pristine root the new current pristine root; updating the working directory as necessary. (``darcs-branch switch``) Additionally, there would be other useful management tools (``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think that these four commands could be done with no darcs interaction at all (unless the branch being switched to has an incomplete/lazy pristine). Useful commands that would need darcs interaction for patch management would be things like ``darcs-branch push`` to push patches between named branches (equivalent at a high level to ``darcs send -o new.dpatch --context branchB.context; darcs-branch switch branchB; darcs apply new.dpatch``), and ``darcs-branch obtain`` to obtain new in-repo local branches from an existing context file, remote/external-local repository, tag, or other matcher (that is, darcs get from one in-repo branch to a new one). I doubt that a ``darcs-branch get`` to download all of the branches other than "current" (or HEAD, if you prefer, or "main" as I prefer) of a remote repository would need any darcs interaction (downloading the inventories and then many/most/all of the pristine objects). We can bet that darcs' usual lazy patch-getting behavior should work out of the box even for multiple branches. Well, that's the general idea, at least. I believe that a willing volunteer and a bit of help from Petr could build such a tool "relatively quickly" and hopefully might even possibly work with today's darcs as it is. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9

6 6