February 2015 - Haskell-Cafe

is it possible to implement Functor for ByteString and Text
by silvio 05 Mar '15

05 Mar '15

I have recently heard that some people want to burn bridges (introducing Foldable and Traversable to Prelude) and I've been wondering if it was possible somehow allow Text and Bytestring like containers to make use of those functions. Something along the lines of import qualified Data.ByteString as BS newtype ByteString' a = ByteString' BS.ByteString type ByteString = ByteString' Word8 instance (ByteString' a ~ ByteString' Word8) => Functor (ByteString') where fmap f (ByteString' bs) = ByteString' $ BS.map f bs Or if DataContexts worked as you would expect. newtype (Word8 ~ a) => ByteString' a = ByteString' BS.ByteString However I couldn't find a solution and I was just wondering if it is possible. P.S. Using GADTS it does actually work for Foldable, but only because it doesn't have to output any ByteStrings. It doesn't work for Functor for instance. data ByteString' a where ByteString' :: BS.ByteString -> ByteString' Word8 type ByteString = ByteString' Word8 instance Foldable ByteString' where foldr f ini (ByteString' bs) = BS.foldr f ini bs Silvio

7 9

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

03 Mar '15

On Sat, Feb 28, 2015 at 11:27 AM, fr33domlover <fr33domlover(a)riseup.net> wrote: > Hello haskellers! > I'd like to make a suggestion: have Hackage accept only packages released under > free software licenses. Anything that excludes software that we could use, or otherwise discourages people from making software available to the community, is a bad idea. A restriction to OSF-approved licenses would exclude anything released under a Creative Commons license, since the OSF doesn't list those, which makes sense as they aren't "software licences" per se. And your restriction of "released under a license" would exclude public domain software - at least in countries that recognize such a thing. Yes, these are nits, but these are nits that could cause someone to decide not to put software that is otherwise perfectly acceptable on Hackage. > Actually the all-rights-reserved tag in Hackage [1] has only two packages > tagged by it - the dummy no-op project HNop, and another package whose COPYING > file contains a broken link and whose README says "BSD style license". This is a general problem on any site that offers downloads with a license type tag. What happens if the selected license tag and the included license have different rights? My suspicion is that if it went to court, you could justify using it under either license, meaning that such things are effectively dual licensed. We might make add a statement making that explicit. In particular, an "all-rights-reserved" tag implies that you may have to ask someone's permission to even download the package from Hackage, so it doesn't make a lot of sense. Given that - with the dual license interpretation - it effectively isn't used, removing it might make sense. Or renaming it to "other not listed" may be more appropriate. <mike

5 9

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

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

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

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

01 Mar '15

On Sat, Feb 28, 2015 at 1:43 PM, fr33domlover <fr33domlover(a)riseup.net> wrote: On 2015-02-28 Mike Meyer <mwm(a)mired.org> wrote: > > Anything that excludes software that we could use, or otherwise > > discourages people from making software available to the community, is > > a bad idea. A restriction to OSF-approved licenses would exclude > > anything released under a Creative Commons license, since the OSF > > doesn't list those, which makes sense as they aren't "software > > licences" per se. And your restriction of "released under a license" > > would exclude public domain software - at least in countries that > > recognize such a thing. > > As to creative commons - indeed they aren't meant for software (maybe except > for CC0, which is basically like public domain). But I also don't think people > want to use them once they see the problem: If you want it permissive, you have > Apache for example (also BSD/MIT), and if you want copyleft you have GPL (also > AGPL, etc.). And what if I want something like the CDDL or the EPL? Those are both licenses that the OSI says are popular. > As to public domain: It's actually just fine! It's true than most countries > recognize lack of license as "all rights reserved", but I also think it's a > very small and trivial task for a maintainer to add a few license lines to > state that the software should be globally treated as public domain. > > So public domain software is just fine, free software. You're addressing the nits, not the core issue I tried to raise: placing restrictions on what licenses (or lack thereof) are acceptable will discourage people from making software available via Hackage. > > Yes, these are nits, but these are nits that could cause someone to > > decide not to put software that is otherwise perfectly acceptable on > > Hackage. > That depends on what "acceptable" means. In the worst case you can have > separation between free and nonfree software by tag, and make it possible to > turn nonfree software on/off using a cabal-install commandline option. > > This will allow people to upload first, and then think and understand the > licensing situation. Once they do, they can properly tag their project. Could > that work? I don't know. I suspect that if you do that, a lot of people would never bother tagging their packages. Would that work for you? You also talk like free/non-free was a binary decision, when it isn't. The OSI lists licenses that aren't compatible with the GPL - like the aforementioned EPL and CDDL. People releasing software under one of those will want to avoid GPL licensed software, whereas people releasing GPL licensed software will want to avoid those licenses, but they are all free. Or I may not care. If I build a binary that uses one package that's GPL-licensed and one that uses an incompatible OSI-approved license, I can distribute my source under whatever terms I want, because my source doesn't include source from those packages. I can build and run binaries myself with no problems, and that may be fine. But I can't distribute binaries because I can't satisfy both licenses simultaneously, and that may not be acceptable. <mike

2 1

Re: [Haskell-cafe] Hackage and Free Software
by Francesco Ariis 28 Feb '15

28 Feb '15

On Sat, Feb 28, 2015 at 07:27:16PM +0200, fr33domlover wrote: > I'd like to make a suggestion: have Hackage accept only packages > released under free software licenses. This is probably true for > most/all packages there, but making it official will both send a > strong message to and from the community, and provide people with > the security and peace of mind, knowing their software is free as > in freedom. I was pretty sure there was a note somewhere on hackage to only upload software with open source licences, but alas I cannot find it now... (maybe I am confusing myself with another package archiver?). I agree having a "please use a licence approved by the OSI/FSF" could prevent problems and seems a sensible choice in any case.

2 1