headers
Edward Kmett | 1 Dec 2009 02:02
Picon
Gravatar

Re: MTL vs Transformers. Any status update?

On Mon, Nov 30, 2009 at 6:50 PM, Ross Paterson <ross <at> soi.city.ac.uk> wrote:

On Sun, Nov 29, 2009 at 07:29:47PM -0500, Edward Kmett wrote:
> The final issue is whether or not it is a good idea to eliminate the
> simpler non-transformer versions of the monads.
>
> Without them, libraries that provide instances for the various monads
> cannot provide instances for State and StateT in a way that lets them
> work compatibly with both versions.
>
> So, an issue that I would like to talk about separately is if we
> _should_ be dropping the basic State, Reader, Writer, etc. constructors.
> They have definite pedagogical value, and have easier to understand
> behavior for introductory purposes.  If we kept those then ALL code
> that worked with mtl 1.2 would be compatible with mtl 2, which strikes
> me as a desirable property.  This has the benefit that it is easier
> to write libraries that export instances.  I think we would be remiss
> in not at least considering the issue.  On the other hand, I don't
> know how many libraries provide instances for the monads in the MTL.
> I have a few in my monoids library, but I'd be willing to go either way.

The benefit of defining these as type synonyms is that the Haskell 98
transformers package has the same functions operating on both the base
monad and the corresponding transformer; there is no need to define two
versions of everything.  Similarly fewer instances are required in the
monad class packages.

True. Like I said, I'd be happy with either way.
 
I think the pedagogical issue can be handled in other ways, and that
making compatibility with the current mtl an overriding requirement
would be unduly constraining.  In any case there would be no complete
compatibility, as transformers adds Applicative and Alternative instances,
and also changes the constraints on Functor instances.

I agree that perfect backwards compatibility is impossible. That said, unlike the type aliases, these are all cases where something new would work that didn't previously. Library code that wanted to be backwards compatible could avoid using the new instances, and the more permissive Functor instances shouldn't break any code that worked before unless that code was defining its own local version of Applicative, Alternative, etc. which were constrained by the restrictive Functor definitions to not work in the most permissive form anyway, so where needed, library code could work around using WrappedMonad, etc. in a way that would be compatible.

It is true, that it would constrain the design of the mtl to carry a handful of handy (or burdensome, depending on your perspective) tutorial constructors around, but note that the functions themselves for working with the simpler type are still contained in transformers, so the function count doesn't really change either way. But the other way says that all of the libraries that re-export functionality on top of the mtl must discard coverage of the non-transformer case when linked against the old mtl.

Both options suck, but only one provides no way out except to force someone up to the new version that they may not be able to use because of other package requirements. I have yet to see any major migration to a new version of a library that isn't more or less plug in compatible with the old version actually take hold (witness current adoption levels of parsec 3 & quickcheck 2). 

I hope this doesn't across as too cynical. I just figured that someone should play devil's advocate, before things got drowned in a sea of +1s.

-Edward Kmett


_______________________________________________
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
Permalink | Reply | 0 comments |
headers
Johan Tibell | 1 Dec 2009 08:19
Picon
Gravatar

Re: [network] new tickets submission unavailable

Hi,

On Mon, Nov 30, 2009 at 6:34 PM, Valery V. Vorotyntsev
<valery.vv <at> gmail.com> wrote:
> On Mon, Nov 30, 2009 at 6:39 PM, Antoine Latter <aslatter <at> gmail.com> wrote:
>> My user (AntoineLatter) gets the following error when navigating to that URL:
>>
>>>>>>>
>> Forbidden
>>
>> TICKET_CREATE privileges are required to perform this operation
>> <<<<<
>
> +1

This is new. I'll file a ticket to community [at] haskell.org for it.

Thanks,

Johan
Permalink | Reply | 0 comments |
headers
Mietek Bąk | 1 Dec 2009 12:25
Picon

Re: Guarantees regarding finalizers

> The docs are rather backward.  Foreign.ForeignPtr finalizers are guaranteed
> to run, Foreign.Concurrent finalizers are not.  I'll fix the docs, thanks
> for the report.

Thanks for the reply.  Unfortunately, I'm running into the following
error message when trying to use a Foreign.ForeignPtr finalizer:

"foo: error: a C finalizer called back into Haskell.
   This was previously allowed, but is disallowed in GHC 6.10.2 and later.
   To create finalizers that may call back into Haskll, use
   Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr."

Is there a technical reason why the Foreign.Concurrent finalizers
aren't guaranteed to run?

Best regards,

--

-- 
Mietek Bąk
Permalink | Reply | 1 comment |
headers
Simon Marlow | 1 Dec 2009 13:13
Picon

Re: Guarantees regarding finalizers

On 01/12/2009 11:25, Mietek Bąk wrote:
>> The docs are rather backward.  Foreign.ForeignPtr finalizers are guaranteed
>> to run, Foreign.Concurrent finalizers are not.  I'll fix the docs, thanks
>> for the report.
>
> Thanks for the reply.  Unfortunately, I'm running into the following
> error message when trying to use a Foreign.ForeignPtr finalizer:
>
> "foo: error: a C finalizer called back into Haskell.
>     This was previously allowed, but is disallowed in GHC 6.10.2 and later.
>     To create finalizers that may call back into Haskll, use
>     Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr."
>
> Is there a technical reason why the Foreign.Concurrent finalizers
> aren't guaranteed to run?

