headers
Max Bolingbroke | 1 Feb 2011 10:52
Picon
Favicon
Gravatar

Re: Local definitions in the class instances

On 27 January 2011 17:11, Iavor Diatchki <iavor.diatchki@...> wrote:
> instance Num Wrapped where
>    local
>      lift2 f (Wrapped a) (Wrapped b) = Wrapped (f a b)
>      lift f (Wrapped a) = Wrapped (f a)
>    in
>     (+) = lift2 (+)
>     (-) = lift2 (-)
>     (*) = lift2 (*)
>     abs = lift abs
>     signum = lift signum

Local declarations at module scope can be emulated using pattern bindings:

"""
(foo, bar) = (foo, bar)
  where
    foo = ..
    bar = ..
    private = ...
"""

If instance declarations supported pattern bindings you could get the
same effect for your instances too. This would be a minimal change
that avoided introducing any extra syntax.

Cheers,
Max
Permalink | Reply | 3 comments |
headers
Ben Millwood | 1 Feb 2011 13:23
Picon
Favicon
Gravatar

Re: Local definitions in the class instances

On Tue, Feb 1, 2011 at 9:52 AM, Max Bolingbroke
<batterseapower@...> wrote:
>
> Local declarations at module scope can be emulated using pattern bindings:
>
> """
> (foo, bar) = (foo, bar)
>  where
>    foo = ..
>    bar = ..
>    private = ...
> """
>
> If instance declarations supported pattern bindings you could get the
> same effect for your instances too. This would be a minimal change
> that avoided introducing any extra syntax.
>

This is kind of ugly, I think, and there are proposals to make pattern
bindings monomorphic which would make this sort of thing no longer
possible in general. I think I would be in favour of a declaration
analogue to let.
Permalink | Reply | 2 comments |
headers
Sebastian Fischer | 2 Feb 2011 03:25
Picon
Favicon

Re: Local definitions in the class instances

On Tue, Feb 1, 2011 at 9:23 PM, Ben Millwood <haskell-G9ciLxwLay5AisqP9vmM6Q@public.gmane.org> wrote:

On Tue, Feb 1, 2011 at 9:52 AM, Max Bolingbroke
<batterseapower-PkbjNfxxIASIwRZHo2/mJg@public.gmane.orgm> wrote:
>
> Local declarations at module scope can be emulated using pattern bindings:
>
> """
> (foo, bar) = (foo, bar)
>  where
>    foo = ..
>    bar = ..
>    private = ...
> """
>
> If instance declarations supported pattern bindings you could get the
> same effect for your instances too. This would be a minimal change
> that avoided introducing any extra syntax.

It's a nice trick! Although it does look strange, it may be reasonable to allow pattern bindings in instance declarations regardless of the original proposal. Is it correct that, currently, pattern bindings are allowed everywhere but in instance declarations? If so, why not in instance declarations too?
 
This is kind of ugly, I think, and there are proposals to make pattern
bindings monomorphic which would make this sort of thing no longer
possible in general.

I think the proposals to make pattern bindings monomorphic only concern pattern bindings without type annotations. Instance methods do have type annotations in the class declaration so even if pattern bindings without type signatures would be monomorphic, instance methods bound using pattern bindings need not be.
 
I think I would be in favour of a declaration analogue to let.

I agree that using pattern bindings for the original task would work around a missing syntax extension. But at least this workaround may be easily implementable and making it possible seems to fix an inconsistency by making the use of pattern bindings more orthogonal.

Sebastian
_______________________________________________
Haskell-prime mailing list
Haskell-prime@...
http://www.haskell.org/mailman/listinfo/haskell-prime
Permalink | Reply | 1 comment |
headers
Max Bolingbroke | 2 Feb 2011 12:36
Picon
Favicon
Gravatar

Re: Local definitions in the class instances

