October 2015 - Haskell-Cafe

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Mike Meyer 06 Oct '15

06 Oct '15

On Tue, Oct 6, 2015 at 2:40 AM Bardur Arantsson <spam(a)scientician.net> wrote: > > - To use functions like "tryReadMVar", "unsafeShiftR", and > > "atomicModifyIORef'" that are in recent base versions but not older > ones > > (this is a place where CPP use is actually justified) > Well, yeah, new functions don't magically appear in old versions. I > don't anybody expects that :). > Right - they have to be backported, and imply maintenance of multiple branches. Python has been mentioned a couple of times. They did that, backporting functions that mimiced Python 3 functions to later Python 2 versions, which made the tools mentioned possible, or at least more capable. I'll refer those wanting fewer breaking changes to Python. Getting language changes accepted by the PYthon community is *hard*. You need a use case for your change, you need to show that the case can't be handled cleanly by the language as it exists today, that it's common enough to justify the change, and that it won't tempt people to write uglier code than the current solution. If you want to break old code, all those bars get raised - a lot. Or did, anyway, The result of following that was the Python 2/Python 3 split, which I don't think anybody thought was a good thing. Unavoidable, maybe - Python 3 had to break backwards compatibility, so they cleaned up everything along the way, and created tools to migrate code, and committed to maintaining both versions for an extended period of time. And the community was pretty badly splintered by this. The one thing I think they got right is documenting the language change process with the entire PEP process. We seem to have wiki pages, with no editorial oversight, and pages show up in google searches after they've been incorporated into the language in a different form. Not quite as good a thing.

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal
by Doug McIlroy 05 Oct '15

05 Oct '15

Sorry for the premature send. The incomplete sentence was: In any event, #ifdef is, as Simon evidently agrees, telling evidence of non-portability. It is hard to imagine an uglier "solution" to keeping up with the drip-drip-drip of Haskell evolution. doug

1 0

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by mantkiew＠gsd.uwaterloo.ca 05 Oct '15

05 Oct '15

