- Haskell-prime - Haskell.org

In opposition of Functor as super-class of Monad
by oleg＠okmij.org 08 Jan '11

08 Jan '11

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. For the sake of the argument, let us suppose that Functor is a superclass of Monad. Let us see how to define a new Monad instance. For the sake of a better illustration, I'll use a complex monad. I just happen to have an example of that: Iteratee. The data type Iteratee is defined as follows: > type ErrMsg = String -- simplifying > data Stream el = EOF (Maybe ErrMsg) | Chunk [el] deriving Show > > data Iteratee el m a = IE_done a > | IE_cont (Maybe ErrMsg) > (Stream el -> m (Iteratee el m a, Stream el)) We wish to define an instance for Monad (Iteratee el m). Since Functor is a superclass of Monad, we must define a functor instance: > instance Functor m => Functor (Iteratee el m) where > fmap f (IE_done a) = IE_done (f a) > fmap f (IE_cont e k) = IE_cont e (\s -> fmap docase (k s)) > where > docase (IE_done a,s) = (IE_done (f a), s) > docase (i, s) = (fmap f i, s) There are two ways to proceed with the Monad instance -- to be precise, there are two ways of defining bind. Method A: just define bind as usual > instance (Functor (Iteratee el m),Monad m) => Monad (Iteratee el m) where > return = IE_done > > IE_done a >>= f = f a > IE_cont e k >>= f = IE_cont e (\s -> k s >>= docase) > where > docase (IE_done a, stream) = case f a of > IE_cont Nothing k -> k stream > i -> return (i,stream) > docase (i, s) = return (i >>= f, s) Although we must state the constraint (Functor (Iteratee el m)) to satisfy the super-class constraint, we have not made any use of the constraint. We defined bind without resorting to fmap. That seems like a waste. What makes it seem more like a waste is that the code for fmap and for bind is almost the same. We had to repeat essentially the same algorithm, analysing Iteratee and the continuation. Method B: define bind in terms of fmap Alas, just fmap is not sufficient to define bind. We need join: > joinIter :: Monad m => Iteratee el m (Iteratee el m a) -> Iteratee el m a > joinIter (IE_done i) = i > joinIter (IE_cont e k) = IE_cont e (\s -> k s >>= docase) > where > docase (IE_done (IE_cont Nothing k), s) = k s > docase (IE_done i, s) = return (i, s) > docase (i, s) = return (joinIter i, s) Only after defining join we can write > bind m f = joinIter $ fmap f m Again we see code duplication: the code for join resembles the code for fmap. The code for join follows the same pattern of analysing Iteratee and the continuation. In either way, Functor as a super-class of Monad leads to code duplication. That gives a bad feeling practically -- and theoretically. The experiment has led me wonder if a superclass constraint is the right way to state the relationship between Monads and Functors. It _almost_ makes me wish the constraint go the other way: > instance Monad m => Functor m where > fmap f m = m >>= (return . f) That is, we need an instance rather than a superclass constraint, and in the other direction. The instance constraint says that every monad is a functor. Moreover, \f m = m >>= (return . f) is a _proof term_ that every monad is a functor. We can state it once and for all, for all present and future monads. Alas, the instance ``instance Monad m => Functor m'' above has several drawbacks (for one, requiring overlapping instances everywhere). This makes me wonder if something is amiss. In the meanwhile, there is a practical work-around. Introduce a TemplateHaskell operation generating an instance such as > instance Monad (Iteratee el m) => Functor (Iteratee el m) where > fmap f m = m >>= (return . f) (the code for the method remains the same; only the type in the instance head varies). Alas, that requires undecidable instances. All the code before was Haskell98.

12 13

Functor hierarchy proposal and class system extension proposal
by Howard B. Golden 07 Jan '11

07 Jan '11

