Re: [Haskell-cafe] Mystery of an Eq instance
Sure. An interesting, if not terribly relevant, fact is that there are more irrational numbers that we *can't* represent the above way than that we can (IIRC). However, those aren't actually interesting in solving the kinds of problems we want to solve with a programming language, so it's academic, and symbolic representation certainly gains you some things and costs you some things in meaningful engineering kinds of ways. On Sat, Sep 21, 2013 at 9:41 AM, Brandon Allbery allber...@gmail.comwrote: On Sat, Sep 21, 2013 at 12:35 PM, Bardur Arantsson s...@scientician.netwrote: On 2013-09-20 18:31, Brandon Allbery wrote: [--snip--] unless you have a very clever representation that can store in terms of some operation like sin(x) or ln(x).) I may just be hallucinating, but I think this is called describable numbers, i.e. numbers which can described by some (finite) formula. Not sure how useful they would be in practice, though :). I was actually reaching toward a more symbolic representation, like what Mathematica uses. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ 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] Mystery of an Eq instance
I think that's right, yeah. On Sat, Sep 21, 2013 at 9:49 AM, Brandon Allbery allber...@gmail.comwrote: On Sat, Sep 21, 2013 at 12:43 PM, David Thomas davidleotho...@gmail.comwrote: Sure. An interesting, if not terribly relevant, fact is that there are more irrational numbers that we *can't* represent the above way than that we can (IIRC). I think that kinda follows from diagonalization... it does handle more cases than only using rationals, but pretty much by the Cantor diagonal argument there's an infinite (indeed uncountably) number of reals that cannot be captured by any such trick. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: New syntax for Haskell
Honestly, I've not. Worth looking at, probably. On Thu, Sep 12, 2013 at 3:42 PM, Bob Ippolito b...@redivi.com wrote: Have you tried AppleScript? I wouldn't say it's pleasant to use, but it's easy to read. On Thursday, September 12, 2013, David Thomas wrote: I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is fascinating and possibly useful. On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote: ** +1 Cucumber seems to be great if you mainly want to read your code over the telephone, distribute it via national radio broadcast, or dictate it to your secretary or your voice recognition software. You can program thus without having to use you fingers. You can lie on your back on your sofa, close your eyes, and utter your programs... We could have blind Haskell/Cucumber programming contests... Tons of new possiblilities... Strongly support this proposal. ;-) Andreas On 2013-09-10 22:57, Artyom Kazak wrote: On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote: I hope these jokes do not cause people to be afraid to post new ideas. Agreed. I would also like to clarify that my message was much more a joke on the incomprehensibility of legal acts than on the original proposal. By the way, I am pretty impressed with this piece of Cucumber description/code: Scenario: Mislav creates a valid task with an upload When I go to the Awesome Ruby Yahh task list page of the Ruby Rockstars project When I follow + Add Task And I fill in Task title with Ohhh upload And I follow Attachment When I attach the file features/support/sample_files/dragon.jpg to upload_file And I press Add Task And I wait for 1 second And I should see Ohhh upload as a task name I was much more sceptical when I had only seen the example in Niklas’s message. ___ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe -- Andreas Abel Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich http://www.tcs.informatik.uni-muenchen.de/~abel/ ___ 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] Proposal: New syntax for Haskell
I've long been interested in a scripting language designed to be spoken. Not interested enough to go about making it happen... but the idea is fascinating and possibly useful. On Thu, Sep 12, 2013 at 2:57 PM, Andreas Abel andreas.a...@ifi.lmu.dewrote: ** +1 Cucumber seems to be great if you mainly want to read your code over the telephone, distribute it via national radio broadcast, or dictate it to your secretary or your voice recognition software. You can program thus without having to use you fingers. You can lie on your back on your sofa, close your eyes, and utter your programs... We could have blind Haskell/Cucumber programming contests... Tons of new possiblilities... Strongly support this proposal. ;-) Andreas On 2013-09-10 22:57, Artyom Kazak wrote: On Wed, 11 Sep 2013 00:20:26 +0400, Thiago Negri evoh...@gmail.com wrote: I hope these jokes do not cause people to be afraid to post new ideas. Agreed. I would also like to clarify that my message was much more a joke on the incomprehensibility of legal acts than on the original proposal. By the way, I am pretty impressed with this piece of Cucumber description/code: Scenario: Mislav creates a valid task with an upload When I go to the Awesome Ruby Yahh task list page of the Ruby Rockstars project When I follow + Add Task And I fill in Task title with Ohhh upload And I follow Attachment When I attach the file features/support/sample_files/dragon.jpg to upload_file And I press Add Task And I wait for 1 second And I should see Ohhh upload as a task name I was much more sceptical when I had only seen the example in Niklas’s message. ___ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe -- Andreas Abel Du bist der geliebte Mensch. Theoretical Computer Science, University of Munich http://www.tcs.informatik.uni-muenchen.de/~abel/ ___ 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] deriving Data.HashTable - stack overflow
I do wish there was a compiler-checked way of specifying a minimum complete
definition.
On Thu, Aug 8, 2013 at 11:02 AM, Joey Adams joeyadams3.14...@gmail.comwrote:
On Thu, Aug 8, 2013 at 12:22 PM, Lyle Kopnicky li...@qseep.net wrote:
...
So I went to the Data.Hashable page and looked up examples on how to
derive a Hashable instance for my datatype:
http://hackage.haskell.org/packages/archive/hashable/latest/doc/html/Data-Hashable.html
The problem occurs even when using the sample code on the page:
{-# LANGUAGE DeriveGeneric #-}
import GHC.Generics (Generic)
import Data.Hashable
data Colour = Red | Green | Blue
deriving Generic
instance Hashable Colour
If I then type `hash Red` I get a stack overflow.
I am using the Haskell Platform, so I have hashable-1.1.2.5, but I notice
the docs are for hashable-1.2.0.10. If I install 1.2.0.10 though, other
code in my project breaks - seems like one part doesn't recognize the
instances from another part. So I'll stick with the platform version.
...
Generic support was added in hashable-1.2. Before then, the default
implementations for `hash` and `hashWithSalt` were written in terms of each
other:
hash = hashWithSalt defaultSalt
hashWithSalt salt x = salt `combine` hash x
Because you did not give an implementation for either of these, both
default implementations were used, leading to a loop.
___
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] Alternative name for return
2. This is the only way you can evaluate your pure value, and because of the monadic chaining, you cannot do it twice, you cannot re-evaluate it. I'm sure there is a sense in which this is true, but I'm not seeing it. How would you describe what's going on here? twice :: IO () - IO () twice x = x x main = twice $ putStrLn foo I would call that evaluating x twice (incidentally creating two separate evaluations of one pure action description), but I'd like to better see your perspective here. Regarding this issue generally, I feel like everyone's climbed on their particular war horses when someone sounded the PURITY trumpet, when *I don't think this is the kind of purity Applicative is talking about* - different things can be pure in different ways. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
Return is all about providing a value *when used transitively*. When used intransitively, it's about moving yourself. There's nothing about the latter sense that implies providing a value. Which is not to say Richard did not overstate the case - return needn't necessarily (in English) suggest providing a value would be more correct, but isn't that far from a charitable interpretation of what he'd said. On Wed, Aug 7, 2013 at 7:56 AM, Donn Cave d...@avvanta.com wrote: quoth Richard A. O'Keefe, ... If you're familiar with *English* rather than, say, the C family of programming languages, return isn't _that_ bad, there is certainly nothing about the word that suggests providing a value. The RFC822 headers of your email suggest that you use a Macintosh computer, so apart from the apparently disputable question of whether you're familiar with English, you have the same online dictionary as mine. Second definition: give, put, or send (something) back to a place or person, with examples she returned his kiss, usage from tennis and football, verdicts, etc. Third definition: yield or make a profit, fourth (re)elect a person or party. Return is all about providing a value, in English. When a term like return is used in a computer programming language in a sense that confounds any prior expectation based on English or other programming languages, that's the opposite of intuitive. It is what it is, and it's silly to talk about changing it at this point, but that doesn't mean that we have to turn the notion of intuitive on its head. Donn ___ 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] Dual-licensing the package on Hackage
One question is how much of a discovery/indexing role Hackage plays. There can be a tremendous difference in ease of obtaining a commercial license, and a restriction for things I can use in a proprietary project, once I pay enough seems like a legitimate use case. It also has some bearing on ease of contributing changes upstream - a project that is dual licensed will probably want well-documented transfer of ownership; a gpl only project may not. That said, I am less sure that Hackage needs to be the place to call that out. On Jul 30, 2013 2:51 AM, Vo Minh Thu not...@gmail.com wrote: Well, if you are willing to grant me a GPL license when I download your package through Hackage, GPL is accurate. Again you are not providing me with another license. Obtaining a commercial license should be seeked through other means, perhaps by sending you an email. I don't think Hackage should be used for making adverts, but I think it would be ok to state in the description of the package something along the lines of commercial licenses are available through example.com. 2013/7/30 David Sorokin david.soro...@gmail.com: Thanks Thu, I agree with you. Just I don't know what to write in the license field of the .cabal file: GPL or OtherLicense. The both choices seem correct to me and misleading at the same time. Cheers, David 30.07.2013, в 12:53, Vo Minh Thu написал(а): 2013/7/30 David Sorokin david.soro...@gmail.com: Hi, Cafe! Probably, it was asked before but I could not find an answer with help of Google. I have a library which is hosted on Hackage. The library is licensed under BSD3. It is a very specialized library for a small target group. Now I'm going to relicense it and release a new version already under the dual-license: GPLv3 and commercial. In most cases GPL will be sufficient as this is not a library in common sense. Can I specify the GPL license in the .cabal file, or should I write OtherLicense? I'm going to add the information about dual-licensing in the description section of the .cabal file, though. Although you can indeed license your software under different licences, in the case of your question it doesn't seem to be a concern with Hackage: The license displayed on Hackage is the one for the corresponding .cabal file (or at least I think it is). So you issue your new version with the changed license, the new version is available with the new license, the old versions are still available with the old license. Everything is fine. Now about the dual licensing. It seems it is again not a problem with Hackage: you are not granting through Hackage such a commercial license. I guess you provide it upon request (for some money). I.e. when I download your library from Hackage, I receive it under the terms of the BSD (or GPL) license you have chosen, not under a commercial license that I would have to receive through other means. Otherwise the semantic of the license field on Hackage would mean the library is available under such and such licenses, which are not granted to you when you download the library on Hackage. Only when you download the package you can actually find the licensing terms (e.g. in the LICENSE file). But this seems unlikely to me. Cheers, Thu ___ 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] Proposal: Non-recursive let
It strikes me as unlikely static analysis would be confused by shadowing. On Tue, Jul 23, 2013 at 12:37 PM, i c ivan.chol...@gmail.com wrote: let's consider the following: let fd = Unix.open ... let fd = Unix.open ... At this point one file descriptor cannot be closed. Static analysis will have trouble catching these bugs, so do humans. Disallowing variable shadowing prevents this. The two fd occur in different contexts and should have different names. On Tue, Jul 23, 2013 at 8:17 PM, Bardur Arantsson s...@scientician.netwrote: On 2013-07-22 17:09, i c wrote: Usage of shadowing is generally bad practice. It is error-prone. Hides obnoxious bugs like file descriptors leaks. These claims need to be substantiated, I think. (Not that I disagree, I just think that asserting this without evidence isn't going to convince anyone who is of the opposite mindset.) Regards, ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] memoization
I, for one, would love to have a compiler do (a) based on (b), my specification of (c), and the ability to pin particular things... On Mon, Jul 22, 2013 at 4:04 PM, wren ng thornton w...@freegeek.org wrote: On 7/22/13 9:06 AM, Tom Ellis wrote: On Mon, Jul 22, 2013 at 07:52:06PM +1200, Chris Wong wrote: A binding is memoized if, ignoring everything after the equals sign, it looks like a constant. In other words, these are memoized: [...] f = \x - x + 1 [...] and these are not: f x = x + 1 In what sense is the former memoised? I'm not aware of any difference between these two definitions. Consider rather, f1 = let y = blah blah in \x - x + y f2 x = let y = blah blah in x + y The former will memoize y and share it across all invocations of f1; whereas f2 will recompute y for each invocation. In principle, we could translate between these two forms (the f2 == f1 direction requires detecting that y does not depend on x). However, in practice, the compiler has no way to decide which one is better since it involves a space/time tradeoff which: (a) requires the language to keep track of space and time costs, (b) would require whole-program analysis to determine the total space/time costs, and (c) requires the user's objective function to know how to weight the tradeoff ratio. -- Live well, ~wren ___ 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] Wrapping all fields of a data type in e.g. Maybe
Oh, very nice. It seems reasonable to extend this to Cfg - IO Cfg to
support things like dynamically loading config files, if needed.
On Jul 16, 2013 5:42 PM, John Lato jwl...@gmail.com wrote:
The suggestion of parameterizing on a functor would be good, however
there's another approach I've often seen (although it's not quite what
you've asked for). You can leave your config datatype alone, but instead
of making it a monoid have your configuration parsers return functions with
the type (Cfg - Cfg). You can wrap these functions in Endo to get a
monoid, combine them together, and then apply that function to the default
configuration.
On Wed, Jul 17, 2013 at 4:57 AM, Michael Orlitzky mich...@orlitzky.comwrote:
I have a common pattern in my command-line programs; I start out with a
configuration data type, which over-simplified looks like:
data Cfg = Cfg { verbose :: Bool }
Now, there's usually a default configuration,
default :: Cfg
default = Cfg False
The user can override the defaults one of two ways, either via a config
file, or from the command-line. If both are specified, the command-line
takes precedence. The way I do this is with,
data OptionalCfg = OptionalCfg { verbose :: Maybe Bool }
And then I define I Monoid instance for OptionalCfg which lets me merge
two ofthem. Once the two OptionalCfgs are merged, I merge *that* with
the default Cfg.
This all works great, except that when there's 20 or so options, I
duplicate a ton of code in the definition of OptionalCfg. Is there some
pre-existing solution that will let me take a Cfg and create a new type
with Cfg's fields wrapped in Maybe?
___
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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comparing functions
On Thu, Jul 11, 2013 at 10:50 AM, Brandon Allbery allber...@gmail.comwrote: ... but functions don't have an Eq instance, and *can't* have one. Not a general one that's interesting. There are two Eq instances that'll compile for all functions (not that it's advisable): instance Eq ((-) a b) where (==) _ _ = True instance Eq ((-) a b) where (==) _ _ = False You can't get more interesting in the general case, because you can't inspect the arguments. If you are okay with distinguishing solely by application you can get a little more interesting: instance (Bounded a, Enum a, Eq b) = Eq ((-) a b) where f == g = all (\ x - f x == g x) [minBound .. maxBound] *Main () == () True *Main () == (||) False Though I'm still not sure I'd say it's a *good idea*... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] tangential request...
I haven't found a font that really works well for Nethack in a while... lemme know if anyone has suggestions :-P On Mon, Jun 24, 2013 at 10:26 AM, Bardur Arantsson s...@scientician.netwrote: On 06/24/2013 06:18 AM, Mark Lentczner wrote: Thanks all, I’ve got what I needed. Finally, 15% seem to be using horrid bitmap console fonts. _How can you stand to look at them?!?!_ (Don't worry, you'll have Plush soon enough...) I realize this is probably a bit tongue-in-cheek, but for my money nothing has beaten Terminus to date. In fact, few fonts even come close and most of them are bitmapped too. (It kind of sucks that it only has a few fixed sizes, but until we all get 600 dpi displays with paper-like contrast, it's probably staying as my font of choice. That, or radically improved hinting and and antialiasing.) Regards, ___ 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] Backward compatibility
I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where. The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that). This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces. On Fri, May 3, 2013 at 3:23 AM, Guy guytsalmave...@yahoo.com wrote: Ertugrul Söylemez wrote: Often demanded changes that may or may not happen in the future: * base: Make Functor a superclass of Monad. One of the two most commonly demanded change to the base library. Will break lots and lots of code. Reason: Would greatly simplify a lot of code. * base: Fix the numeric type classes. The other most commonly demanded change. Will break lots and lots of code, including most of the base library. Reason: Would make numeric code much more sensible and algebraic. That's what I thought of when I saw the original complaint - GHC is too backwards compatible! There's far too much boilerplate because of the Functor = Applicative = Monad mess. Float/Double being Enums is ridiculous. None of this gets fixed because of the fear that new GHC won't compile old code. Perhaps we need some system for maintainers to vote on whether they consider the value of a breaking change to be worth the effort of fixing their packages to work with it. In my own code, I usually find that this effort is minor, and I'm more than happy to do it in return for a better language/library. PS The proposal to fix Functor = Applicative = Monad has patches attached for GHC and base, but the backwards compatibility bogeyman always seems to trump something that will break a lot of code. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Backward compatibility
That's approximately what I was describing, yes. Thanks! On Fri, May 3, 2013 at 7:54 AM, Guy guytsalmave...@yahoo.com wrote: David Thomas wrote: I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where. The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that). This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces. http://hackage.haskell.org/**trac/ghc/wiki/**DefaultSuperclassInstanceshttp://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Backward compatibility
That's approximately what I was describing, yes. Thanks! On Fri, May 3, 2013 at 7:54 AM, Guy guytsalmave...@yahoo.com wrote: David Thomas wrote: I'd also like to see these two. It occurs to me there may be language tweak that could reduce breakage and add some convenience in both cases. It would not surprise me at all if this has been thought of, examined, and discarded, but I don't have time to dig so I'll just lay it out quickly, and if it has been discussed before someone will probably know where. The idea is to allow definitions of superclass operations in subclass instances. If there are such definitions, it's treated as if there were instances defined for each class (potentially a source translation, even). I think default definitions of superclass operations in the subclass would be used last (that is, only for the automatic instance of the superclass, and only if the superclass didn't have a default for that). This should allow existing instances of Num to just work (and I think Monad too, with some care). It would also mean if you're making something that's a Monad or a Num you could just lay out the one instance in all one place, reducing a bit of boilerplate. At the same time, you'd have the flexibility to just use the superclasses where you just want pieces. http://hackage.haskell.org/**trac/ghc/wiki/**DefaultSuperclassInstanceshttp://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances I'm surprised that the various superclass proposals haven't got more attention, seeing as it would allow for this kind of class hierarchy clean-up without breaking lots of code. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Backward compatibility
If you are actively using something then keep it up to date, encourage someone to keep it up to date, pay someone to keep it up to date, or migrate off of it. If you try building with a fresh set of packages every so often, you can catch breaking changes early and deal with them when it's typically pretty clear why things broke. On May 2, 2013 6:33 AM, Adrian May adrian.alexander@gmail.com wrote: So WASH is ancient history. OK, lets forget it. How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? That's how I spent my afternoon today, instead of getting on with my job. Now you might think I was silly not to have uninstalled the linux package first, but I tried, and then decided against it because it thought the entire OS depended on it and actually proposed to remove everything from clib to googleearth as a solution. It's not Haskell's fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it's better not to keep moving the furniture around. Why was I trying to build the Haskell Platform at all? Because it wasn't obvious to me that a 7 year old library would be doomed. I find it perfectly normal to be able to compile C code from the 1970s but still run STL through the same compiler. That's why I blamed the system instead of the library. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH in that long-forgotten era when Barack Obama was barely known, a Russian spy was poisoned with Polonium and a Sudanese man was ordered to marry a goat he was caught in an intimate position with, then I still see it that way. Adrian. On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote: John Lato jwl...@gmail.com wrote: I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity. I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today. Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing. Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake. I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users. With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ ___ 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 mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Haskel let
On Mon, Apr 1, 2013 at 9:32 AM, Richard Eisenberg e...@cis.upenn.edu wrote:
Normal let:
In a function (which does not use do), you can use let to make local
variables. The word in separates the local variable declaration from the
part of your function where you want to use that variable. Loosely
translating from Haskell to C++:
Haskell:
let foo = bar in baz
C++:
/* insert correct type here */ foo = bar;
baz
For the C++, I'd say
{
/* insert correct type here */ foo = bar;
baz
}
for let ... in, whereas let without in (only permitted in do notation)
discards those braces.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Overloading
If you add NoImplicitPrelude, I think you should also be able to do:
import Prelude hiding (Num)
import qualified Prelude (Num)
instance Num a = Plus a a where
type PlusResult a a = a
a + b = a Prelude.+ b
On Tue, Mar 12, 2013 at 2:24 PM, MigMit miguelim...@yandex.ru wrote:
On Mar 13, 2013, at 12:54 AM, Richard A. O'Keefe o...@cs.otago.ac.nz
wrote:
The interesting challenge here is that we should have
Date + Period - Date Date - Period - Date
Period + Date - Date Period - Date - ILLEGAL
Period + Period - DeriodPeriod - Period - Period
Date + Date - ILLEGAL Date - Date - Date
and _also_ (remember we are trying to beat C++ here) Int +/- Int - Int.
Well, an obvious suggestion would be to use MultiParamTypeClasses and
TypeFamilies:
{- LANGUAGE MultiParamTypeClasses, TypeFamilies -}
module Date where
import Prelude hiding (Num, (+))
data Date = Date
data Period = Period
class Plus a b where
type PlusResult a b
(+) :: a - b - PlusResult a b
instance Plus Date Period where
type PlusResult Date Period = Date
Date + Period = Date
instance Plus Period Date where
type PlusResult Period Date = Date
Period + Date = Date
instance Plus Period Period where
type PlusResult Period Period = Period
Period + Period = Period
But I suppose you've been thinking about Haskell98. That, I'm afraid,
doesn't seem possible.
___
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] ANN: Nomyx 0.1 beta, the game where you can change the rules
hash(id:secret) should not be reversible, if you use a cryptographic hash. hash(id) can be brute-forced, on something with so small a range. On Wed, Feb 27, 2013 at 11:20 AM, Corentin Dupont corentin.dup...@gmail.com wrote: hash is reversible or not? On Wed, Feb 27, 2013 at 8:18 PM, Clark Gaebel cgae...@uwaterloo.cawrote: You could just hash it. - Clark On Wed, Feb 27, 2013 at 2:08 PM, Corentin Dupont corentin.dup...@gmail.com wrote: So I need to encrypt the user ID in some way? What I need is to associate the user ID to a random number and store the association is a table? On Wed, Feb 27, 2013 at 3:52 PM, Erik Hesselink hessel...@gmail.comwrote: Note that cookies are not the solution here. Cookies are just as user controlled as the url, just less visible. What you need is a session id: a mapping from a non-consecutive, non-guessable, secret token to the user id (which is sequential and thus guessable, and often exposed in urls etc.). It doesn't matter if you then store it in the url or a cookie. Cookies are just more convenient. Erik On Wed, Feb 27, 2013 at 3:30 PM, Corentin Dupont corentin.dup...@gmail.com wrote: Yes, having a cookie to keep track of the session if something I plan to do. On Wed, Feb 27, 2013 at 3:16 PM, Mats Rauhala mats.rauh...@gmail.com wrote: The user id is not necessarily the problem, but rather that you can impose as another user. For this, one solution is to keep track of a unique (changing) user token in the cookies and use that for verifying the user. -- Mats Rauhala MasseR -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlEuFVQACgkQHRg/fChhmVMu3ACeLLjbluDQRYekIA2XY37Xbrql tH0An1eQHrLLxCjHHBQcZKmy1iYxCxTt =tf0d -END PGP SIGNATURE- ___ 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 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] performance question
(I'll be brief because my head is hurting, but please don't interpret that as an intent to offend) A few points: 1) Capture groups are all you need to do some meaningful interpretation of data; these were around long before perl. 2) Yacc is typically used in conjunction with lex, partly for (a) efficiency and partly for (b) ease of use (compared to writing out [a-z] as production rules). 3) I've actually used lex without yacc (well, flex without bison) when faced with dealing with a language that's regular (and easy enough to express that way - cf. an enormous finite subset of a context-free language). 2b is mostly irrelevant in Haskell, as Parsec already provides functions that can easily match the same things a regexp would. 2a, if it stands up to testing, is the best argument for ripping things apart in Haskell using a DFA. Parsec and cousins are efficient, but it's hard to beat a single table lookup per character. The questions are 1) is the difference enough to matter in many cases, and 2) is there a way to get this out of parsec without touching regexps? (It's not impossible that parsec already recognizes when a language is regular, although I'd be weakly surprised). On Thu, Feb 14, 2013 at 3:07 PM, wren ng thornton w...@freegeek.org wrote: On 2/13/13 11:18 PM, wren ng thornton wrote: On 2/13/13 11:32 AM, Nicolas Bock wrote: Since I have very little experience with Haskell and am not used to Haskell-think yet, I don't quite understand your statement that regexes are seen as foreign to Haskell-think. Could you elaborate? What would a more native solution look like? From what I have learned so far, it seems to me that Haskell is a lot about clear, concise, and well structured code. I find regexes extremely compact and powerful, allowing for very concise code, which should fit the bill perfectly, or shouldn't it? Regexes are powerful and concise for recognizing regular languages. They are not, however, very good for *parsing* regular languages; nor can they handle non-regular languages (unless you're relying on the badness of pcre). In other languages people press regexes into service for parsing because the alternative is using an external DSL like lex/yacc, javaCC, etc. Whereas, in Haskell, we have powerful and concise tools for parsing context-free languages and beyond (e.g., parsec, attoparsec). Just to be clear, the problem isn't that proper regexes are only good for regular languages (many files have regular syntax afterall). The problem is that regexes are only good for recognition. They're an excellent tool for deciding whether a given string is good or bad; but they're completely unsuitable for the task of parsing/interpreting a string into some structure or semantic response. If you've ever used tools like yacc or javaCC, one of the crucial things they offer is the ability to add these semantic responses. Parser combinator libraries in Haskell are similar, since the string processing is integrated into a programming language so we can say things like: myParser = do x - blah guard (p x) y - blargh return (f x y) where p and f can be an arbitrary Haskell functions. Perl extends on regular expressions to try and do things like this, but it's extremely baroque, hard to get right, and impossible to maintain. (N.B., I was raised on Perl and still love it.) And at some point we have to call into question the idea of regexes as an embedded DSL when we then turn around and try to have Perl be a DSL embedded into the regex language. One of the big things that makes regexes so nice is that they identify crucial combinators like choice and repetition. However, once those combinators have been identified, we can just offer them directly as functions in the host language. No need for a special DSL or special syntax. The big trick is doing this efficiently. Parser combinators were an academic curiosity for a long time until Parsec came around and made them efficient. And we've come a long way since then: with things like attoparsec, PEG parsing, and non-monadic applicative parsers (which can perform more optimizations because they can identify the structure of the grammar). The theory of regular expressions is indeed beautiful and elegant. However, it's a theory of recognition, not a theory of parsing; and that's a crucial distinction. Haskell is about clear, concise, and well-structured code; but to be clear, concise, and well-structured we have to choose the right tool for the job. -- Live well, ~wren __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] performance question
One way in which regexps are foreign to Haskell-think is that, if they break, they generally break at run-time. This could be ameliorated with template haskell, but a substantial portion of Haskell coders find that a smell itself. On Wed, Feb 13, 2013 at 8:32 AM, Nicolas Bock nicolasb...@gmail.com wrote: Since I have very little experience with Haskell and am not used to Haskell-think yet, I don't quite understand your statement that regexes are seen as foreign to Haskell-think. Could you elaborate? What would a more native solution look like? From what I have learned so far, it seems to me that Haskell is a lot about clear, concise, and well structured code. I find regexes extremely compact and powerful, allowing for very concise code, which should fit the bill perfectly, or shouldn't it? Thanks, nick On Wed, Feb 13, 2013 at 8:12 AM, Brandon Allbery allber...@gmail.comwrote: On Tue, Feb 12, 2013 at 11:32 PM, bri...@aracnet.com wrote: actualy native code compiler. Can't regex be done effectively in haskell ? Is it something that can't be done, or is it just such minimal effort to link to pcre that it's not worth the trouble ? PCRE is pretty heavily optimized. POSIX regex engines generally rely on vendor regex libraries which my not be well optimized; there is a native Haskell implementation as well, but that one runs into a different issue, namely a lack of interest (regexes are often seen as foreign to Haskell-think, so there's little interest in making them work well; people who *do* need them for some reason usually punt to pcre). -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ 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] performance question
I don't think you can do much about fails to match the input string - indeed, that's often desired behavior... and matches the wrong thing you can only catch with testing. The simplest place template haskell could help with is when the expression isn't a valid expression in the first place, and will fail to compile. If you're just validating, I don't think you can do better; in order to improve your confidence of correctness, your only option is testing against a set of positives and negatives. If you're capturing, you might be able to do a little better, if you are able to get some of that info into the types (number of capture groups expected, for instance) - then, if your code expects to deal with a different number of captured pieces than your pattern represents, it can be caught at compile time. If you're capturing strings that you intend to convert to other types, and can decorate regexp components with the type they're going to capture (which can then be quickchecked - certainly a pattern should never match and then fail to read, c), and if you are able to propagate this info during composition, you might actually be able to catch a good chunk of errors. Note that much of this works quite a bit different than most existing regexp library APIs, where you pass a bare string and captures wind up in some kind of list, which I expect is much of the reason no one's done it yet (so far as I'm aware). On Wed, Feb 13, 2013 at 8:43 AM, Nicolas Trangez nico...@incubaid.comwrote: On Wed, 2013-02-13 at 08:39 -0800, David Thomas wrote: One way in which regexps are foreign to Haskell-think is that, if they break, they generally break at run-time. This could be ameliorated with template haskell Care to elaborate on the ameliorate using TH part? I figure regexes would be mostly used to parse some runtime-provided string, so how could compile-TH provide any help? Nicolas ___ 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] performance question
The fact that parsec and attoparsec exist and can be pressed into service with reasonable performance (I think?) on tasks for which regexps are suitable is probably another big part of the reason no one's done it yet. I expect much of the plumbing would wind up looking a lot like those, actually. On Wed, Feb 13, 2013 at 9:43 AM, David Thomas davidleotho...@gmail.comwrote: I don't think you can do much about fails to match the input string - indeed, that's often desired behavior... and matches the wrong thing you can only catch with testing. The simplest place template haskell could help with is when the expression isn't a valid expression in the first place, and will fail to compile. If you're just validating, I don't think you can do better; in order to improve your confidence of correctness, your only option is testing against a set of positives and negatives. If you're capturing, you might be able to do a little better, if you are able to get some of that info into the types (number of capture groups expected, for instance) - then, if your code expects to deal with a different number of captured pieces than your pattern represents, it can be caught at compile time. If you're capturing strings that you intend to convert to other types, and can decorate regexp components with the type they're going to capture (which can then be quickchecked - certainly a pattern should never match and then fail to read, c), and if you are able to propagate this info during composition, you might actually be able to catch a good chunk of errors. Note that much of this works quite a bit different than most existing regexp library APIs, where you pass a bare string and captures wind up in some kind of list, which I expect is much of the reason no one's done it yet (so far as I'm aware). On Wed, Feb 13, 2013 at 8:43 AM, Nicolas Trangez nico...@incubaid.comwrote: On Wed, 2013-02-13 at 08:39 -0800, David Thomas wrote: One way in which regexps are foreign to Haskell-think is that, if they break, they generally break at run-time. This could be ameliorated with template haskell Care to elaborate on the ameliorate using TH part? I figure regexes would be mostly used to parse some runtime-provided string, so how could compile-TH provide any help? Nicolas ___ 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] ANN: monad-bool 0.1
I think it needs to be both places. I know when I'm searching, I often just go to google with site:hackage.haskell.org inurl:latest I would be likely to miss it if it were just in the cabal file (although in the modules it could be as simple as a note saying this is defunct - view the main page for an explanation of why). Alternatively, if there is much reasoning specific to a particular module it could certainly go there, while the cabal gets the overview... On Fri, Jan 25, 2013 at 3:23 PM, wren ng thornton w...@freegeek.org wrote: On 1/24/13 1:40 AM, Ertugrul Söylemez wrote: David Thomas davidleotho...@gmail.com wrote: We could even set up NotOnHackage: a package repository just like Hackage, except the packages are just documentation on why there is no such package. Implementation-wise it's just a wiki; but the idea is about how to organize the wiki. NotOnHackage should be organized and searchable similar to Hackage itself, so that people can look there when nothing looks promising on Hackage. Couldn't this be actually on hackage, so one search turns up what you want? Yes. There is no reason to put up a second Hackage for that one. Without changing anything in the current system, packages can just update their categories, so that they will be displayed below Defunct or something like that. This is fine, as only the categories of the latest version are significant. If you think this is a good idea, I will start with some of my packages. =) We've had package deprecation for a while, so the big trick IMO is the documentation. Good descriptions of why the package is defunct and suggestions on how people can do things better. If we're going to do it on Hackage itself, I think the big question is one of style: should the documentation be all in the cabal file (i.e., on the package description page, with no modules in the package); or should we put the documentation into modules? -- Live well, ~wren __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] ANN: monad-bool 0.1
Couldn't this be actually on hackage, so one search turns up what you want? On Jan 23, 2013 3:24 PM, wren ng thornton w...@freegeek.org wrote: On 1/23/13 3:00 AM, Alexander Kjeldaas wrote: If we step back, I think the lesson here is that Haskell libraries exist, but the concepts are far enough from what you expect to exist given background knowledge from another programming language. So what is actually needed is not monad-bool, but the equivalent documentation that makes a programmer which is not an expert in Haskell connect the dots like you did today. Definitely. We could even set up NotOnHackage: a package repository just like Hackage, except the packages are just documentation on why there is no such package. Implementation-wise it's just a wiki; but the idea is about how to organize the wiki. NotOnHackage should be organized and searchable similar to Hackage itself, so that people can look there when nothing looks promising on Hackage. -- Live well, ~wren ___ 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] Object Oriented programming for Functional Programmers
On Sun, Dec 30, 2012 at 1:27 PM, Brandon Allbery allber...@gmail.comwrote: [T]he Monad m = in the signature really means hey, compiler, pass me the appropriate implementation of Monad so I can figure out what I'm doing with this type m. It's not a built in table, it's a hidden parameter. Well, hidden - it *is* right there in the type signature still, it just doesn't *look* like an argument. It also might be optimized away in static cases (certainly, it *could* happen, whether does or is even worthwhile is another question). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] ghc and android
Couldn't that simply be simulated? On Mon, Dec 31, 2012 at 2:36 PM, Nathan Hüsken nathan.hues...@posteo.dewrote: That seems almost impossible, I would need an android device with unusual capacity. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))
Jon's suggestion sounds great.
The bike shed should be green.
That is all.
On Sun, Dec 30, 2012 at 4:44 PM, Petr P petr@gmail.com wrote:
Hi,
I also support Jon's proposal for standalone of { ... }. Seems to me
clearer and more useful than the special \case construct.
I suppose 'of { ... }' could be generalized to multiple arguments, so that
of (Just x) (Just y) - x ++ y
would create an anonymous function of type 'Maybe String - Maybe String
- String'.
Considering the recent thread about partial functions:
http://www.haskell.org/pipermail/haskell-cafe/2012-December/105445.html
we could have variants of 'of' to distinguish partial functions. For
example, we could have something like 'ofFull' that would require an
exhaustive list of patterns, and something like 'ofPart' that would instead
produce results of type 'Maybe something'. (Most likely we'd have to think
of better names for them.) For example:
ofPart [x] [y] - x ++ y
would be of type '[String] - [String] - Maybe String', returning
`Nothing` if one of the input isn't a 1-element list - an approach similar
to Scala's partial functions.
http://www.scala-lang.org/api/current/scala/PartialFunction.html
[Perhaps we could have 'of' to work both ways - if the list of patterns
would be exhaustive, the result would be pure. If it would be
non-exhaustive, the result would be 'Maybe something'. Of course 'case x of
...' would still work as now, not caring about exhaustiveness. But I'm not
sure if this wouldn't be too error prone.]
We could even generalize 'ofPart' to work with any Alternative instance so
that
ofPart [x] [y] - x ++ y
would be of type '(Alternative f) = [String] - [String] - f String'.
Matching patterns would return results using 'pure', non-matching 'empty',
and they would be all combined combined using |. 'empty' would be
returned if nothing matched. (Among other things, this could have some
interesting consequences when overlapping patterns would be applied to
'Alternative []'.) For example
fn = ofPart (Right 0) - 1
(Right x) - x
would produce (using today's syntax):
fn :: (Alternative f) = Either Bool Int - f Int
fn x = case x of { Right 0 - pure 1 ; _ - empty; } |
case x of { Right x - pure x ; _ - empty; } |
empty
Best regards,
Petr
2012/12/29 Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk
On Thu, Nov 29, 2012 at 05:49:53PM +, Jon Fairbairn wrote:
Ben Franksen ben.franksen at online.de writes:
just wanted to drop by to say how much I like the new lambda case
extension.
I use it all the time and I just *love* how it relieves me from
conjuring up
dummy variables, which makes teh code not only esier to write but
also to
read.
[...] should *definitely* go into Haskell'13.
[...]
To me it seems obvious that if we are going to do this [...] we should
do
it simply by making the case exp part of a case expression optional.
of {alts...}
and we would then describe
case e of {...}
as syntactic sugar for
(of {...}) (e)
My very belated and unsolicited layman's reply is that I am a strong
supporter of Jon's position. His suggestion is parsimonious and natural.
Without wishing to start the discussion again, I disagree that it is
bikeshedding. One lesson I learned from Haskell is that syntax is much
more
important than I previously realised.
Tom
___
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 mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Substituting values
Seems like the function is easy to define:
replaceIfEq a b c = if c == a then b else c
Then the above can be written
replaceIfEq Foo Bar value
Or the slightly more general (in exchange for slightly more verbosity at
the call site)
replaceIf p r a = if p a then r else a
replaceIf (== Foo) Bar value
On Fri, Dec 21, 2012 at 6:46 PM, Radical radi...@google.com wrote:
Sometimes I'll need something like:
if value == Foo then Bar else value
Or some syntactic variation thereof:
case value of { Foo - Bar; _ - value }
Is there a better/shorter way to do it? I'm surprised that it's more
complicated to substitute a value on its own than e.g. in a list, using
filter. Or perhaps I'm missing the right abstraction?
Thanks,
Alvaro
___
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] (L)GPL libraries Haskell/GHC
Strictly speaking this is correct, and probably there's no one who would miss the gotcha on the list, but for the sake of completeness: You can release the source only to people who you have provided the program, but *they* have the ability to redistribute it under the terms of the GPL. As discussed elsewhere, this seems to be a difference between the LGPL and GPL, when dealing with Haskell libraries. When using the LGPL, you must allow people to update the library, so must (in the absence of dynamic linking) provide the source, but you *may* prohibit redistribution of that source. (IANAL...) On Wed, Dec 12, 2012 at 5:11 AM, Joachim Breitner m...@joachim-breitner.dewrote: Also, if you want to sell the resulting program, you do not have to publish the source publicly, as long as you offer the source to your customers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Right. If either of the following hold, you should be able to carry on as you were (but double check with your lawyer): 1) The algorithm is borrowed but the code was not copied. In this case, copyright doesn't cover it, and the GPL is inapplicable. (Patents could conceivably be an issue, but no more so than if it was BSD code). 2) If you are not going to be distributing the code - either it is used for internal tools or in the backend of a networked service (which the GPL does not treat as distribution, as distinct from the AGPL). If a sizable chunk of actual code was copied, then the containers package would have to be GPL, and if you are using the library and distribute programs built with it then those programs must be GPL as well. On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu not...@gmail.com wrote: 2012/12/12 Dmitry Kulagin dmitry.kula...@gmail.com: Hi Cafe, I am faced with unpleasant problem. The lawyer of my company checked sources of containers package and found out that it refers to some GPL-library. Here is quote: The algorithm is derived from Jorg Arndt's FXT library in file Data/IntMap/Base.hs The problem is that FXT library is GPL and thus containers package can not be considered as BSD3. And it means that it can not be used in my case (closed source software). Is this logic actually correct and containers should be considered as GPL? The package is widely used by other packages and the only way I see right now is to fix sources to reimplement this functionality, which is not good option. GPL covers code, not algorithms. Beside, you can use GPL in closed-source code. GPL forces you to make the source available when you distribute the software, but if you don't distribute the software, there is nothing wrong to use GPL and not make your code available. HTH, IANAL, Thu ___ 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] containers license issue
Ah, that's more than we'd been told. If that is the case, then containers is in violation of the GPL (unless they got permission to copy that code, separately), and either must obtain such permission, be relicensed, remove/replace that code. On Wed, Dec 12, 2012 at 8:29 AM, Clark Gaebel cgae...@uwaterloo.ca wrote: It's not an algorithm. The source code of containers is derived from the source code of another library. - Clark On Wed, Dec 12, 2012 at 11:27 AM, Vo Minh Thu not...@gmail.com wrote: I'm not sure what your point is. Re-implementing an algorithm is not a copyright infringement (nor is a propagation of the original work). Algorithms are not covered by copyright. 2012/12/12 Clark Gaebel cgae...@uwaterloo.ca: I think this is a potential problem, but, obviously, IANAL. [1] According to the GPL: To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. and You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. and of course You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). I believe that this counts as propagation of the original work, since it would be considered infringement under applicable copyright law. Now, the wording in the GPL is a bit confusing on this point. I'm not sure if propagation requires that the BSD3 that containers is licensed under must remain in force, or the GPL on which the which is derived must remain in force. Does anyone else have better luck interpreting this? - Clark [1] Aside: Can we stop saying IANAL? Let's just all assume that, until proven otherwise, no one here is a lawyer. [2] Required Reading: http://www.gnu.org/licenses/gpl.html On Wed, Dec 12, 2012 at 11:00 AM, David Thomas davidleotho...@gmail.com wrote: Right. If either of the following hold, you should be able to carry on as you were (but double check with your lawyer): 1) The algorithm is borrowed but the code was not copied. In this case, copyright doesn't cover it, and the GPL is inapplicable. (Patents could conceivably be an issue, but no more so than if it was BSD code). 2) If you are not going to be distributing the code - either it is used for internal tools or in the backend of a networked service (which the GPL does not treat as distribution, as distinct from the AGPL). If a sizable chunk of actual code was copied, then the containers package would have to be GPL, and if you are using the library and distribute programs built with it then those programs must be GPL as well. On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu not...@gmail.com wrote: 2012/12/12 Dmitry Kulagin dmitry.kula...@gmail.com: Hi Cafe, I am faced with unpleasant problem. The lawyer of my company checked sources of containers package and found out that it refers to some GPL-library. Here is quote: The algorithm is derived from Jorg Arndt's FXT library in file Data/IntMap/Base.hs The problem is that FXT library is GPL and thus containers package can not be considered as BSD3. And it means that it can not be used in my case (closed source software). Is this logic actually correct and containers should be considered as GPL? The package is widely used by other packages and the only way I see right now is to fix sources to reimplement this functionality, which is not good option. GPL covers code, not algorithms. Beside, you can use GPL in closed-source code. GPL forces you to make the source available when you distribute the software, but if you don't distribute the software, there is nothing wrong to use GPL and not make your code available. HTH, IANAL, Thu ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
This may be overconfident - how does copyright law deal with translations in literature? Still, it certainly makes infringement less likely, and the earlier explicit statement that code was copied likely the result of confusion. On Dec 12, 2012 8:33 AM, Niklas Larsson metanik...@gmail.com wrote: The problem is that FXT library is GPL and thus containers package can not be considered as BSD3. And it means that it can not be used in my case (closed source software). Is this logic actually correct and containers should be considered as GPL? The package is widely used by other packages and the only way I see right now is to fix sources to reimplement this functionality, which is not good option. There is no copied code from FXT (which can be said with certainty as FXT is a C library), hence the there can be copyright issue. Niklas ___ 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] ANNOUNCE: tie-knot library
On Tue, Dec 11, 2012 at 5:35 PM, Brandon Allbery allber...@gmail.comwrote: (Oddly enough, GPL is not the only open source license.) There was no implication to the contrary. It was stated that BSD is a *weaker* license - this is true in the sense that it has fewer requirements (in particular, no copyleft) - and that strong copyleft licenses such as the GPL should be preferred as they do more to bolster the free software community. You can disagree with this claim (there are arguments both ways - delving into them is not my point here) but please try not to bring in straw men. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tie-knot library
Right. Like, if Linus hadn't bogged down the Linux kernel with the GPL license, it might have wound up as popular as BSD! Both dynamics go on, and the question is which is more likely to dominate in a given case (and cumulatively). On Tue, Dec 11, 2012 at 5:50 PM, Jonathan Fischer Friberg odysso...@gmail.com wrote: On Wed, Dec 12, 2012 at 2:26 AM, Ramana Kumar ramana.ku...@cl.cam.ac.ukwrote: Using the GPL (or a strong copyleft free license) strengthens the free software community of which I thought the Haskell community is a part (or at least intersects substantially). I don't think it strengthens the community. If someone wants to make a change a library, but not release the source, they cannot do that with GPL. The idea behind GPL is that then, the change is forced to be released - which would, as you say, strengthen the community. However, I think what would happen instead is that the person would simply not use the library in the first place. So in short: GPL does not make people become a part of the community - it pushes them away. Jonathan ___ 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] ANNOUNCE: tie-knot library
... and OS X and iOS are clearly a win for the FLOSS community? On Tue, Dec 11, 2012 at 6:07 PM, Alexander Solla alex.so...@gmail.comwrote: As a matter of fact, BSD is far more popular on the desktop than GPL. And has a huge share of the mobile market. Witness: OS X, iOS. And none of this has anything to do with Haskell. Petr can release *his* code with any license he wants. Some licenses fit into *this* ecosystem better than others. Suggestions have been made and we can all move on. On Tue, Dec 11, 2012 at 6:03 PM, David Thomas davidleotho...@gmail.comwrote: Right. Like, if Linus hadn't bogged down the Linux kernel with the GPL license, it might have wound up as popular as BSD! Both dynamics go on, and the question is which is more likely to dominate in a given case (and cumulatively). On Tue, Dec 11, 2012 at 5:50 PM, Jonathan Fischer Friberg odysso...@gmail.com wrote: On Wed, Dec 12, 2012 at 2:26 AM, Ramana Kumar ramana.ku...@cl.cam.ac.uk wrote: Using the GPL (or a strong copyleft free license) strengthens the free software community of which I thought the Haskell community is a part (or at least intersects substantially). I don't think it strengthens the community. If someone wants to make a change a library, but not release the source, they cannot do that with GPL. The idea behind GPL is that then, the change is forced to be released - which would, as you say, strengthen the community. However, I think what would happen instead is that the person would simply not use the library in the first place. So in short: GPL does not make people become a part of the community - it pushes them away. Jonathan ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tie-knot library
IANAL, but reviewing what others have written, it sounds like it may be possible to maintain *some* distinction between LGPL and GPL in Haskell, but it's a different distinction than with an LGPL shared library, so even if applicable it's certainly worth being aware of. It sounds (and I'd very much like clarification) like providing source of an application to users *without* license to redistribute, which can be built using an LGPL library, would be compliant - whereas if the library was GPL this would not be the case? On Tue, Dec 11, 2012 at 9:19 PM, wren ng thornton w...@freegeek.org wrote: On 12/11/12 9:30 PM, Ramana Kumar wrote: I wonder if this discussion has been had before in the Haskell community. If so, pointers to archives could be of interest. Indeed, the discussion has been had more than once. Alas, I'm too bogged for time to look up the archives at the moment. I'm glad to see that there are others who apparently share my concern about the fact that people are actively recommending that new libraries be licensed without copyleft. The big issue, and the reason for suggesting that people not use LGPL is a technical one. Namely that due to GHC's heavy inlining etc, the things distinguishing LGPL from GPL are no longer in force, and therefore using the LGPL license for your library is equivalent to using the full GPL license for your library. Given as using the full GPL is not usually people's intent, it's important to make people aware of this issue. And in so doing, we usually suggest the BSD license (or similar) as an alternative. Inevitably, however, after the details of this technical situation are discussed (often followed by a debate over the proper interpretation of the linking clauses of the GPL/LGPL), the thread then turns to arguments over the merits of various licenses... which eventually peters out when everyone is too upset to keep on with it, just as in every other free/open-source community. I don't mean to sound jaded, but I've been through the cycle more than a few times already. Perhaps this time someone'll mine the archives and set up a wiki highlighting the posts with insightful discussion (and insightful counterpoints) so we can direct people there for the next time... -- Live well, ~wren __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] Recursive timezone-loading function
https://github.com/dlthomas/tzcache A small bit of code, but seems likely to be useful enough that I figured I should share. I've a few notes/questions: 1) Does this already exist somewhere I missed? 2) It seems silly to make this its own library - any suggestions where it could be added? 3) Is the traverse-a-directory-and-populate-a-map pattern one worth abstracting? If so, where should that go? 4) Presently, it's a static cache entirely pre-loaded. This seems fine, as it's not a terribly huge amount of data, but it's worth noting. 5) Any comments on the code generally? Improvements? Complaints? Thanks, - David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Common function names for '(.) . (.)', '(.) . (.) . (.)' ...?
( . ) . ( . ) in particular seems to be a generalization of flip on - hopefully there's something cleaner and more general though. On Wed, Nov 21, 2012 at 9:43 AM, Daniel Trstenjak daniel.trsten...@gmail.com wrote: Greetings, Daniel ___ 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] Deriving settings from command line, environment, and files
Is there a library that provides a near-complete solution for this? I looked around a bit and found many (many!) partial solutions on hackage, but nothing that really does it all. In coding it up for my own projects, however, I can't help but feel like I must be reinventing the wheel. What I want is something that will process command line options (this seems to be where most packages are targetted), environment variables, and settings files (possibly specified in options), and override/default appropriately. Did I miss something? If not, I'd like to see about fixing the situation, but very much want to avoid the whole There were X libraries that didn't quite do it right; now there's X+1! thing. Are there any opinions as to which of the many libraries is likely the best starting point if I'm going to contribute to one of them? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] foldr (.) id
sum can be a verb, but yeah, product can't really, so it probably makes sense to follow the noun pattern if we're wanting to be consistent more than brief. and as a noun is unusual, but fwiw dictionary.com says that there's a noun sense that means conjunction in the logical sense, which is exactly what we're doing here. On Mon, Oct 29, 2012 at 1:12 PM, Sebastian Fischer m...@sebfisch.de wrote: (.)/compose is consistent with (+)/sum, (*)/product, ()/and, etc. (to) compose is a verb. composition would be consistent with sum and product. and doesn't fit, though. Sebastian ___ 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] Sparse records/ADTs
You've got a bunch of great answers, if there's no rhyme or reason to
which fields are missing.
If, on the other hand, they will tend to be present or absent in
groups, you could decompose your data-structure a bit, for fast
lookups, good space efficiency, and maybe even slightly more
interesting checks from the type system.
On Wed, Oct 24, 2012 at 3:08 AM, Jon Fairbairn
jon.fairba...@cl.cam.ac.uk wrote:
Is there a convenient way of handling a data structure with lots
of fields of different types that may or may not be filled in?
Something equivalent to
data D = D {a::Maybe A, b::Maybe B, c::Maybe C, …}
but with better space efficiency and a more convenient empty
object.
An easy alternative is
data E = Ea A | Eb B | Ec C | …
type R = [E]
which has a straightforward empty object, but one then must
define
getA e = listToMaybe [a | Ea a - e]
for each field, which is tedious (and O(n)). Obviously Templates
would help, but is there an alternative I’ve missed?
--
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Kleisli composition is not in the Monad signature?
I think the version below (with a Functor or Applicative superclass) is clearly the right answer if we were putting the prelude together from a clean slate. You can implement whichever is easiest for the particular monad, use whichever is most appropriate to the context (and add optimized versions if you prove to need them). I see no advantage in any other specific proposal, except the enormous advantage held by the status quo that it is already written, already documented, already distributed, and already coded to. Regarding mathematical purity of the solutions, this is in every way isomorphic to a monad, but we aren't calling it a monad because we are describing it a little differently than the most common way to describe a monad in category theory strikes me as *less* mathematically grounded than we are calling this a monad because it is in every way isomorphic to a monad. On Tue, Oct 16, 2012 at 7:03 AM, AUGER Cédric sedri...@gmail.com wrote: So I think that an implicit question was why wouldn't we have: class Monad m where return :: a - m a kleisli :: (a - m b) - (b - m c) - (a - m c) bind = \ x f - ((const x) = f) () join = id=id :: (m (m a) - m a) ___ 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] Platform Versioning Policy: upper bounds are not our friends
Would it make sense to have a known-to-be-stable-though soft upper bound added proactively, and a known-to-break-above hard bound added reactively, so people can loosen gracefully as appropriate? On Aug 15, 2012 1:45 PM, Johan Tibell johan.tib...@gmail.com wrote: On Wed, Aug 15, 2012 at 1:02 PM, Brandon Allbery allber...@gmail.com wrote: So we are certain that the rounds of failures that led to their being *added* will never happen again? It would be useful to have some examples of these. I'm not sure we had any when we wrote the policy (but Duncan would know more), but rather reasoned our way to the current policy by saying that things can theoretically break if we don't have upper bounds, therefore we need them. -- Johan ___ 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] Are there arithmetic composition of functions?
The 17 at the end should be 12, or the 2 passed into (f+g+2) should be 3.
On Mon, Mar 19, 2012 at 10:38 AM, Ozgur Akgun ozgurak...@gmail.com wrote:
Hi,
If you are feeling adventurous enough, you can define a num instance for
functions:
{-# LANGUAGE FlexibleInstances #-}
instance Num a = Num (a - a) where
f + g = \ x - f x + g x
f - g = \ x - f x - g x
f * g = \ x - f x * g x
abs f = abs . f
signum f = signum . f
fromInteger = const . fromInteger
ghci let f x = x * 2
ghci let g x = x * 3
ghci (f + g) 3
15
ghci (f+g+2) 2
17
HTH,
Ozgur
On 19 March 2012 16:57, sdiy...@sjtu.edu.cn wrote:
By arithmetic I mean the everyday arithmetic operations used in
engineering.
In signal processing for example, we write a lot of expressions like
f(t)=g(t)+h(t)+g'(t) or f(t)=g(t)*h(t).
I feel it would be very natural to have in haskell something like
g::Float-Float
--define g here
h::Float-Float
--define h here
f::Float-Float
f = g+h --instead of f t = g t+h t
--Of course, f = g+h is defined as f t = g t+h t
___
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] Theoretical question: are side effects necessary?
If the question is when can I have my output, then both are equally relevant and can be safely conflated. That said, while some programming problems *are* of this type, I think most aren't, and your points certainly stand. On Fri, Mar 16, 2012 at 3:31 PM, Chris Smith cdsm...@gmail.com wrote: On Fri, Mar 16, 2012 at 3:43 PM, serialhex serial...@gmail.com wrote: an interesting question emerges: even though i may be able to implement an algorithm with O(f(n)) in Haskell, and write a program that is O(g(n)) O(f(n)) in C++ or Java... could Haskell be said to be more efficient if time spent programming / maintaining Haskell is C++ or Java?? There are two unrelated issues: (a) the efficiency of algorithms implementable in Haskell, and (b) the efficiency of programmers working in Haskell. It makes no sense to ask a question that conflates the two. If you're unsure which definition of efficient you meant to ask about, then first you should stop to define the words you're using, and then ask a well-defined question. That being said, this question is even more moot given that real Haskell, which involves the IO and ST monads, is certainly no different from any other language in its optimal asymptotics. Even if you discount IO and ST, lazy evaluation alone *may* recover optimal asymptotics in all cases... it's known that a pure *eager* language can add a log factor to the best case sometimes, but my understanding is that for all known examples where that happens, lazy evaluation (which can be seen as a controlled benign mutation) is enough to recover the optimal asymptotics. -- Chris Smith ___ 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] Some thoughts on Type-Directed Name Resolution
record.field (read record, oops, I only want part of it.) I would read this record's field ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
Crash blossoms, while amusing, are not a desirable feature of a programming language. They are specifically a failure to communicate clearly. On Feb 6, 2012 6:38 PM, AntC anthony_clay...@clear.net.nz wrote: Donn Cave donn at avvanta.com writes: You can find stuff like fromIntegral.ord in packages downloaded to build cabal-install for example. It graphically appeals to the notion of a function composed of several functions, so the programmers in question will likely not even be repentant! Data.Char.toUpper -- a name composed of several names shape.position.xCoord -- a structure composed of several structures Here's an off-the-wall idea for the syntactics: - Where there's a block of names with dot separators (and no spaces). - The dots must be either all postfix apply or all prefix compose. - Postpone analysing until we've got some type info for the sub-names. - The types must interlock either left-to-right or right-to-left. So now we know whether we're prefix or postfix. - Then we can adjust the AST for loose-binding vs tight-binding. (As happens for operator precedence.) ?Do we call this Type-Directed Syntax Resolution ;-) (By the way, natural languages do this sort of stuff all the time. In fact they revel in it: Eighth Army Push Bottles Up German Rear. http://languagelog.ldc.upenn.edu/nll/?p=3708 ) The more I think about it, the more the pseudo-fields makes sense, the more I want field selectors to be just functions. There's an interesting example in Wadler's original paper that became View Patterns Views: A way for pattern matching to cohabit with data abstraction [1987], 4. Viewing a complex number in cartesian and polar coordinates. We may want our implementation of complex to be abstract. We provide (pseudo-) fields to select the coordinates. Then they're ever-so like methods for an (abstract) object. Also we want the (pseudo-) fields to be updatable, which means field update needs to be polymorphic (overloaded). Then all I need is a type-(or kind-) level 'peg' for the name, and an instance for Has/get/set. AntC ___ 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] black Wikipedia
My understanding is that blocking/redirection is to be done at the DNS level. In which case, there *is* a ?banner hack of sorts - get the IP by some other means. Which is not to say we should be significantly less concerned. On Wed, Jan 18, 2012 at 10:17 AM, Brandon Allbery allber...@gmail.com wrote: On Wed, Jan 18, 2012 at 13:11, Henning Thielemann lemm...@henning-thielemann.de wrote: On Wed, 18 Jan 2012, Andrew Butterfield wrote: Just add ?banner=none to the url if you really have to read the page Maybe the intention was to demonstrate that censorship (in this case self-censorship) is mostly a problem for average users but not for advanced users. There isn't going to be a disable-javascript or ?banner hack when anyone anywhere can force a website to be redirected to some DOJ page without providing any proof. (Yes, really.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ 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] black Wikipedia
Granted, but nothing a technical user can't handle, which was the earlier question. On Wed, Jan 18, 2012 at 2:18 PM, Brandon Allbery allber...@gmail.com wrote: On Wed, Jan 18, 2012 at 17:15, David Thomas davidleotho...@gmail.com wrote: My understanding is that blocking/redirection is to be done at the DNS level. In which case, there *is* a ?banner hack of sorts - get the IP by some other means. Sadly name-based virtual hosts require a bit more work than that... -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] IO typeclasses
Is there any particular reason IO functions in the standard libraries aren't grouped into type-classes? This might allow for: 1) Testing IO code without actual input and output. (I have done this on a small scale, but it presently involves much ugliness). 2) Redirecting output of a function that neglects to take a handle without a bunch of calls to dup. 3) Forwarding IO over a connection to a remote system, allowing code written to work locally to be applied remotely, or vice-versa. 4) Wrapping dangerous IO actions in additional sanity checks. Thoughts? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
