new major release of transformers package
lemming at henning-thielemann.de
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 henning-thielemann.de> 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