Hi, In 2006, Ashley Yakeley proposed the functor hierarchy proposal (http://www.haskell.org/haskellwiki/Functor_hierarchy_proposal) and, in 2007, Brianh (his wiki handle since I don't know his name) proposed the class system extension proposal (http://www.haskell.org/haskellwiki/Class_system_extension_proposal) I recently Googled these proposals and didn't see any significant discussion since they were originally proposed. If there has been some, please point me to it so I can read it. Making functor a superclass of monad has the benefit of consistency with the mathematical definitions. It may also simplify the libraries. The class system extension proposal makes it possible to inherit the default implementations of functions from a superclass, thus simplifying the code that would otherwise be required to create a monad if the functor hierarchy proposal is adopted. Is there any interest in considering these proposals for the next iteration of Haskell'? Cheers, Howard B. Golden Northridge, California, USA

6 8

Haskell 2011?
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, I haven't heard anything about Haskell 2011 since http://www.haskell.org/pipermail/haskell-prime/2010-August/003263.html Can someone let me know what's happening please? Will there be a Haskell 2011? Thanks Ian

2 1

ExplicitForAll complete
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, I've completed the ExplicitForAll proposal, started by Niklas Broberg (but any errors are doubtless mine!): http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall http://hackage.haskell.org/trac/haskell-prime/ticket/133 I imagine this is too late for H2011 (if that will actually be happening?), but there wasn't an H2012 milestone, so I put it in H2011 anyway. Please feel free to remilestone. Thanks Ian

5 8

Small report fixes
by Ian Lynagh 23 Dec '10

23 Dec '10

Hi all, I've made a couple of tickets for small fixes to the report: http://hackage.haskell.org/trac/haskell-prime/ticket/140 http://hackage.haskell.org/trac/haskell-prime/ticket/141 Thanks Ian

2 1

Re: [Haskell] typo in Haskell definition
by Yitzchak Gale 20 Nov '10

20 Nov '10

Moving this to the haskell-prime list, where perhaps someone will notice it. Serge D. Mechveliani wrote: > Looking into the on-line Haskell-2010 definition, > I see in the Library definition > > 20.4.3 ... > iteratef (instead of "iterate f"), > repeatx (instead of "repeat x"). Also, replicaten x (instead of "replicate n x"). Thanks for the report. I don't seem to be able to log in to the trac, so perhaps someone else will submit the ticket. Thanks, Yitz

2 1

Add haskell-src as an official machine-readable component of the Haskell standard
by Yitzchak Gale 18 Nov '10

18 Nov '10

I propose that the haskell-src package be renamed haskell20nn-src for each revision Haskell 20nn of the standard, and be made an official machine-readable component of the standard. This has the following advantages: 1. It would require almost no extra work, because haskell-src already exists, and syntax changes, if any, will be very minimal for each revision. 2. For the portion of the standard that it covers, any ambiguity that might creep into the human-readable standard document would be resolved. 3. It would serve as a basic machine-verification tool which is easily extensible. 4. As a side-effect, the haskell-src package would be continually maintained. The package is useful in its own right as a much lighter-weight version of haskell-src-exts. It is much easier to use when an application does not require full support of all of Haskell's syntax. This proposal is a natural extension of a proposal raised on the libraries mailing list in the context of the Haskell Platform: Ian Lynagh proposed that the current haskell-src-exts be renamed haskell-src (and included in the Haskell Platform, as suggested by Sterling Clover), and that the current haskell-src be renamed to haskell98-src (and removed from the Platform). The libraries subthread is here: http://www.haskell.org/pipermail/libraries/2010-November/015018.html Thanks, Yitz

6 11

Add haskell-src as an official machine-readable component of the Haskell standard
by Yitzchak Gale 18 Nov '10

18 Nov '10

Ben Millwood wrote: > But if we make the official parser usable for AST manipulation, we > have to rule on the design issues I raised above: whether to make > efforts to stop invalid lambdas being constructed, how to name the > types and constructors, etc. No we don't. With regard to its inclusion as part of the standard, we make only one guarantee - that it serves to verify whether code is compliant to the standard. For your convenience, the package maintainer will try to make it useful for other things too, but in that respect it is no different than any other package on Hackage. > What purpose does it serve that a Haskell > parser independent of the report does not? Machine verification of Haskell 20nn standards compliance. > We can't guarantee it's bug-free We can't guarantee that the human-readable part of the standard is bug-free, either. It always has had bugs and it always will, like any standard. We do the best we can. Actually, there is the possibility of developing an automated system to generate unit tests from the standards document to verify the consistency of the parser with the document. Those same unit tests could then also be used by compiler writers to certify the compliance of their Haskell 20nn mode and do regression testing. There are many intriguing possibilities. > I suppose providing a reference parser at least ensures that any > modification to Haskell syntax is implementable, and the issues in its > implementation will have been considered Yes that is one of the advantages of this approach. > but in practice every > alteration to the Haskell language from now on is going to be > standardising extensions that already exist, so I don't really think > this is a priority. For you it may not be a priority. But for enterprise project architects who are required to consider and document every possible risk before agreeing to adopt Haskell, it is a priority. Regards, Yitz

2 2

Re: Add haskell-src as an official machine-readable component of the Haskell standard
by S. Doaitse Swierstra 17 Nov '10

17 Nov '10

On 17 nov 2010, at 16:21, Ben Millwood wrote: On Wed, Nov 17, 2010 at 8:52 AM, Yitzchak Gale <gale(a)sefer.org> wrote: >> Reading this proposal I think it clearly states my point made earlier: allowing infix specifications everywhere provides unneeded flexibility and unnecessary complexity. >> >> Ideally I would like to see them even before the module keyword: they state how to read the text that follows, and thus fall in the category of: >> >> - LANGUAGE pragma's which add sometimes extra syntax >> - import's, which extend the name space >> >> Restricting them to occur only directly after the imports is something I cannot see anyone to object to, and would enable the immediate correct parsing of all expressions to follow. >> >> Doaitse >> > > This is an interesting idea! It would certainly solve a fair few > issues with fixity parsing, but I worry that we'd lose a lot of > consistency, and/or gain a lot of redundancy - we want operators to > associate the same way in every file, but people will have different > ideas about which way to associate what (I like associating $ to the > left, but I generally don't for the sake of my readers' sanity). > Plus, like explicit import lists, I suspect that a list of all > operators used in the program, potentially some distance away from > their usage site, is going to invite subtle errors when people forget > to add one, redundancy when people forget to remove one, and noise in > patch files when people do the right thing. So as much as I want to > see Haskell's infix syntax simplified, I'm not sure this is a > practical way to do so. I once had the idea of having fixity > determined in some sense by the name of the operator - long operators > binding more tightly/loosely than short ones, or an angle bracket in > the right place changing the associativity - but I don't think there's > any satisfactory way of doing that either. That is why I refined the proposal in my last sentence to only allowing them after the import's. It is also the only way I see programming environments ever becoming "priority aware". Doaitse _______________________________________________ Haskell-prime mailing list Haskell-prime(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

1 0

Re: Add haskell-src as an official machine-readable component of the Haskell standard
by S. Doaitse Swierstra 17 Nov '10

17 Nov '10

Reading this proposal I think it clearly states my point made earlier: allowing infix specifications everywhere provides unneeded flexibility and unnecessary complexity. Ideally I would like to see them even before the module keyword: they state how to read the text that follows, and thus fall in the category of: - LANGUAGE pragma's which add sometimes extra syntax - import's, which extend the name space Restricting them to occur only directly after the imports is something I cannot see anyone to object to, and would enable the immediate correct parsing of all expressions to follow. Doaitse On 17 nov 2010, at 08:55, Simon Peyton-Jones wrote: > See http://hackage.haskell.org/trac/ghc/ticket/4430 for what we are proposing for Template Haskell. > > S > > > | -----Original Message----- > | From: haskell-prime-bounces(a)haskell.org [mailto:haskell-prime-bounces@haskell.org] On > | Behalf Of Lennart Augustsson > | Sent: 16 November 2010 19:52 > | To: Ben Millwood > | Cc: haskell-prime(a)haskell.org > | Subject: Re: Add haskell-src as an official machine-readable component of the Haskell > | standard > | > | Please explain. Fixity information cannot be provided unless you find > | all the imported modules and process those, so I'm not sure how > | haskell-src-exts could do any better than it currently does. > | > | > > | > (Examples of controversies possible in haskell-src: we have the Hs > | > prefix on constructors everywhere, we can't provide fixity information > | > (and the haskell-src-exts implementation of this is unsatisfactory in > | > several important ways), a lot of type class instances are absent > | > (even Ord!), the distribution of SrcLocs is a little awkward when > | > manipulating source abstractly, and some constructors allow impossible > | > values, e.g. HsLambda can contain zero patterns) > | _______________________________________________ > | Haskell-prime mailing list > | Haskell-prime(a)haskell.org > | http://www.haskell.org/mailman/listinfo/haskell-prime > > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime

1 0