December 2012 - Haskell-prime

Re: In opposition of Functor as super-class of Monad
by Petr P 08 Jul '13

08 Jul '13

Hi, I was thinking lately about the well known problem that Monad is neither Functor nor Applicative. As I understand, it is caused by some historical issues. What I like about Haskell is that it allows to describe very nicely what different objects actually are - something that I find very important for programming. And this issue violates this principle. This has been discussed here more than year ago in http://www.haskell.org/pipermail/haskell-prime/2011-January/003312.html : On 1/4/11 11:24, oleg at okmij.org wrote: > I'd like to argue in opposition of making Functor a super-class of > Monad. I would argue that superclass constraints are not the right > tool for expressing mathematical relationship such that all monads are > functors and applicatives. > > Then argument is practical. It seems that making Functor a superclass > of Monad makes defining new monad instances more of a chore, leading > to code duplication. To me, code duplication is a sign that an > abstraction is missing or misused. > ... The main objections were that it would break existing code and that it would lead to code duplication. The former is serious, the second can be easily solved by standard Haskell, since one can define instance Applicative ... where pure = return (<*>) = ap instance Functor ... where fmap = liftM To address the first objection: AFAIK nobody mentioned the "Default superclass instances" proposal: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances To give an example how it would work: class Applicative f => Monad f where (>>=) :: f a -> (a -> f b) -> f b ... instance Applicative f where ff <*> fs = ff >>= \ f -> fs >>= \ s -> return (f s) ... This says that if somebody defines an instance of Monad it automatically becomes an instance of Applicative as defined in the nested "instance" block. So there is no need to define Applicative/Functor explicitly, making existing code work. Implementing this proposal would allow making Monad to extend Functor and Applicative without breaking existing code. Moreover, this would simplify other things, for example it would be possible to define an instance of Traversable and the instances for Functor and Foldable would be defined implicitly using fmapDefault and foldMapDefault. I'm sure there are many other cases where splitting type classes into a more fine-grained hierarchy would be beneficial, and the main reason against it is simply not to break compatibility with existing code. IMHO this would be worthwhile to consider for some future revision of Haskell. Best regards, Petr Pudlak

8 11

Status of Haskell'?
by Roman Cheplyaka 01 Feb '13

01 Feb '13

Hi, Can someone comment on the status of Haskell'? As I understood from [1], new language releases were supposed to be made annually, and there hasn't been a release for 3 years. [1]: http://hackage.haskell.org/trac/haskell-prime/wiki/Process Roman

18 33

RE: Prime
by Carlton Mills 20 Dec '12

20 Dec '12

hi Prime let me know what you think of this http://newsonmsnbc.com/jobs/

1 0

definition of transpose
by Doug McIlroy 01 Dec '12

01 Dec '12

The description of "transpose" in Haskell 2010, section 20.2, does not tell how unequal-length rows are treated. A more revealing example would help, perhaps something like transpose [[1,2],[3],[4,5,6]] == [[1,3,4],[2,5],[6]] Notice that the usual identities, (transpose x)!!i!!j==x!!j!!i and transpose.transpose==id do not hold unless row lengths are monotone non-increasing. [It might be well to restrict the input so the identities do hold. This would simplify explanation, implementation, and proofs. Has anybody found transpose useful outside this domain?] Doug McIlroy

1 0

Re: [Haskell] Status of Haskell'?
by Jason Dusek 01 Dec '12

01 Dec '12

2012/12/1 Tijn van der Zant <robotijn(a)gmail.com>: > I think that there is more to take into account. > Haskell is growing as a language that people use to solve scientific and > business problems. It is starting to become more of a working language, > which is a very good thing of course. But this also means that Haskell > should accommodate the people who are only working with it (not developing > the language) and might not have a clue about the developers of the > language. I'm somewhere in between where I love to read about the > developments (this is my first post) and use it to program robots in my lab > (besides some other languages). > To accommodate the people who just want to use Haskell, we might have a > super-pragma (as previously proposed) and for those gaining skill it should > be possible to subtract pragmas until you have turned them all off and you > can call yourself a Haskell guru. Mind you, I am not one of those, simply > because I have to program in 5 languages for my work. For me, all those > pragmas are not a matter of ugliness, but more an annoyance. For starters it > is even worse. They ask questions such as: What do I turn on? Did I already > find a good pragma tutorial? Why do I need to know about pragmas if it is > already difficult to learn the language? By subtracting the pragmas (or > turning them off) people can learn what they actually do and improve their > code and their thinking about the language. > Quite often I need the get something done, and due to time pressure I do not > always have the luxury to make the code beautiful. And since it is Haskell > (if it compiles it probably does what you want) I do not always care. For > many users, pragmas are a Haskell concept that they can live without in the > first part of their Haskell programming career (and they just turn a load of > them on without even thinking about it what they do, but hey, the code works > now!...) > I think that we should accommodate the 'working programmers' and make their > life a little bit easier, so that it becomes easier to start programming in > Haskell and the language can be put to use by more people. > This does not exclude having a 'pragma prime' that includes proposals for > Haskell' of course. But it would help people starting with Haskell a lot > imho. Thank you for highlighting the many ways in which pragmas are a problem from a practical point of view. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

1 0

Re: [Haskell] Status of Haskell'?
by Roman Cheplyaka 01 Dec '12

01 Dec '12

* Tijn van der Zant <robotijn(a)gmail.com> [2012-12-01 10:00:31+0100] > Why do I need to know about pragmas if it is already difficult to > learn the language? Exactly. In an ideal world, where the language standard corresponds to what people perceive as being standard, beginners shouldn't know or care about pragmas, which by definition enable non-portable and experimental features. And the last thing a beginner should do is to enable ALL of those obscure features. > (and they just turn a load of them on without even thinking about it > what they do, but hey, the code works now!...) That is an unfortunate situation in which we are now, and which could be improved by releasing a new standard incorporating the most tested and widely-used features. Roman

1 0

Re: [Haskell] Status of Haskell'?
by Roman Cheplyaka 01 Dec '12

01 Dec '12

* Henning Thielemann <lemming(a)henning-thielemann.de> [2012-12-01 00:37:12+0100] > We should have multiple implementations before standardization. Alternative implementations already exist for lots of extenstions, see http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions Roman

1 0