- Haskell-Cafe - Haskell.org

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

03 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 03 Mar '15

03 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 02 Mar '15

02 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

ANNOUNCE postgresql-query and postgresql-config
by Alexey Uimanov 01 Mar '15

01 Mar '15

Hi guys! Here is yet another some-level library to work with PostgreSQL DB. http://hackage.haskell.org/package/postgresql-query This library uses `postgresql-query` and is a list of helpers/workarounds to generate complex queries more safely and parse result. What it contains: 1. interplating quasiquote `sqlExp` which uses instances of `ToField` typeclass to paste values inside query. It looks like this: let val = "'hello'" :: Text q = [sqlExp|SELECT field1 FROM tbl WHERE field2 = #{val}|] where `val` is an arbitrary Haskell expression which type has instance of `ToField` Resulting query will be like: "SELECT field1 FROM tbl WHERE field2 = '''hello'''" Yes, proper string escaping is performed authomatically like using this '?'-like queries with parameters. Resulting type of quasiquote is `SqlBuilder` which uses bytestring builders inside and can be concatenated efficiently. There is also posibility to paste one query inside another like: let q2 = [sqlExp|SELECT field1 f FROM (^{q}) WHERE field1 is not null|] so `q2` will generate nested query. sqlExp also removes SQL comments and removes long sequences of space characters. It also properly handles string literals and quoted identifiers inside quasiquotes. 2. Typeclass `HasPostgres`, simple connection reader `PgMonadT` and functions like `pgQuery` to perform queries. http://hackage.haskell.org/package/postgresql-query-1.0.1/docs/Database-Pos… 3. TH functions to authomatically derive `FromRow` and `ToRow` instances (from postgresql-simple) http://hackage.haskell.org/package/postgresql-query-1.0.1/docs/Database-Pos… 4. Some kind of primitive pre-ORM which generates queries for CRUD-ing simple record types. It looks like: data User = User { userName :: !Text , userPasswordEncrypted :: !Text } deriving (Show, Eq, Ord, Typeable) type UserId = EntityId User $(deriveFromRow ''User) $(deriveToRow ''User) instance Entity User where newtype EntityId User = UserId { unUserId :: UUID } -- Note that you can use any type for id deriving (Show, Read, Ord, Eq, FromField, ToField, PathPiece) -- To use with Yesod tableName _ = "users" fieldNames _ = [ "name" , "password_encrypted" ] runPgMonadT con $ do uid <- pgInsertEntity $ User "name" "j27dna74ja784ha7" pgUpdateEntity uid $ MR [("name", mkValue "John")] pgDeleteEntity uid There is also package http://hackage.haskell.org/package/postgresql-config which contains trivial code to make your postgresql-simple connection pool easily configurable.

1 0

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

01 Mar '15

On Sun, Mar 1, 2015 at 3:03 AM, fr33domlover <fr33domlover(a)riseup.net> wrote: > Hello Mike, > I think there's some confusion here. I wan't talking about GPL compatible > licenses, but about *any* free software license! According to Gershom's letter, it already does that. Or at least "cabal check" does. > It looks like Creative Commons licenses may apply too, in particular the > version 4 ones. CC by 4 is even GPL-compatible. > The same for EPL and CDDL! Check out this: > http://www.gnu.org/licenses/license-list.HTML > Both are free sofware licenses. GPL compatibility isn't the issue here :) That URL gets a 404 error. However, if you look at this page: http://www.gnu.org/licenses/license-list.HTML you'll find that the EPL and CDDL are listed as incompatible. The CC licenses are only mentioned as non-software licenses, and not all of them are listed. Nuts, it's even documented that the CC licenses aren't all compatible with each other! https://wiki.creativecommons.org/Wiki/cc_license_compatibility > > And what if I want something like the CDDL or the EPL? Those are both > > licenses that the OSI says are popular. > The FSF approves them as well, like I said. Well, I found them on a free license list. Of course, some of those include things like "We urge you not to use the CDDL" in them, which hardly sounds like approval to me. 5 > > 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. > I don't think it will, because people are already making free software. Look at > other existing hosting services - they're *full* of free software! This is what > people are making anyway. All I suggest is to make it official, providing a > guarantee so people know each `cabal install` indeed installs only free > software. As long as you're willing to accept any license that the author thinks of as free, then it won't. But that's such a broad scope as to make this change effectively negligible, even from my nit-picking standpoint. > > 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. > That's true, but eventually you wouldn't want to do that. I mean, if you build > some program, you'd be happy to have it packaged for distros and make binary > releases for people who don't want to build from source. Sure, I may be happy to have the binaries build and packaged for all distros. Then again, I know there are people building software using Haskell - and hence hackage or stackage - that aren't planning on distributing the software in any form, so don't care about this issue. For me personally, the FreeBSD package system allows for adding things that have to be built from source for some reason or another, and make building them as easy as installing the binaries. I'm happy providing FreeBSD ports, but making it possible for people building packages for less flexible systems who actually check all the licenses involved isn't something I'm going to spend a lot of effort on. And you're proposed change - or possibly non-change, given what Gershom reported - won't change that effort. All the licenses involved are free. However, some of them aren't compatible with each other, so the only way to fix this is to use different packages. I suppose I could try and get some of the authors to change their license, but that's probably even more work. > This is essentially the question I'm asking the community: do you care about > the packages being free software, allowing legal distribution of binaries? > Specifically, would you make a step forward and make it official, build-in > into Hackage? Except you can't answer the question "does it allow legal distribution of binaries" by just looking at the license on the package. You also have to consider the licenses on the transitive closure of the libraries it uses, as they will be included in the binary, or at least dynamically linked to it, and thus may be considered a derivative work of the packages it includes. So your binary has to comply with the terms of all those licenses, which may not be possible even if all the licenses are approved by the OSI or on the FSF's list of free licenses. Which is also why even the relatively minor restriction "must allow free redistribution of binaries" isn't one I'd be happy with. Sure, it probably won't affect most people. But it equally won't help most people who want to distribute binaries, because it only removes a minor source of barriers to doing so. Unless, of course, by "must allow free redistribution of binaries", you mean "doesn't place any restrictions whatsoever on the distribution of binaries", which would eliminate the not only many of the CC licenses, but also the GPL and some of the BSD licenses. <mike

1 0

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