Doug suggested this below:
“Capture can be prevented by declaring type signatures for local
variables. The compiler might warn when such defensive
declarations are lacking.”
I think what Doug is proposing is that it be a warning *not* to include a type signature for any local declaration in an instance, and continue to be an error to provide a type signature for any class member implementation. That would mean that if you started warnings-free, a change in the type class that captured a local would always result in an error.
The downsides I see are that
(a) it doesn’t seem very intuitive for the presence or absence of type signatures to signify whether something is local or not
(b) GHC has a recent extension “InstanceSigs” that allows signatures to be given on class members
Overall I like the idea of regularizing the language and have wanted something like this myself in the past, but Edward’s objection feels significant to me.
From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Edward Kmett
Sent: 01 May 2013 02:46
To: Doug McIlroy
Cc: haskell-prime@haskell.org Prime
Subject: Re: relaxing instance declarations
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 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 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 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 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 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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime _______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime Content-Type: text/html; charset=UTF-8
=============================================================================================================
This material has been prepared by individual sales and/or trading personnel and does not
constitute investment research. Please follow the attached hyperlink to an important disclaimer:
http://www.credit-suisse.com/americas/legal/salestrading
=============================================================================================================
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================