relaxing instance declarations

[Edward Kmett]

The problem I see with this is it becomes very brittle to just silently
accept bad class member names.

Before, if I had a method

class Foo a where
  bar :: a -> Int
  bar _ = 0

and I went to implement something with a typo

instance Foo Int where
  baz = id

then I'd get an error, but your proposal it'd just silently be accepted,
and lead to to long nights searching for why my instance wasn't doing what
I expected long after I'd shipped my product.

This kind of class isn't an academic concern, many real world classes are
defined with 2-3 members circularly. Consider Foldable or Traversable.

newtype Baz = Baz a

instance Foldable Baz where
  foldmap f (Baz a) = f a

is an innocent typo that would then just mean that foldMap when applied to
Baz will silently loop forever with no warning to the programmer.
Traversable Baz behaves similarly with the cyclic between sequenceA+fmap
and traverse.

I'd argue that I've made typos on member names *far* more often than I've
wanted this feature.

In fact, I've actually tried to live with a very similar lexical scoping
design in a toy language of mine I called Kata. In Kata, you could just
introduce new members by writing them in a 'public' block, and constrain
subclasses by putting in members without definitions, but it was
sufficiently brittle that I wound up adding another syntactic construct
which could only be used to instantiate definitions not make new names.
That resolve the issue and made the language much nicer to play around in.

I'd really rather not switch from a design that is robust and usually does
the right thing to one that is more brittle and prone to introducing hard
to find bugs. =(

-Edward



On Tue, Apr 30, 2013 at 7:05 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

> Max's idea (see below) of a second where clause is cute, but
> not sanctioned by Haskell syntax.
>
> Iavor wrote, "It would be quite arbitrary to restrict this only
> to instances."
>
> Actually what I have in mind is to make the language MORE
> consistent, by eliminating distinctions between instance-wheres
> and ordinary declaration-wheres.  Currently instance-wheres may
> only declare class methods, while declaration-wheres may declare
> variables at will.  Also instance-wheres may not declare type
> signatures, while declaration-wheres may.  I propose dropping
> these restrictions on instance-wheres.
>
> Hazard: Adding a method to an existing class could accidentally
> capture a name that was previously local to an instance-where.
> Capture can be prevented by declaring type signatures for local
> variables.  The compiler might warn when such defensive
> declarations are lacking.
>
> Doug
>
> On Mon, 29 Apr 2013 15:56 Iavor Diatchki <iavor.diatchki at gmail.com> wrote
>
> Hello,
>
> I think that if we want something along those lines, we should consider a
> more general construct that allows declarations to scope over other
> declarations (like SML's `local` construct).  It would be quite arbitrary
> to restrict this only to instances.
>
> -Iavor
>
>
>
> On Mon, Apr 29, 2013 at 2:41 PM, Max Bolingbroke <
> batterseapower at hotmail.com
> > wrote:
>
> > You could probably get away with just using two "where" clauses:
> >
> > instance Foo a where
> >     bar = ...
> >   where
> >     auxilliary = ...
> >
> >
> >
> >
> > On 28 April 2013 18:42, Edward Kmett <ekmett at gmail.com> wrote:
> >
> >> Makes sense. I'm not sure what a good syntactic story would be for that
> >> feature though. Just writing down member names that aren't in the class
> >> seems to be too brittle and error prone, and new keywords seems uglier
> than
> >> the current situation.
> >>
> >> Sent from my iPad
> >>
> >> On Apr 28, 2013, at 1:24 PM, Doug McIlroy <doug at cs.dartmouth.edu>
> wrote:
> >>
> >> > Not always. For example, you can't mess with the declaration
> >> > of a standard class, such as Num.
> >> >
> >> > On Sun, Apr 28, 2013 at 12:06 PM, Edward Kmett <ekmett at gmail.com>
> >> wrote:
> >> >
> >> >> You can always put those helper functions in the class and then just
> >> not
> >> >> export them from the module.
> >> >
> >> > On Sun, Apr 28, 2013 at 10:49 AM, Doug McIlroy <doug at cs.dartmouth.edu
> >> >wrote:
> >> >
> >> >> Is there any strong reason why the where clause in an instance
> >> >> declaration cannot declare anything other than class
> >> >> operators? If not, I suggest relaxing the restriction.
> >> >>
> >> >> It is not unusual for declarations of class operators to
> >> >> refer to special auxiliary functions. Under current rules
> >> >> such functions have to be declared outside the scope in
> >> >> which they are used.
> >> >>
> >> >> Doug McIlroy
> >>
> >> _______________________________________________
> >> Haskell-prime mailing list
> >> Haskell-prime at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-prime
> >>
> >>
> >
> > _______________________________________________
> > Haskell-prime mailing list
> > Haskell-prime at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-prime
> >
> >
>
> Content-Type: text/html; charset=UTF-8
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-prime/attachments/20130430/dba7d410/attachment.htm>