I loved the statement made by Ryan Trinkle in his recent talk [1]: "since we cannot predict all the changes needed the future, we must have an architecture that will support any change" (it's roughly like that, not an exact quote, about 4minutes in). Having to use IFDEFs is a sign that the language itself is not expressive enough to deal with these kinds of changes and therefore it's not having the right "architecture". Is Backpack going to provide the necessary support, (e.g., ability to mix in package fragments with extensions instead of making breaking changes)? What kind of language features are still missing? Anyway, mistakes were made in the past, because had we known any better we would have done better. Nothing should prevent us from fixing mistakes. Regarding IFDEFS, all of them disappeared from my code once I used transformers-compat and mtl-compat. ‎Also the trick with import Prelude worked-you just have to list what you hide instead of what you import (which is weird...). -- Michał [1] http://www.infoq.com/presentations/functional-techniques-complexity On Mon, Oct 5, 2015 at 2:34 PM, Gregory Collins <greg(a)gregorycollins.net> wrote: > > On Mon, Oct 5, 2015 at 8:09 AM, Gershom B <gershomb(a)gmail.com> wrote: >> >> My understanding of the argument here, which seems to make sense to me, is >> that the AMP already introduced a significant breaking change with regards >> to monads. Books and lecture notes have already not caught up to this, by >> and large. Hence, by introducing a further change, which _completes_ the >> general AMP project, then by the time books and lecture notes are all >> updated, they will be able to tell a much nicer story than the current one? > > > This is a multi-year, "boil the ocean"-style project, affecting literally > every Haskell user, and the end result after all of this labor is going to > be... a slightly spiffier bike shed? > > Strongly -1 from me also. My experience over the last couple of years is > that every GHC release breaks my libraries in annoying ways that require CPP > to fix: > > ~/personal/src/snap λ find . -name '*.hs' | xargs egrep > '#if.*(MIN_VERSION)|(GLASGOW_HASKELL)' | wc -l > 64 > > > As a user this is another bikeshedding change that is not going to benefit > me at all. Maintaining a Haskell library can be an exasperating exercise of > running on a treadmill to keep up with busywork caused by changes to the > core language and libraries. My feeling is starting to become that the > libraries committee is doing as much (if not more) to cause problems and > work for me than it is doing to improve the common infrastructure. > > G > -- > Gregory Collins <greg(a)gregorycollins.net> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

1 0

ANN: HaRe 0.8 - The Haskell Refactorer
by Alan & Kim Zimmerman 05 Oct '15

05 Oct '15

I'm pleased to announce the release of HaRe 0.8, available on hackage [1] What's new? =========== Everything, and nothing. Everything in the sense that it has been completely reworked internally to make use of the new API Annotations [2] in GHC 7.10.2, via the ghc-exactprint [3] library. Nothing in the sense that the functionality in this version is/should be identical to that in 0.7.2.8 Limitations =========== HaRe 0.8 will only work for projects using GHC 7.10.2 for compilation. Compiling HaRe with 7.10.2 and then using it against projects using an earlier compiler will not work, as HaRe needs to be able to invoke GHC to the type checker stage on the project using GHC 7.10.2. What is it? =========== HaRe makes changes to working code, so that it still works once the change is made. Refactorings it can do are * demote Take a declaration from the level where it is defined and move it down to the place where it is used. This only works if it is used in one place only. * dupdef Duplicate a definition with a new name. * iftocase Convert an if declaration to a case declaration. * liftOneLevel Move a declaration one level up, adding parameters as needed to pass in locally declared variables. * liftToTopLevel Move a declaration to the top level, adding parameters as needed to pass in locally declared variables. * rename Change a name throughout the project. This makes use of the GHC renamed source so will not change other names that just happen to be lexically identical, but are in fact different names. It currently has an emacs integration only, assistance in supporting other environnments welcome. [1] https://hackage.haskell.org/package/HaRe [2] https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations [3] https://hackage.haskell.org/package/ghc-exactprint Alan

4 6

Teaching haskell at the 42 french school
by Quentin Le Guennec 05 Oct '15

05 Oct '15

Hi, as an introduction, it would be a good advice to first look, if you did not heard of it yet, at what the 42 school is: http://www.42.fr/42-revolutionary-computer-training-free-and-open-to-all/ (TL;DR: *"unique pedagogical approach and accessibility to all, completely free of charge, 42 is the most daring response yet to the challenge of information-technology skill development", "**Innovative teaching methods in technology training: Peer-to-Peer learning"*) The school aims to teach a general knowledge of computer science, but does not provide a Haskell course yet. The exercices and projects are built by students, for students. I love haskell and I'd be really happy to teach that wonderful language, and I'd love to hear your suggestions. I was thinking of the haskell's hard learning way. (I gotta say, the school's pedagogy is pretty sadistic). - Recode List, (,), Either, Maybe and their functor/applicative/monad/etc instances (implying recode those data types first) - String manipulation (basically recode Data.List). Any ideas for prevent students from just copy pasting the hackage code source? - Red black trees are fun, aren't they? - Some kind of AI to solve, for example, Rubik's cube One other thing, this may be very sadistic, but I would like to ask what do you think of allowing ONLY pointfree? It may end-up by having different answers and promote beautiful and concise code. Please expose your ideas, everything is feasible, bonus added to traps, hard to solve problems, and everything that may lead the student to think a lot. Thanks. -- Quentin Le Guennec

2 1

[ANN] PETSc Haskell bindings
by Marco Zocca 05 Oct '15

05 Oct '15

Dear all, development of the Haskell bindings for the PETSc scientific computation library is now public; the repository can be found at https://github.com/ocramz/petsc-hs The interface is still very much experimental and in a state of flow but a number of basic functions are working. I look forward to all feedback; Kind regards, Marco Zocca

1 0

Concept for "equal but unknown"
by martin 05 Oct '15

05 Oct '15

Hello all, there is a problem which popped up a number of times recently and I wondered if there is a general concept to tackle this kind of problems. It goes like this: I book a hotel room. At this time it becomes known that the hotel has one fewer room available, but it is not known which room it is. Likewise I know, that I have a reservation for "a room", but I don't know which one it is. It is however known, that the room in my reservation is the same room the hotel has removed from the list of available rooms. Another example: In air-cargo the cargo company has reserverd space in an aircraft for two containers. One for high-priority parcels and one for low-priority parcels. In the cargo hub, they plan to pack these two containers. At this point in time it is only known that there will be two containers one labelled "high-prio" and the other labelled "low-prio" but their physical identity is not known. Only when you actually do the packing you have a physical container at hand, which has identity. At this moment it becomes clear to which physical containers the reservations refer to and which physical containers are used for packing. I think I can handle this in an imparative style using an extra indirection (think pointers), though even there I would be happy if someone told me something like "this is an example of covariant unification" or something like this. But in haskell I cannot see a solution at all? So: how can I express that two things are equal to each other without knowing the exact value and how do I manage to make both assume a value once one of them becomes known. Do these kind of problems have a name?

5 6

Approach to generalising Functor, is it worth pursuing?
by Clinton Mead 04 Oct '15

04 Oct '15

I've been thinking about generalising Functor, as I had something which was "Functor like" but didn't seem to fit into the existing definition. The example I'll present isn't the problem I was trying to solve, but it probably illustrates the solution better. The questions I have is: 1. Is this useful? 2. Has this been done? If the answers are Yes and No, I'll continue on into making this into a package. Anyway, here's what I've done: As we know, the type signature of fmap is the following: fmap :: Functor f => (a -> b) -> (f a -> f b) I've put brackets around the last two arguments to show that fmap can be also seen as a function which takes a function and returns a new function, in a different "space", for want of a better word. fmap should also follow this rule: fmap (f . g) == (fmap f . fmap g) So we can map an ordinary function into the "Maybe" space, but in a way that composing functions in the putting them in the space is the same as putting them in the space then composing them. I thought it would be nice if we could fmap to Kleisli Arrows, like so: fmap :: Monad m => (a -> b) -> Kleisli m a b Of course this is just "arr". But "arr" follows fmap's rules, so I thought it would be nice to make it a functor. So I was looking for more generalised versions of "Functor", and I found the 'categories' package, which had the following definition: class (Category <https://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Category.html…> r, Category <https://hackage.haskell.org/package/base-4.7.0.1/docs/Control-Category.html…> t) => Functor f r t | f r -> t, f t -> r where fmap :: r a b -> t (f a) (f b) This solves half my problem, as now I can set r = (->) and t = Kleisli m and I've got the categories right. But it forces the "output" category to have a data constructor. So: fmap :: Monad m => (a -> b) -> Kleisli m a b Just won't fit. I'd need to make it: fmap :: Monad m => (a -> b) -> Kleisli m (Id a) (Id b) and then unwrap the results. I found this ugly though. So I've gone with another approached. I've linked the code here: http://ideone.com/TEg4MN and also included it inline at the bottom of this mail. Defining functors now becomes a bit wordy, but basically what I've defined is two functor instances. The first is just a copy of the existing functor instances to maintain the status quo behaviour. But secondly I've defined the Kleisli instance as discussed above. The "main" line, does two calls to fmap. The outermost (on the left) is just an ordinary fmap call on lists. The innermost, fmaps the function "triple" into a Kleisli Arrow, allowing it to be composed with the the Kleisli arrow already defined, 'evenOrNothing'. Type inference works this all out magically without signatures being required. Like I said, is approach new and useful? Improvements would be appreciated also, I'm only over the last few months really started focusing on learning Haskell properly (after leaving my previous job of 8 years), so I'm sure I'm still doing plenty of things not quite right. Thanks, Clinton --- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} module Main ( main ) where import qualified Control.Arrow import Prelude hiding (Functor, fmap, (.)) import Control.Category (Category, (.)) import qualified Data.Functor import qualified Control.Arrow import Control.Arrow (Kleisli(Kleisli), runKleisli) type family F (r :: (* -> * -> *)) (t :: (* -> * -> *)) x type family InputParam f x type family ResultParam f x type family InputCategory f :: (* -> * -> *) type family ResultCategory f :: (* -> * -> *) class Functor f where fmap :: ( Category r, Category t, f ~ F r t c, f ~ F r t d, r ~ InputCategory f, t ~ ResultCategory f, a ~ InputParam f c, b ~ InputParam f d, c ~ ResultParam f a, d ~ ResultParam f b ) => r a b -> t c d data OrdinaryFunctor :: (* -> *) -> * type instance F (->) (->) (f a) = OrdinaryFunctor f type instance InputParam (OrdinaryFunctor f) (f a) = a type instance ResultParam (OrdinaryFunctor f) a = f a type instance InputCategory (OrdinaryFunctor f) = (->) type instance ResultCategory (OrdinaryFunctor f) = (->) instance (Data.Functor.Functor f) => Functor (OrdinaryFunctor f) where fmap = Data.Functor.fmap data KleisliFunctor :: (* -> *) -> * type instance F (->) (Kleisli m) a = KleisliFunctor m type instance InputParam (KleisliFunctor f) a = a type instance ResultParam (KleisliFunctor m) a = a type instance InputCategory (KleisliFunctor m) = (->) type instance ResultCategory (KleisliFunctor m) = Kleisli m instance (Monad m) => Functor (KleisliFunctor m) where fmap = Control.Arrow.arr triple = (*3) evenOrNothing = Kleisli (\x -> if (even x) then Just x else Nothing) main = print $ fmap (runKleisli (evenOrNothing . fmap triple)) [3..6]

2 1

HGamer3D 0.6.2
by Peter Althainz 03 Oct '15

03 Oct '15

Dear All, HGamer3D has some new features with version 0.6.2, see www.hgamer3d.org. Builds on Windows and Linux. with version 0.6 a switch was made towards a simpler structure and a new 3d library. regards Peter

1 0

Re: [Haskell-cafe] Parsing Atom feed link
by Adam Bergmark 02 Oct '15

02 Oct '15

Hi, This sounds like a good change to me! Are you willing to provide a patch (and maybe a testcase??) for this? - Adam On Sun, Sep 27, 2015 at 11:17 PM, fr33domlover <fr33domlover(a)riseup.net> wrote: > On Sat, 26 Sep 2015 10:15:24 +0200 > Francesco Ariis <fa-ml(a)ariis.it> wrote: > > > > > Since you have done the homework and this is rfc compliant, have you > > tried sending an email to the maintainer [1]? > > It seems an uncontroversial change and they are active (last version > > released in 2015), I bet they are be willing to fix this. > > > > [1] http://hackage.haskell.org/package/feed > > I sent the message to the maintainer too. I'm tempted to add a quick > temporary fix to my code, but hopefully this issue will get fixed soon > anyway. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >

2 2