March 2015 - Haskell-Cafe

Re: [Haskell-cafe] Hackage and Free Software
by Mike Meyer 03 Mar '15

03 Mar '15

On Mon, Mar 2, 2015 at 3:36 PM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On 2015-02-28 > Mike Meyer <mwm(a)mired.org> wrote: > > > > > There are open source projects that are systematically excising GPL'ed > > software because of the problems it shares with ShareAlike licenses. > Should > > we disallow the GPL because some people have problems with it? > > > > Making Hackage better to help users sort out which licenses they are > > willing to accept in their project - which I personally would like to do > on > > a project-by-project basis! - is a solution to these problems. > Restricting > > the licenses that are acceptable on Hackage to meet some arbitrary set of > > criteria is a knee-jerk. > The restrictions aren't arbitrary at all. They're based on ethics. On > Software > freedom. > Until you've got an objective set of ethics - or a definition of "software freedom" - that everyone accepts, that's just a long-winded way of saying "arbitrary". Here's a suggestion: We can talk about this forever, because there seem to > be > no official guidelines to really discuss. Why don't we put clear > guidelines at > hackage.haskell.org ? If these guidelines would be "proprietary software > allowed", then there's a point to discuss. But if the guideline requires > certain tagging - currently all the license tags except > all-rights-reserved are > free software licenses - maybe the problem is already solved. > Not quite. "OtherLicense" is an accepted license tag, and I take it to mean I can use any license I want. If you're going to place a restriction on the license types beyond "use one of our tags" (and if you disallow the otherLicense tag, then I'd say that's an arbitrary restriction), then you should either define the terms in it, or choose terms that are well defined. "free software" is so ill defined that gnu.org has to explain what they mean by "free software" (https://www.gnu.org/philosophy/free-sw.html) They even point out that there are open source software licenses that don't meet their definition of free ( https://www.gnu.org/philosophy/open-source-misses-the-point.html) Their definition of proprietary as "not free" makes software licensed under such licenses proprietary, though that's certainly not common usage. So just saying "only free software licenses" or "no proprietary software" would make matters worse, not better, because those terms have multiple meanings in common use. And that makes them not only arbitrary, but vague.

4 4

Re: [Haskell-cafe] Hackage and Free Software
by Mike Meyer 03 Mar '15

03 Mar '15

On Tue, Mar 3, 2015 at 3:19 AM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On Mon, 2 Mar 2015 16:27:53 -0600 > Mike Meyer <mwm(a)mired.org> wrote: > > Until you've got an objective set of ethics - or a definition of "software > > freedom" - that everyone accepts, that's just a long-winded way of saying > > "arbitrary". > Indeed there is an objective clear definition: > http://www.gnu.org/philosophy/free-sw.html Applying that definition may be objective, but not everyone agrees that it's a correct definition of free software, which makes it a subjective definition. > > Not quite. "OtherLicense" is an accepted license tag, and I take it to mean > > I can use any license I want. If you're going to place a restriction on the > > license types beyond "use one of our tags" (and if you disallow the > > otherLicense tag, then I'd say that's an arbitrary restriction), then you > > should either define the terms in it, or choose terms that are well > > defined. "free software" is so ill defined that gnu.org has to explain what > > they mean by "free software" ( https://www.gnu.org/philosophy/free-sw.html) > > They even point out that there are open source software licenses that don't > > meet their definition of free ( > > https://www.gnu.org/philosophy/open-source-misses-the-point.html) Their > > definition of proprietary as "not free" makes software licensed under such > > licenses proprietary, though that's certainly not common usage. > "Open source misses the point" talks about the open source movement - it > doesn't say the BSD, MIT or Apache are not free software licenses. They are! > gnu.org provides a definition of free software, which makes it quite well > defined. There's even a list of licenses. While the BSD, MIT and Apache licenses are free, the GNU license list (https://www.gnu.org/philosophy/license-list.html#NonFreeSoftwareLicenses) provides a long list of open source licenses that aren't free. Some of them aren't free because they are truly noxious, some aren't free because they are poorly written, and some aren't free because the developers restrictions they feel are reasonable, but violate that letter if not the spirit of that definition. > There is nothing arbitrary about it - in the same way the law that puts > murderers in prison isn't arbitrary. It's based on ethics: the value of human > life. Free software is similarly based on the value people's freedom to control > their computing, know what they run and be able to adapt and spread it. Yes, but not everyone agrees to something you would think would be clearcut, like the value of a human life. For instance, some cultures feel that giving your own life for the good of your religion is the best thing you can do with it, and think nothing of taking away some non-believers life for that cause. And in other cultures, your life isn't yours but the states, and you don't have the right to end it yourself. Since there's such broad disagreement on the value of a human life, then it should be no surprise that people disagree on an idea as recent as "free software". For instance, I find it a bit ironic that a defintion of "free software" puts restrictions on derived works that the original author doesn't have to abid by. > > So just saying "only free software licenses" or "no proprietary software" > > would make matters worse, not better, because those terms have multiple > > meanings in common use. And that makes them not only arbitrary, but vague. > The FSF's definition is the only definition I know of. If people understand it > in a different way, this only strengthens my point: make it official and > explain the details and rules, so people do understand what free software is. > If hackage.haskell.org explains this, there will be nothing vague anymore. Pointing to an external definition is certainly an acceptable way to clear up the issue of the meaning of the phrase. However, I object to any definition that excludes open source licenses that would otherwise be useable under the otherLicnese tag for reasons I find capricious (i.e - any license with a "no commercial use" clause is excluded, and the lovely "must use for good" clause in the JSON license causes it to be excluded). The OSI's definition of open source doesn't have any of those problems. How about using it: http://opensource.org/definition <mike

1 0

A Proposed Law for Foldable?
by Gershom B 02 Mar '15

02 Mar '15

For a long time, many people, including me, have said that "Foldable has no laws" (or Foldable only has free laws) -- this is true, as it stands, with the exception that Foldable has a non-free law in interaction with Traversable (namely that it act as a proper specialization of Traversable methods). However, I believe that there is a good law we can give for Foldable. I earlier explored this in a paper presented at IFL 2014 but (rightfully) rejected from the IFL post-proceedings. ( http://gbaz.github.io/slides/buildable2014.pdf) That paper got part of the way there, but I believe now have a better approach on the question of a Foldable law -- as sketched below. I think I now (unlike in the paper) can state a succinct law for Foldable that has desired properties: 1) It is not "free" -- it can be violated, and thus stating it adds semantic content. 2) We typically expect it to be true. 3) There are no places where I can see an argument for violating it. If it pans out, I intend to pursue this and write it up more formally, but given the current FTP discussion I thought it was worth documenting this earlier rather than later. For simplicity, I will state this property in terms of `toList` although that does not properly capture the infinite cases. Apologies for what may be nonstandard notation. Here is the law I think we should discuss requiring: * * * Given Foldable f, then forall (g :: forall a. f a -> Maybe a), (x :: f a). case g x of Just a --> a `elem` toList x * * * Since we do not require `a` to be of type `Eq`, note that the `elem` function given here is not internal to Haskell, but in the metalogic. Furthermore, note that the use of parametricity here lets us make an "end run" around the usual problem of giving laws to Foldable -- rather than providing an interaction with another class, we provide a claim about _all_ functions of a particular type. Also note that the functions `g` we intend to quantify over are functions that _can be written_ -- so we can respect the property of data structures to abstract over information. Consider data Funny a = Funny {hidden :: a, public :: [a]} instance Foldable Funny where foldMap f x = foldMap f (public x) Now, if it is truly impossible to ever "see" hidden (i.e. it is not exported, or only exported through a semantics-breaking "Internal" module), then the Foldable instance is legitimate. Otherwise, the Foldable instance is illegitimate by the law given above. I would suggest the law given is "morally" the right thing for Foldable -- a Foldable instance for `f` should suggest that it gives us "all the as in any `f a`", and so it is, in some particular restricted sense, initial among functions that extract as. I do not suggest we add this law right away. However, I would like to suggest considering it, and I believe it (or a cleaned-up variant) would help us to see Foldable as a more legitimately lawful class that not only provides conveniences but can be used to aid reasoning. Relating this to adjointness, as I do in the IFL preprint, remains future work. Cheers, Gershom

8 19

Re: [Haskell-cafe] Skolems!
by evan＠evan-borden.com 02 Mar '15

02 Mar '15

An extension of the message Tom sent a little while back, we've discovered a more in depth example of this possible GHC bug. It is exacerbated by GADTs, but can be fixed with NoMonoLocalBinds. Without GADTs and just leveraging ExistentialQuanitification it works fine. We've included a pretty exhaustive set of examples. {-# LANGUAGE ExistentialQuantification, GADTs #-} {- removing MonoLocalBinds fixes all of these errors {-# LANGUAGE ExistentialQuantification, GADTs, NoMonoLocalBinds #-} -} module PossibleGHCBug where data SumType = SumFoo | SumBar class SomeClass a where someType :: a -> SumType data SomeExistential = forall a. SomeClass a => SomeExistential a noError :: String -> [SomeExistential] -> String noError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" noError2 :: String -> [SomeExistential] -> String noError2 n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c :: SumType -> String c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n noError3 :: String -> [SomeExistential] -> String noError3 n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d :: SomeClass a => a -> String d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n partialTypedError :: String -> [SomeExistential] -> String partialTypedError n st = n ++ concatMap cname st where cname :: SomeExistential -> String cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n fullError :: String -> [SomeExistential] -> String fullError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> "asdf" ++ n justNError :: String -> [SomeExistential] -> String justNError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> n ignoreNError :: String -> [SomeExistential] -> String ignoreNError n st = n ++ concatMap cname st where cname (SomeExistential p) = d p d p = c $ someType p c p = case p of SumFoo -> "foo" _ -> fst ("foo", n)

5 6

New Functional Programming Job Opportunities
by Functional Jobs 02 Mar '15

02 Mar '15

Here are some functional programming job opportunities that were posted recently: Senior Software Engineer at McGraw-Hill Education http://functionaljobs.com/jobs/8787-senior-software-engineer-at-mcgraw-hill… Engineering Manager (OCaml or Haskell under Linux) at FireEye http://functionaljobs.com/jobs/8786-engineering-manager-ocaml-or-haskell-un… Cheers, Sean Murphy FunctionalJobs.com

1 0

Would you use frozen-base
by Joachim Breitner 02 Mar '15

02 Mar '15

Hi, = Introduction (can be skipped) = Recently, I find myself often worried about stability of our ecosystem – may it be the FTP discussion, or the proposed¹ removal of functions you shouldn’t use, like fromJust. While all that makes our language and base libraries nicer, it also means that my chances that code from 3 or 4 years ago will compile without adjustment on newer compilers are quite low. Then I remember that a perl based webpage that I wrote 12 years ago just keeps working, even as I upgrade perl with every Debian stable release, and I’m happy about that. It makes me wonder if I am ever going to regret using Haskell because there, I’d have to decide whether I want to invest time to upgrade my code or simply stop using it. I definitely do not want to stop Haskell from evolving. Maybe we can make a more stable Haskell experience opt-in? This is one step in that direction, solving (as always) only parts of the problem. = The problem = One problem is that our central library "base" is both an implementation and an interface. As the implementation is tied to the compiler, and the interface comes with the implementation, you cannot upgrade one without the other. = My solution: frozen-base = My solution would be to provide a new library, let’s call it frozen-base, which decouples the interface (frozen-base) from the implementation (still base). We would start with one particular version of base, say, 4.6. With GHC-7.6 (which comes with base 4.6), frozen-base would simply re-export its modules². On newer compilers and newer versions of base, it would re-create the old interface using CPP. So if your program depends on frozen-base only, you can expect it to compile with newer versions of GHC – achievement unlocked. = How to get new features, then? = But does that mean that you do not get to use great new functionality in later versions of base, such as Data.Bool.bool? No: When a new version of base gets released, and a module gets changed, than frozen-base will ship a _new_ module, named Data.Bool1 that matches that interface. The next change in base causes yet another module to be created, i.e. Data.Bool2 So if you need to use Data.Bool.bool, in one of your modules, you simply change the import from "import Data.Bool" to "import Data.Bool2", adjust your code to the new interface, and are ready to go. Note that you only had to adjust to the changes in Data.Bool, nothing else. Note that you also had to touch only a single module in your program, the others still use whatever interface they were using. Your dependency on frozen-base would have to indicate a lower version bound, i.e. specify the lowest version that has all the Data.Bool<n> variants that you desire, but – by design – never an upper version.³ = When does it not work? = Of course, the promises by froze-base are not absolute: There are changes in base that frozen-base cannot protect you against: Data type changes, some type class changes, type class instances. I don’t have any great ideas here, but maybe they are rare enough so that frozen-base is still useful. = What about the Prelude? = I did not talk about the Prelude. There probably is not a good solution, and I’d simply leave the Prelude frozen. Maybe later GHC has a nice way to specifying which Prelude to use in a certain module, then you could use "Prelude1", "Prelude2" etc. in the same manner. = How does it related to base-compat? = The idea is similar to what base-compat provides, but the other way around: base-compat allows you to use the latest features of base on older compilers, while frozen-base would allow you to use the API of old base versions on newer systems. Frozen-base might subsume base-compat by providing, say Data.Bool2 with the API from base-4.8 also on systems with base-4.6. = How does it related to the split base proposal = Depending on how exactly base is being reconstructed, it might become a pure interface package on its own, or at least independent from compiler-specific bits. Then it might be feasible that, say, after the release of ghc-7.10 there is a new upload of base-4.6.0.n that provides the 4.6 API, but compiles on ghc-7.10. This way, if you depend on base == 4.6.* you could still expect your program to work. If that happens, and also cabal would learn that a plan with different versions of a interface only library like base are not a problem, frozen-base might be obsoleted. See https://ghc.haskell.org/trac/ghc/wiki/SplitBase for more on that. = No Conclusion and lots of future work = So what do you think? Would you be interested in using this? Do you have reasons to believe that this will not work as nicely as I think i could? Greetings, Joachim ¹ but rejected, it seems ² or a sensible subset; I could imagine not exporting certain .Internal modules and things like OldTypeable that are about compatibility themselves. ³ or just one on the very major version number (frozen-base < 2), which to allow for exceptional breaking changes – a redesign of the module naming scheme for example. -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata(a)debian.org

7 11

how to make this work recursive ?
by Roelof Wobben 02 Mar '15

02 Mar '15

Hello, I found out that for 1 item I can do this : node = Node leaf "msg 1" leaf And for 2 items I can do this : node = Node leaf "msg1" (Node leaf "msg2" leaf) But now I wonder how I can make this work with recursion. It seems that I keep the first 2 items and change the 3th one from leaf to another node Roelof

5 17

ANN: clustering-0.1.0
by Kai Zhang 02 Mar '15

02 Mar '15

https://hackage.haskell.org/package/clustering This package provides optimal algorithms (O(N^2)) for hierarchical clustering, including single linkage, complete linkage, average linkage, weighted linkage, and Ward's method. Benchmarks of average linkage can be found here: https://github.com/kaizhang/clustering. I hope this would be useful in general. Motivation of this work: I found the "hierarchical-clustering" library cannot handle large input (>10^4) due to its suboptimal algorithms. Best, Kai

1 0

What other prelude to cleanly convert text-files into json
by Bram Neijt 01 Mar '15

01 Mar '15

Dear reader, I wrote some tiny code to parse files into json (to automate escaping multi-line text). It quickly became a collection of "import qualified" and "T.unpack, T.pack" calls that made the whole thing look ugly [1]. What "alternative prelude" would help in getting clean code when combining "aeson" and reading text files? Greetings, Bram [1] Source can be read here: https://gist.github.com/bneijt/9bdb4b1759790a8463c9

3 5

A Question about IO monad
by Zongzhe Yuan 01 Mar '15

01 Mar '15

Hi i have a question about IO monad. Sometimes IO do something and return something, i wonder if the return type, for example is IO Int means it will return an int, could i purely fetch the int? but i fail, i cannot construct a function, i use do notation but i found i must use something to pass the int to another monad. But i could write a function has the type of Maybe a -> a and it is easily. Maybe monad and IO monad both instance monad but why i can’t do that? Zongzhe Yuan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

5 5