- Haskell-Cafe - Haskell.org

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

Simple quirk in behavior of `mod`
by Nathan Bloomfield 22 Jul '09

22 Jul '09

Hello haskell-cafe; I'm fiddling with this<http://cdsmith.wordpress.com/2009/07/20/calculating-multiplicative-inverses…>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: ( link<http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-Real.htm…> ) > 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%2…> <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.

3 2

Re[2]: [Haskell] TABI 0.1: a typeful tagged cross-language calling convention
by Bulat Ziganshin 21 Jul '09

21 Jul '09

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, Bulat mailto:Bulat.Ziganshin@gmail.com

3 2

understanding HXT's insertChildrenAfter
by Jake 21 Jul '09

21 Jul '09

Playing on HXT 8.3.0 via cabal on GHC 6.10.2. While there are plenty of useful examples of extract data from XML, applying the appropriate API to transform and/or merging still baffle me. In this case, it is the insertChildrenAfter, let's try it with the following example: given 2 files --- update.xml <?xml version="1.0" encoding="UTF-8"?> <update> <hot>sky is now orange</hot> <hot>fish is fresh</hot> <hot>violets are blue</hot> </update> --- master.xml <?xml version="1.0" encoding="UTF-8"?> <news> <page1> <hot>sky is blue</hot> <hot>roses are red</hot> </page1> <page2> <story>game shipped on sunday</story> </page2> </news> with the intention of augment the master list with the new items: import Text.XML.HXT.Arrow import qualified Text.XML.HXT.DOM as DOM getMaster = readDocument [(a_validate,v_0)] "master.xml" >>> removeDocWhiteSpace getUpdate = readDocument [(a_validate,v_0)] "update.xml" >>> removeDocWhiteSpace selectUpdateArea = getChildren >>> hasName "news" >>> getChildren >>> hasName "page1" updateContent = insertChildrenAfter (selectUpdateArea) (getUpdate >>> getChildren >>> getChildren) main = do runX ( getMaster >>> updateContent >>> putXmlTree "-" ) instead the following tree is produced: ---XTag "/" | +---XTag "hot" | | | +---XText "sky is red" | +---XTag "hot" | | | +---XText "fish is fresh" | +---XTag "hot" | | | +---XText "violets are blue" | +---XTag "news" | +---XTag "page1" | | | +---XTag "hot" | | | | | +---XText "sky is blue" | | | +---XTag "hot" | | | +---XText "roses are red" | +---XTag "page2" | +---XTag "story" | +---XText "game shipped " Can someone give some examples of how insertChildrenAfter works? How about also some general guidelines when comes to merging/grafting XML documents. Jake

1 0

Pruning the Front Page
by Thomas DuBuisson 21 Jul '09

21 Jul '09

All, I think we should remove unmaintained or refocused implementations from the haskell.org front page. This would mean removing: YHC - unmaintained, hasn't built for me in a while LHC - Not a standalone compiler these days - perhaps should be linked as a GHC subproject? Other than those I'd propose NHC but I'm guessing that would get some pushback (even though it currently doesn't build for me). Before anyone brings up HUGS I'll just say that 1) it is used 2) it builds 3) at least it's been updated more recently than the Haskell langauge. Thomas

3 2

Ambiguous type variable - help!
by phil＠beadling.co.uk 20 Jul '09

20 Jul '09

Hi, I'm trying to work out how to handle a choice at runtime which determines what instance of a State monad should be used. The choice will dictate the internal state of the monad so different implementations are needed for each. I've concocted a very simple example to illustrate this (below) - but it doesn't compile because ghc complains that my type is ambiguous arising from my use of 'fromSeq'. I can kind-of see what the compiler is complaining about, I'm guessing because it is the internals of my type which dictate which state Monad to use and it can't know that? Thinking about it I tried making SeqType an instance of Sequence class, but had no luck here. I understand that haskell is static at compile time, so I'm looking for something like a template solution in C++ (rather than a virtual function style implementation). I see there are libraries out their which do this, but I was wondering in my simple example if there was a way of doing this without writing a load of boilerplate code in main (this would get ugly very quickly if you had loads of choices). If this is impossible does anyone have an example / advice of implementing simple template style code in Haskell? Any help or suggestions would be really appreciated. Many Thanks, Phil. Thus just implements a state Monad which counts up from 1 to 10, using either an Int or a Double depending on user choice. It's pointless of course, but illustrates my point. {-# LANGUAGE TypeSynonymInstances #-} import Control.Monad.State.Strict data SeqType = SeqDouble Double | SeqInt Int class SequenceClass a where nextSeq :: State a Int fromSeq :: SeqType -> a instance SequenceClass Int where nextSeq = State $ \s -> (s,s+1) fromSeq (SeqInt i) = i fromSeq _ = 0 instance SequenceClass Double where nextSeq = State $ \s -> (truncate s,s+1.0) fromSeq (SeqDouble d) = d fromSeq _ = 0.0 chooser :: String -> SeqType chooser inStr | inStr == "Double" = SeqDouble 1.0 | inStr == "Int" = SeqInt 1 | otherwise = SeqInt 1 main :: IO() main = do userInput <- getLine let result = evalState (do replicateM 10 nextSeq) $ fromSeq $ chooser userInput print result

2 2

Anglohaskell - wifi signups
by Philippa Cowderoy 20 Jul '09

20 Jul '09

Wifi signups are Anglohaskell are now on the wiki - please add your details by the 31st of July if you want a wifi account at MS Research for the Friday. Alternatively, reply to this email with your full name, institution, country of residence and email address. The Anglohaskell wiki page can be found at http://www.haskell.org/haskellwiki/AngloHaskell/2009 There's still room for more talks if anyone's got something they fancy giving a go - everything from cutting edge research to "what I did with Haskell on my holiday" is welcome, as is everyone from GHC implentors to newbies frantically writing Hello World on their laptop in the back row. -- flippa(a)flippac.org

1 0