On 2 February 2011 02:25, Sebastian Fischer <fischer@...> wrote:
> It's a nice trick! Although it does look strange, it may be reasonable to
> allow pattern bindings in instance declarations regardless of the original
> proposal. Is it correct that, currently, pattern bindings are allowed
> everywhere but in instance declarations? If so, why not in instance
> declarations too?

Unfortunately, they are not allowed. I ran up against this limitation
even before this thread. Here is an example:

"""
{-# LANGUAGE NoMonoPatBinds #-}
data I a = I { unI :: a }

instance Monad I where
    (return, (>>=)) = (I, \mx f -> f (unI mx))

main = return ()
"""

And the error:

"""
/Users/mbolingbroke/Junk/InstancePattern.hs:5:5:
    Pattern bindings (except simple variables) not allowed in instance
declarations
      (return, >>=) = (I, \ mx f -> f (unI mx))
"""

This behaviour does seem to be as per the Haskell 98 spec, but I'm not
sure of the motivation behind it.

> I think the proposals to make pattern bindings monomorphic only concern
> pattern bindings without type annotations. Instance methods do have type
> annotations in the class declaration so even if pattern bindings without
> type signatures would be monomorphic, instance methods bound using pattern
> bindings need not be.

This was what I used to think too, but I recently found out (again,
unrelated to this thread) that they won't work even with explicit
signatures! See for example
http://hackage.haskell.org/trac/ghc/ticket/4940

I'm personally not in favour of MonoPatBinds anyway, but it is
*particularly* annoying that they don't work even with a signature.

Cheers,
Max
Permalink | Reply | 0 comments |
headers
John Smith | 4 Feb 2011 10:41
Picon
Favicon

Reform of the Monad, and Disruptive Change

There has been a fair amount of discussion, both on this list and libraries, regarding the Monad class
hierarchy. The 
many on the libraries list expressed support for the patch at
http://hackage.haskell.org/trac/ghc/ticket/4834, 
conditional on it being part of the next Haskell report. However, Haskell' prefers patches to have been
implemented 
before proposing here.

What is the best way out of this deadlock?
Permalink | Reply | 7 comments |
headers
Malcolm Wallace | 4 Feb 2011 11:08
Gravatar

Re: Reform of the Monad, and Disruptive Change


On 4 Feb 2011, at 09:41, John Smith wrote:

> There has been a fair amount of discussion, both on this list and  
> libraries, regarding the Monad class hierarchy. The many on the  
> libraries list expressed support for the patch at http://hackage.haskell.org/trac/ghc/ticket/4834 
> , conditional on it being part of the next Haskell report. However,  
> Haskell' prefers patches to have been implemented before proposing  
> here.
>
> What is the best way out of this deadlock?

I suggested, and several people +1'd, that if we are making disruptive  
changes to the standard libraries defined in the Language Report  
(especially the Prelude), then we should aim to make a thorough job of  
cleaning up all the cruft and redesigning in a single strike.  This  
means not just rearranging the Monad hierarchy, but looking at I/O  
types, exceptions, the default strictness of foldl, and much much  
more.  I would expect the language committee to get involved in  
reviewing the decisions of the base library strike force.

Then (for instance) ghc could make a major release with the refreshed  
libraries, and after a little experience in the field (and perhaps a  
few patches), the libraries would then proceed to be blessed as part  
of the subsequent language standard.

Regards,
     Malcolm
Permalink | Reply | 6 comments |
headers
Dark Lord | 4 Feb 2011 11:49
Picon
Favicon

Re: Reform of the Monad, and Disruptive Change

On 04/02/2011 12:08, Malcolm Wallace wrote:
 > I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries
defined in the
 > Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the
cruft and
 > redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types,
 > exceptions, the default strictness of foldl, and much much more. I would expect the language committee to
get involved
 > in reviewing the decisions of the base library strike force.
 >
 > Then (for instance) ghc could make a major release with the refreshed libraries, and after a little
experience in the
 > field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the subsequent language
 > standard.
 >
 > Regards,
 > Malcolm

