Gabriel Gonzalez | 13 Aug 20:49 2013
Picon

(unknown)

My preference is to call the new transformer ExceptT, with a basic
monad called Except, in line with most of the other transformers, and
to deprecate ErrorT.  (The rationale for the name is that Either isn't
just for exceptions, and exceptions aren't just for errors.)

Specializing to an identity base monad is usually a misfeature in real code and only useful for pedagogical purposes.  Experts leave it polymorphic like this:

expertCode :: (Monad m) => EitherT E m R

By designing the API entirely around the identity specialization you're optimizing for a narrow skill range of intermediate Haskell programmers who are:

a) Smart enough to figure out that `ExceptT` is the official generalization of `EitherT`

b) Not smart enough to figure out how to keep the base monad polymorphic

So I propose that you leave the monad transformer name as `EitherT`, but use `Except` for the `Identity` specialization:

type Except e r = EitherT e Identity r

This has the nice properties that:

* The identity specialization doesn't conflict with `Either`

* Beginners find `transformers` when they search for `EitherT` as they inevitably will

* Existing packages that use `EitherT` won't break, thus preserving compatibility with the code bases that Edwards already mentioned

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Dag Odenhall | 13 Aug 22:50 2013
Picon

Re:

I don't see why we need type Except e r = EitherT e Identity r if it's exactly the same as Either anyway. We don't have this for MaybeT?



On Tue, Aug 13, 2013 at 8:49 PM, Gabriel Gonzalez <gabriel439 <at> gmail.com> wrote:
My preference is to call the new transformer ExceptT, with a basic
monad called Except, in line with most of the other transformers, and
to deprecate ErrorT.  (The rationale for the name is that Either isn't
just for exceptions, and exceptions aren't just for errors.)

Specializing to an identity base monad is usually a misfeature in real code and only useful for pedagogical purposes.  Experts leave it polymorphic like this:

expertCode :: (Monad m) => EitherT E m R

By designing the API entirely around the identity specialization you're optimizing for a narrow skill range of intermediate Haskell programmers who are:

a) Smart enough to figure out that `ExceptT` is the official generalization of `EitherT`

b) Not smart enough to figure out how to keep the base monad polymorphic

So I propose that you leave the monad transformer name as `EitherT`, but use `Except` for the `Identity` specialization:

type Except e r = EitherT e Identity r

This has the nice properties that:

* The identity specialization doesn't conflict with `Either`

* Beginners find `transformers` when they search for `EitherT` as they inevitably will

* Existing packages that use `EitherT` won't break, thus preserving compatibility with the code bases that Edwards already mentioned


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Gabriel Gonzalez | 13 Aug 22:57 2013
Picon

Re:

I don't really see the value in `Except` either, but it's there to satisfy Ross who wants an `Identity`-specialized version of the monad transformer.


On Tue, Aug 13, 2013 at 1:50 PM, Dag Odenhall <dag.odenhall <at> gmail.com> wrote:

I don't see why we need type Except e r = EitherT e Identity r if it's exactly the same as Either anyway. We don't have this for MaybeT?



On Tue, Aug 13, 2013 at 8:49 PM, Gabriel Gonzalez <gabriel439 <at> gmail.com> wrote:
My preference is to call the new transformer ExceptT, with a basic
monad called Except, in line with most of the other transformers, and
to deprecate ErrorT.  (The rationale for the name is that Either isn't
just for exceptions, and exceptions aren't just for errors.)

Specializing to an identity base monad is usually a misfeature in real code and only useful for pedagogical purposes.  Experts leave it polymorphic like this:

expertCode :: (Monad m) => EitherT E m R

By designing the API entirely around the identity specialization you're optimizing for a narrow skill range of intermediate Haskell programmers who are:

a) Smart enough to figure out that `ExceptT` is the official generalization of `EitherT`

b) Not smart enough to figure out how to keep the base monad polymorphic

So I propose that you leave the monad transformer name as `EitherT`, but use `Except` for the `Identity` specialization:

type Except e r = EitherT e Identity r

This has the nice properties that:

* The identity specialization doesn't conflict with `Either`

* Beginners find `transformers` when they search for `EitherT` as they inevitably will

* Existing packages that use `EitherT` won't break, thus preserving compatibility with the code bases that Edwards already mentioned


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
David Luposchainsky | 13 Aug 23:09 2013

Re:

On 2013-08-13 22:57, Gabriel Gonzalez wrote:
> I don't really see the value in `Except` either, but it's there to
> satisfy Ross who wants an `Identity`-specialized version of the monad
> transformer.

I think at this rate, we're running out of terms for "crashing" pretty
soon. Exception vs. error is bad enough, and now some want to add Except
to that list.

On the other hand, EitherT already exists in a current and used library,
it is very clear what that transformer does, and it goes hand in hand
with MaybeT.

Furthermore I think Hennings objections are not very convincing:

- Monad for pairs duplicates Writer, which is existing functionality but
without the newtype wrapper safety. There is no equivalent for this with
Either.

- Num for functions - I have yet to see an example where that is
beneficial beyond "funny how that works".

- Ord for complex numbers is alarming for the mathematics police, but a
useful hack if you want to store them in a Map or something. A class
"ArbitraryOrd" would be better for this, but for the time being we're
stuck to using newtype wrappers. I don't see what's mathematically wrong
with EitherT (neither on this scale nor on any other).

David
Henning Thielemann | 14 Aug 10:49 2013
Picon

Re: ExceptT vs. EitherT

