LAST CALL to comment on the Applicative/Monad Proposal

[Henrik Nilsson]

Hi all,

Well, I am in favour of discussing AMP and MRP separately because:

   a) As far as I am aware, there is no compelling *technical*
      reason for not doing so.

   b) On balance, this is the path most likely to result in some
      progress on this issue.

Of course, if there *is* a fundamental technical reason for why
the AMP, MFP, and MRP all *must* be discussed together, then
please put this forward.

As to the underlying issue, I don't agree that AMP on its own
somehow is not "clean". But of course, design is something where
reasonable people may choose to disagree. (Which in itself strongly
suggests that it makes sense to strive to consider technically
independent proposals separately.)

The rationale for my position is:

   a) The remaining legacy issues raised by MRP significantly outweighs
      any technical benefits.

   b) Keeping "return" as a monadic *method* would in principle (through
      a minor language extension that has been proposed separately for
      different reasons) allow both Functor and Applicative instances to
      be defined in terms of a Monad instance.

The latter is really useful in a situation where one genuinely only
cares about the monad, makes perfect sense mathematically of course,
and would go a long way towards alleviating the genuine difficulties of
teaching monads that AMP did bring about, as reported by a number of
*very* experienced educators.

But clearly this is a separate discussion. Which is why AMP, MRP, and
MFP should be considered separately.

One high-level perspective on this is the well-established possibility 
in Haskell of defining an instance of a class by only giving
definitions of a subset of its methods where methods are interdefinable.

Many methods in the Functor/Monad/Applicative hierarchy are similarly
interdefinable, but spread over more than one class. But in principle,
choosing to define e.g. "fmap" in terms of the monadic methods,
or "pure" in terms of "return", or vice versa for that matter,
is not very different from the choice between defining a monad in
terms of bind or join.

Best,

/Henrik



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 contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.