I thoroughly agree with this. However, in the event that this does not happen, piecemeal fixes are better
than none.

(Seeing as the inertia in Haskell is such that Haskell 2011 was cancelled, and Haskell Platform 2011
contains no new 
packages, such a task force doesn't seem very likely.)
Permalink | Reply | 2 comments |
headers
Howard B. Golden | 4 Feb 2011 16:37
Picon
Favicon
Gravatar

Re: Reform of the Monad, and Disruptive Change

John Smith <voldermort@...> asked:

> What is the best way out of  this deadlock?

My suggestions:

* If possible, make the change optional. As an example, create a second (third, 
etc.) Prelude with the new features without abandoning the current Prelude. Let 
the user choose the Prelude he/she wants via a pragma or compiler option. Then 
developers can vote with their feet (fingers?). If the new Prelude is buggy, it 
will be easy to try something else. You might call this "intellectual free 
enterprise."

* Do everything possible to create adapters to make upgrading existing code to 
the new Prelude. Thus, if a new Prelude is adopted widely, existing code will be 
easy to incorporate with minimal source changes.

* Avoid disruptive changes by letting the user decide. Once there is a clear 
consensus based on significant usage, then the new Prelude can be blessed by 
some committee (if desired). However, don't abandon the previous Prelude as an 
option, ever. Textbooks might teach only the newer Prelude, but old code would 
still work.

* Recognize that the Haskell user base at this time shouldn't be constrained by 
mandated changes, but should be encouraged to experiment and evolve the 
libraries.

Cheers,

Howard
Permalink | Reply | 0 comments |
headers
Ian Lynagh | 4 Feb 2011 17:00
Picon
Gravatar

Re: Reform of the Monad, and Disruptive Change

On Fri, Feb 04, 2011 at 12:49:09PM +0200, Dark Lord wrote:
> On 04/02/2011 12:08, Malcolm Wallace wrote:
> > I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries
defined in the
> > Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the
cruft and
> > redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types,
> > exceptions, the default strictness of foldl, and much much more. I would expect the language committee
to get involved
> > in reviewing the decisions of the base library strike force.
> >
> > Then (for instance) ghc could make a major release with the refreshed libraries, and after a little
experience in the
> > field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the
subsequent language
> > standard.
>
> I thoroughly agree with this. However, in the event that this does not happen, piecemeal fixes are better
than none.
>
> (Seeing as the inertia in Haskell is such that Haskell 2011 was 
> cancelled, and Haskell Platform 2011 contains no new packages, such a 
> task force doesn't seem very likely.)

Also note that the H' process is the way it is because "fix everything
at once" in the language turned out to be infeasible. The same may or
may not be true for the libraries.

I don't object to a "fix everything at once" libraries change, but in
the absence of it happening, fixing things individually is also good
with me.

(where "individually" would still mean, for example, all Monad class
reshuffling should happen at once, but the strictness of foldl' would be
a separate change).

Thanks
Ian
Permalink | Reply | 0 comments |
headers
Roman Leshchinskiy | 4 Feb 2011 20:16
Picon
Picon
Favicon

Re: Reform of the Monad, and Disruptive Change

On 04/02/2011, at 10:49, Dark Lord wrote:

> I thoroughly agree with this. However, in the event that this does not happen, piecemeal fixes are better
than none.

FWIW, I disagree. To put it bluntly, why is repeatedly breaking a lot of code better than not breaking it at
all? Breaking a lot of code once might be ok because the benefits of fixing many issues probably outweigh
the costs. But for each individual change (such as the Monad redesign), the costs far outweigh the
benefits, IMO.

> (Seeing as the inertia in Haskell is such that Haskell 2011 was cancelled, and Haskell Platform 2011
contains no new packages, such a task force doesn't seem very likely.)

Introducing backwards-incompatible changes into a language standard *should* be hard.

Roman
Permalink | Reply | 0 comments |

Gmane