Am 13.08.2013 23:09, schrieb David Luposchainsky:
> On 2013-08-13 22:57, Gabriel Gonzalez wrote:
>> I don't really see the value in `Except` either, but it's there to
>> satisfy Ross who wants an `Identity`-specialized version of the monad
>> transformer.
>
> I think at this rate, we're running out of terms for "crashing" pretty
> soon. Exception vs. error is bad enough, and now some want to add Except
> to that list.
>
> On the other hand, EitherT already exists in a current and used library,
> it is very clear what that transformer does, and it goes hand in hand
> with MaybeT.
>
> Furthermore I think Hennings objections are not very convincing:

In all cases I listed you can define an instance that is mathematically 
sound, that is, it fulfills some nice laws. But from the view of a 
programmer, I want additionally safety. I want that programs are 
rejected that are "obviously" wrong.

Returning to "Either": You can define a monad instance on it that 
fulfills all monad laws, i.e. it is mathematically sound. This instance 
already exist. But for me Either is just a plain set sum, a union type. 
I may use it for lists that may contain two types of elements. I may use 
it for constructing larger sum types without the need to define a new 
'data'. This is for example useful in GHCi. But then - why should this 
type also be a monad, where the Left and Right are handled very 
differently? When I want to have the exception semantics I prefer to 
make that explicit using the Except type. (Currently I use my own 
Exceptional type for that purpose.)

My general concern is that the discussion is focussed on whether an 
instance fulfills mathematical laws, but not on software engineering 
aspects. Although some types are structurally equivalent (Either and 
Except, pair and Writer, function and Reader monad), they have very 
different uses. If I want to combine two types in one, I want to express 
this by Either. If I want exception handling, I want to express this by 
Except. Either should not have a monad instance, and Except should not 
have a function like partitionEithers.

A strength of Haskell's type system is safety. Safety means that certain 
things are forbidden. In contrast to that, a discussion focussed on 
fulfilling mathematical laws tends to allow as much as possible. On the 
one hand we encourage people to artificially make types distinct by 
newtype wrapping. E.g. we define newtype Id = Id Int, in order to forbid 
arithmetic operations that are useless for Id's. On the other hand we 
throw together many applications to a single type by defining more and 
more instances for base types and base classes. In the long run we end 
up with MATLAB semantics: They put so much applications into one type 
(complex valued tensors used for bools, reals, complex numbers, 
polynomials, matrices, graphs etc.) that you better not touch a working 
program, if you want to keep it running.

That said, instance Monad Either and instance Monad (->) already exist. 
We cannot remove them easily, because may people rely on them. However, 
we can discourage their use and propose the clean way via types from the 
transformers package. Then the exception handling monad in 
'transformers' should not have a name that resembles "Either", because 
its use is very different from a plain union type. For me "Exept" is a 
good choice, because the intended application is exception handling.

> - Monad for pairs duplicates Writer, which is existing functionality but
> without the newtype wrapper safety. There is no equivalent for this with
> Either.

In transformer the Writer monad could also have been defined as

   data Writer w a = Writer a w

and vice versa the Except monad could be defined by

   newtype Except e a = Except (Either e a)

I don't think there is a substantial difference. I order to be 
consistent with the current style of type definitions in 'transformers', 
I think the definition will be:

   newtype ExceptT e m a = ExceptT (m (Either e a))
   type Except = ExceptT e Identity a

> - Num for functions - I have yet to see an example where that is
> beneficial beyond "funny how that works".

I guess that people liked to write sin+cos or 2*exp. If not, there must 
be enough other reasons to publish
   http://hackage.haskell.org/package/NumInstances
David Luposchainsky | 14 Aug 11:24 2013

Re: ExceptT vs. EitherT

On 2013-08-14 10:49, Henning Thielemann wrote:

> In all cases I listed you can define an instance that is mathematically
> sound, that is, it fulfills some nice laws. But from the view of a
> programmer, I want additionally safety. I want that programs are
> rejected that are "obviously" wrong.
> 
> Returning to "Either": You can define a monad instance on it that
> fulfills all monad laws, i.e. it is mathematically sound. This instance
> already exist. But for me Either is just a plain set sum, a union type.
> I may use it for lists that may contain two types of elements. I may use
> it for constructing larger sum types without the need to define a new
> 'data'. This is for example useful in GHCi. But then - why should this
> type also be a monad, where the Left and Right are handled very
> differently? When I want to have the exception semantics I prefer to
> make that explicit using the Except type.
>
> [...]
> 
> In transformer the Writer monad could also have been defined as
> 
>   data Writer w a = Writer a w
> 
> and vice versa the Except monad could be defined by
> 
>   newtype Except e a = Except (Either e a)
> 
> I don't think there is a substantial difference. I order to be
> consistent with the current style of type definitions in 'transformers',
> I think the definition will be:
> 
>   newtype ExceptT e m a = ExceptT (m (Either e a))
>   type Except = ExceptT e Identity a

That sounds very convincing (I didn't think making an Either newtype was
up for discussion). I still don't think "ExceptT" makes a very good
name, but that's a negligible issue.

David
Okasaki, C. DR EECS | 17 Jan 17:29 2006
Picon

Re:

I wrote:
> You've just highlighted why the collections hierarchy in 
> Edison was a lattice of 8 classes.  Basically, there are
> two choices in each of three different dimensions:
>
>  1. The set/map distinction
>  2. Require Ord or don't (your first point above)
>  3. "Observable" or not (your second point above)

Oops, I typed too fast.  Edison actually has two choices in each of four
different dimensions.  The first is the set/map distinction, but those
are in two separate class hierarchies.  Within each of those class
hierarchies, the three dimensions are Ord/not, Observable/not, and
"unique"/not, where the last dimension is the difference between sets
and bags.

-- Chris

Gmane