
On Thu, 8 Mar 2012, Edward Kmett wrote:
On Thu, Mar 8, 2012 at 6:09 AM, Henning Thielemann
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 http://www.haskell.org/pipermail/libraries/2011-August/ http://www.haskell.org/pipermail/libraries/2011-September/ 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'.