Re: [Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
On Wed, Jul 22, 2009 at 4:40 AM, Trent W. Buckt...@cybersource.com.au wrote: 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. I went from nothing to using git, and I sincerely don't know what's overwhelming about repo branching. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
Ha, try branching and merging in SVN (it worse in CVS) :-) Git got beautiful branching. On 22/07/2009, at 4:46 PM, david48 wrote: On Wed, Jul 22, 2009 at 4:40 AM, Trent W. Buckt...@cybersource.com.au wrote: 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. I went from nothing to using git, and I sincerely don't know what's overwhelming about repo branching. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
On Wed, Jul 22, 2009 at 7:46 AM, david48dav.vire+hask...@gmail.com wrote: On Wed, Jul 22, 2009 at 4:40 AM, Trent W. Buckt...@cybersource.com.au wrote: 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. I went from nothing to using git, and I sincerely don't know what's overwhelming about repo branching. You just need to work with more clue-less people. It'll do _your_ head in trying to understand why they fail to understand VCS :-) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Simple quirk in behavior of `mod`
Nathan Bloomfield wrote: Hello haskell-cafe; I'm fiddling with this http://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) I agree that (n `mod` 0) ought to be n. Specifically divMod n 0 = (0,n) and quotRem n 0 = (0,n) In (divMod n m) the sign of the remainder is always the same as the sign of m, unless n or m is zero. In (quotRem n m) the sign of the quotient is the product of the signs of n and m, unless n or m is zero. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Implicit concatenation in list comprehensions
Bulat Ziganshin bulat.zigans...@gmail.com writes: 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 ] That looks good enough to convince me that new syntax gains too little here. When adding stuff to the syntax you have to be very careful about interactions between forms, and possible errors. The more you add, the more likely it is that something horrible gets overlooked. And learning haskell becomes more tedious (you have to learn stuff that you'd never use because other people will). Having a fairly small amount of flexible syntax (and Haskell is already pushing the boundaries of fairly small) together with powerful abstraction tools is far better than having a syntax so huge that no-one can see how weak the abstractions are... I keep trying, but I don't think I can finish this posting without mentioning Perl, whose aficionados have so much investment in having learned all that crap that they can't see how awful it is. -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
There are two ways of looking at the mod operator (on integers):
1. As a map from the integers Z to Z/pZ.
Then n mod p is defined as:
n mod p = { k | k in Z, k = n + ip for some i in Z }
Instead of the set, we ususally write its smallest nonnegative
element. And yes, in that sense, Z/0Z gives:
n mod 0 = { k | k in Z, k = n } = { k } =~ k
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.
Thomas
On Wed, Jul 22, 2009 at 10:05, Chris
Kuklewiczhask...@list.mightyreason.com wrote:
Nathan Bloomfield wrote:
Hello haskell-cafe;
I'm fiddling with this
http://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)
I agree that (n `mod` 0) ought to be n. Specifically
divMod n 0 = (0,n)
and
quotRem n 0 = (0,n)
In (divMod n m) the sign of the remainder is always the same as the sign
of m, unless n or m is zero. In (quotRem n m) the sign of the quotient
is the product of the signs of n and m, unless n or m is zero.
--
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: cheap in-repo local branches (just needs implementation)
On Wed, Jul 22, 2009 at 9:41 AM, Magnus Therningmag...@therning.org wrote: On Wed, Jul 22, 2009 at 7:46 AM, david48dav.vire+hask...@gmail.com wrote: I went from nothing to using git, and I sincerely don't know what's overwhelming about repo branching. You just need to work with more clue-less people. It'll do _your_ head in trying to understand why they fail to understand VCS :-) I have the luck to work for a factory where we are only 3 people involved with coding, and most of the time on separate stuff :) David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] what about adding a HIDE pragma ?
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
___
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)
Hi, Grant Husbands darcsus...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what about adding a HIDE pragma ?
Hello Marc, Wednesday, July 22, 2009, 4:28:49 PM, you wrote: So does it make sense to add this information using pragmas? pragmas shouldn't change program behavior or alter whether program may be compiled of course, LANGUAGE pragmas violate this law, but is considered as bug in Haskell developments rather than welcomed feature -- 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] what about adding a HIDE pragma ?
On 22 Jul 2009, at 14:53, Bulat Ziganshin wrote: Hello Marc, Wednesday, July 22, 2009, 4:28:49 PM, you wrote: So does it make sense to add this information using pragmas? pragmas shouldn't change program behavior or alter whether program may be compiled of course, LANGUAGE pragmas violate this law, but is considered as bug in Haskell developments rather than welcomed feature Why shouldn't they? I'm not particularly in support of this idea -- it makes it less clear what is being exported by the module, but I don't get your reasoning. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] what about adding a HIDE pragma ?
Hello Thomas, Wednesday, July 22, 2009, 5:08:15 PM, you wrote: Why shouldn't they? I'm not particularly in support of this idea -- it makes it less clear what is being exported by the module, but I don't get your reasoning. pragmas supposed to be some hints to compiler helping it to improve speed or debugging. program semantic shouldn't be altered when all pragmas are stripped off. otherwise, we are easily lose difference between pragmas and language itself -- 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] Re: Simple quirk in behavior of `mod`
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). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implicit concatenation in list comprehensions
Speaking as a perl programmer I find that a bit insulting. We do see how awful some of it is. perl4-perl5-perl6 have been as much about cleanup as adding functionality. And I would have thought this forum would have been more aware that after Audrey built the first perl6 interpreter basically overnight in Haskell that almost every perl aficionado around has looked at Haskell and many have learned it and that it's a major contributor to the design space of perl6. But then nobody beats a dead horse so I'll just keep laughing all the way to the bank on my perl programs. :) -ljr Jon Fairbairn wrote: Having a fairly small amount of flexible syntax (and Haskell is already pushing the boundaries of fairly small) together with powerful abstraction tools is far better than having a syntax so huge that no-one can see how weak the abstractions are... I keep trying, but I don't think I can finish this posting without mentioning Perl, whose aficionados have so much investment in having learned all that crap that they can't see how awful it is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Generalizing takeWhile
I need to take some elements from the front of a list. However the criteria are somewhat complex. walk f [] = [] walk f (x:xs) = case f x of Just g - x : walk g xs Nothing - [] For each item the `predicate' f either returns Nothing, when it thinks we should not take any more elements, or return Just another `predicate' to apply to the next element. However the type system does not like my function. How can I mollify it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [darcs-users] cheap in-repo local branches (just needs implementation)
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 signature.asc Description: Digital signature ___ 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)
Grant Husbands darcsus...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
On Wed, Jul 22, 2009 at 06:00:38PM +0200, Matthias Görgens wrote:
] I need to take some elements from the front of a list. However the
] criteria are somewhat complex.
]
] walk f [] = []
] walk f (x:xs) = case f x
] of Just g - x : walk g xs
] Nothing - []
]
] For each item the `predicate' f either returns Nothing, when it thinks
] we should not take any more elements, or return Just another
] `predicate' to apply to the next element.
]
] However the type system does not like my function. How can I mollify it?
It's actually simple! The problem is the type of 'f' would be
type TypeOfF a = a - Maybe (TypeOfF a)
However, this type synonym isn't valid for the obvious reason (it
is infinite, I don't remember the correct name). Data types,
on the other hand, may be recursive.
type TypeOfF a = a - Maybe (TypeOfF' a)
newtype TypeOfF' a = F {unF :: TypeOfF a}
and you may write your function as
walk :: TypeOfF a - [a] - [a]
walk _ [] = []
walk f (x:xs) = case f x of
Just g - x : walk (unF g) xs
Nothing - []
Some test predicates
takeN :: Num a = a - TypeOfF b
takeN 0 = const Nothing
takeN n = const . Just . F . takeN $ n-1
zigZag :: (a - Bool) - TypeOfF a
zigZag p = go True
where go b x | p x == b = Just . F $ go (not b)
| otherwise = Nothing
--
Felipe.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
2009/7/22 Matthias Görgens matthias.goerg...@googlemail.com I need to take some elements from the front of a list. However the criteria are somewhat complex. walk f [] = [] walk f (x:xs) = case f x of Just g - x : walk g xs Nothing - [] For each item the `predicate' f either returns Nothing, when it thinks we should not take any more elements, or return Just another `predicate' to apply to the next element. However the type system does not like my function. How can I mollify it? At a quick glance it looks to me like the type of f is infinite. Something like: f :: a - Maybe (a - Maybe (a - ...)) When I've seen people solve similar problems in the past they have introduced a data type to hide the infinite type. See for example, the solution to defining fix: http://blog.plover.com/prog/springschool95-2.html I didn't actual read that article, but it appears to explain the technique. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
Thanks to Jason and Felipe. I'll try that approach. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
Felipe Lessa wrote:
On Wed, Jul 22, 2009 at 06:00:38PM +0200, Matthias Görgens wrote:
] I need to take some elements from the front of a list. However the
] criteria are somewhat complex.
]
] walk f [] = []
] walk f (x:xs) = case f x
] of Just g - x : walk g xs
] Nothing - []
]
] For each item the `predicate' f either returns Nothing, when it thinks
] we should not take any more elements, or return Just another
] `predicate' to apply to the next element.
]
] However the type system does not like my function. How can I mollify it?
It's actually simple! The problem is the type of 'f' would be
type TypeOfF a = a - Maybe (TypeOfF a)
However, this type synonym isn't valid for the obvious reason (it
is infinite, I don't remember the correct name). Data types,
on the other hand, may be recursive.
type TypeOfF a = a - Maybe (TypeOfF' a)
newtype TypeOfF' a = F {unF :: TypeOfF a}
Another way to do it is to use an alternative to Maybe, defined like this:
data MaybeFun a = NoFun | Fun (a - MaybeFun a)
...which gives this definition for walk:
walk :: (a - MaybeFun a) - [a] - [a]
walk f [] = []
walk f (x:xs) = case f x
of Fun g - x : walk g xs
NoFun - []
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
Matthias Görgens matthias.goerg...@googlemail.com writes: Thanks to Jason and Felipe. I'll try that approach. http://www.nabble.com/There%27s-nothing-wrong-with-infinite-types!-td7713737.html Which explains the problem. -- aycan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
What is the use case(s) for this function? lements from the front of a list. However the criteria are somewhat complex. walk f [] = [] walk f (x:xs) = case f x of Just g - x : walk g xs Nothing - [] For each item the `predicate' f either returns Nothing, when it thinks we should not take any more elements, or return Just another `predicate' to apply to the next element. However the type system does not like my function. How can I mollify it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Simple quirk in behavior of `mod`
Is the utility of having (n `mod` 0) return a value greater than the confusion it will engender? In the 99.99% case it's an error. You wouldn't want (n `div` 0) to return 0, I expect.If we want these number-theoretic mod and div operations let's please put them in a separate module. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Implicit concatenation in list comprehensions
It was the perl community that brought me to haskell - by their interesting choice of implementation language for Pugs - and I'm grateful to them for this among other things! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implicit concatenation in list comprehensions
Hello Simon, Wednesday, July 22, 2009, 11:47:17 PM, you wrote: It was the perl community that brought me to haskell - by their interesting choice of implementation language for Pugs - for me, Pugs development tale is Beast and Beauty of programming world :) -- 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] ANN: Semantic Web
I. Swish-0.2.1(Semantic Web Inference uSing Haskell) is a semantic web toolkit designed and implemented by Graham Klyne - g...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
On Wed, Jul 22, 2009 at 1:34 PM, gladst...@gladstein.com wrote: Is the utility of having (n `mod` 0) return a value greater than the confusion it will engender? In the 99.99% case it's an error. You wouldn't want (n `div` 0) to return 0, I expect. If we want these number-theoretic mod and div operations let's please put them in a separate module. Couldn't the same be said for round-to-even, instead of rounding down like every other language? I doubt any beginners have ever expected it, but it's probably better. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
What is the use case(s) for this function? I often want to take one more element than takeWhile does, or only start checking the predicate after taking the first element for sure. Or both. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Simple quirk in behavior of `mod`
Couldn't the same be said for round-to-even, instead of rounding down like every other language? I doubt any beginners have ever expected it, but it's probably better. What do you mean with round-to-even? For rounding down there's floor. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Generalizing takeWhile
On Thu, Jul 23, 2009 at 07:28:55AM +0200, Matthias Görgens wrote: ] I often want to take one more element than takeWhile does, or only takeWhileMore n p x | p x = Just . F $ takeWhileMore n p | otherwise = Just . F $ takeN n ] start checking the predicate after taking the first element for sure. plusFirst = const . Just . F ] Or both. both = plusFirst . takeWhileMore 1 :) -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Semantic Web
I'd like to thank Vasili for resurrecting this project, which I thought had all-but-died for lack of nurture (the day job, etc.). It's really nice to know that, when (I hope!) the day comes that I want to pick up my Haskell work again, it won't have completely been left behind by the many exciting developments in the Haskell platform. When I have just a little time, I'd like to help move the code into a suitable open repository. Many thanks! #g -- Vasili I. Galchin wrote: I. Swish-0.2.1(Semantic Web Inference uSing Haskell) is a semantic web toolkit designed and implemented by Graham Klyne - g...@ninebynine.org mailto:g...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