It's hard to make it work reliably, and arguably finalizers shouldn't be 
used in this way [1].

Haskell finalizers are run in separate threads, but separate threads 
don't normally prevent the Haskell program from exiting, so there would 
be an inconsistency if we made a special case for finalizers. Another 
problem is that you often find you need to express dependencies between 
finalizers, but that is not supported (the finalizers all run 
concurrently), and even if it were supported, it would probably be 
necessary to run the GC repeatedly until we run out of finalizers.

Cheers,
	Simon

[1] "Destructors, Finalizers, and Synchronization", Boehm, Hans-J.
     http://www.hpl.hp.com/techreports/2002/HPL-2002-335.html
Permalink | Reply | 0 comments |
headers
Duncan Coutts | 1 Dec 2009 13:47

Re: MTL vs Transformers. Any status update?

On Mon, 2009-11-30 at 23:50 +0000, Ross Paterson wrote:

> I think the pedagogical issue can be handled in other ways, and that
> making compatibility with the current mtl an overriding requirement
> would be unduly constraining.  In any case there would be no complete
> compatibility, as transformers adds Applicative and Alternative instances,
> and also changes the constraints on Functor instances.

I'd advocate doing it the "best" way, whatever the experts agree that
is. Then we can handle the transition using the tools and procedures
available.

The reason I suggest calling it mtl-2 is not for compatibility but to
make it easier to explain to package authors what we recommend they do.

Duncan
Permalink | Reply | 0 comments |
headers
Gracjan Polak | 2 Dec 2009 15:14
Picon

HaXR, maintainer

Hi libraries!

There is a beautiful HaXR XML-RPC client and server library out there that I use
in connection with BlogLiteratively. I needed to change HaXR a bit to support my
language encoding (Polish). 

http://hackage.haskell.org/package/haxr

If nobody else steps up I'd like to take maintainership of HaXR.

I have preliminary encouragement from Sigbjorn Finne, the original author.

So, let the patches flow to me!

--

-- 
Gracjan
Permalink | Reply | 1 comment |
headers
Gracjan Polak | 2 Dec 2009 16:21
Picon

Re: HaXR, maintainer

Gracjan Polak <gracjanpolak <at> gmail.com> writes:
> 
> ... Sigbjorn Finne, the original author.
> 
that be Bjorn Bringert, sorry about the confusion.

--

-- 
Gracjan
Permalink | Reply | 0 comments |
headers
Robin Green | 2 Dec 2009 06:27
Gravatar

Patches and forks for GHC 6.12

Some packages will need modifications to build or work with GHC
6.12 (in some cases, just modifications to the .cabal file).
I've created this wiki page to track work people have done on
that which hasn't yet been included into official packages or
repositories:

http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12

Please add any ones you know of (or just email me and I'll add them
for you).
--

-- 
Robin
Permalink | Reply | 0 comments |
headers
Henning Thielemann | 3 Dec 2009 15:12
Picon

Re: [GHC] #3709: Data.Either.partitionEithers is not lazy enough


On Thu, 3 Dec 2009, Malcolm Wallace wrote:

>> #3709: Data.Either.partitionEithers is not lazy enough
>> 
>> This is a behavioural change, e.g.:
>> Main> case partitionEithers1 [Left 'a', error "Not me"] of (x : _, _) -> x
>> Program error: Not me
>> Main> case partitionEithers2 [Left 'a', error "Not me"] of (x : _, _) -> x
>> 'a'
>
> Yes, and isn't that the point of the bugfix?  No non-bottoming program has 
> changed, but fewer programs fail now.  I find it hard to imagine that anyone 
> could have been relying on getting a crash here.

Making something more lazy can cause a memory leak.
Permalink | Reply | 4 comments |
headers
Malcolm Wallace | 4 Dec 2009 02:19
Picon

Re: [GHC] #3709: Data.Either.partitionEithers is not lazy enough

>>> No non-bottoming program
>>> has changed, but fewer programs fail now. I find it hard to imagine
>>> that anyone could have been relying on getting a crash here.
>>
>> Making something more lazy can cause a memory leak.

But in this case, leaving it strict would be responsible for a memory  
leak, whereas laziness removes the leak for some cases.  In those  
cases where the lazy version still has a memory leak, the strict  
version also suffers from the same leak.

> and a time leak, or a stack overflow.  People might complain if we  
> made foldl' more lazy :-)

I believe there is general agreement that Haskell library functions  
should be lazy by default.  Where there is a compelling case for  
strictness, it is usually noted by changing the name, e.g. foldl vs  
foldl'.  Where something has explicitly been strictified, of course  
making it lazy again would rightly provoke howls of protest.  But  
where a function seems to be *un*intentionally too strict...?

To come back to the specifics of partitionEithers, is anyone arguing  
that, in this case, the original over-strictness is either  
intentional, or useful?

Regards,
     Malcolm
Permalink | Reply | 2 comments |

Gmane