new major release of transformers package

Henning Thielemann lemming at
Thu Mar 8 21:26:40 CET 2012

On Thu, 8 Mar 2012, Edward Kmett wrote:

> On Thu, Mar 8, 2012 at 6:09 AM, Henning Thielemann <lemming at> wrote:
> I'd prefer to call them stateT, readerT, writerT in order to keep 'state', 'reader', 'writer'
> with the restricted types. The restricted type should work without type annotations in cases
> where I really only want type 'State'. Actually stateT, readerT, writerT are only alternative
> constructors for StateT, ReaderT, WriterT with a restriction on 'm'.
> There was a discussion period on this about 6 months ago. We're just now finally getting it all
> integrated. I'd rather not add new names for the same operations.

I can't remember that. I just scanned
  and did not find the keyword "transformer".

Nevertheless, Ross is right that the proposed 'state' function is still 
closer to the old 'state' function than to the current 'StateT' 
constructor. Maybe the problem with type inference is not as bad as I 
thought first, since evalState will keep the restricted State type. Thus a 
combination of evalState and state in the same function will still work 
without type annotation. If evalState and state are in separate functions, 
then the type signature of the functions will fix the type to State.

It's just that I originally proposed the 'state' function as a replacement 
for the 'State' constructor that was gone due to redefining 'State s' as 
type synonym to 'StateT s Identity'.

More information about the Libraries mailing list