Re: instance declarations
David Feuer <[EMAIL PROTECTED]> writes: > 1. Why can't [instances] be hidden in module imports/exports? The way I see it, an instance declaration is an assertion that a certain data type supports a certain set of operations. Thus, if the data type and the operations on it are in scope, it makes sense for the class instance to be, too. (This leads to the question of why we need to have instance declarations at all :-) (My guesses would be: compiler implementation issues, code clarity, error detection, partially implemented classes)) Problems arise when a data type needs to be instantiated twice in the same class, but with different operator implementations. (I.e. you have a data type which prints differently according to which module you're in) This would, I think, be a problem in most languages, think of deriving a C++ class twice from the same base class while providing different overrides for the functions. I'm not entirely convinced it's an issue that needs a better resolution than the language provides today. (There's a diminishing returns effect when adding language features, and at some point, the increased complexity of the language doesn't make it worth it, IMHO.) > 2. Why can't you simultaneously declare a type to be an instance of > multiple classes? Why does it matter? > class C1 t where a::t->t > class C1 t => C2 t where b::t->t > instance C1 T, C2 T where > a=... > b=... To me, it'd make more sense to provide class C1 t where a :: t -> t class (C1 t) => C2 t where b :: t -> t instance C2 T where a = ... -- implicitly instantiating C1 b = ... and avoid long instantiation chains. But that too is IMHO a minor issue. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: instance declarations
Hi Marcin, | > There's no solid technical reason for this, but Haskell doesn't allow | > it at the moment because there isn't an easy way to name an instance | > declaration. | | There is another problem: even if we created a syntax to name them, | if they would not be exported by default then current programs would | have to be changed. You're right of course, although I consider this a pragmatic issue rather than a technical problem: I'm thinking of future languages that are inspired by current Haskell standards but not constrained by details of the current definition or existing codebase. All the best, Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: instance declarations
Hi David, | >Recently, however, there has been some interest in using named instance | >declarations in other ways, so perhaps we will see features like this | >creeping into future versions of the language. | | In what kinds of ways? Sounds interesting. I was thinking of a couple of papers from the most recent Haskell workshop. See http://www.cs.uu.nl/people/ralf/hw2001.html for some pointers (the second session). | > module M(C(..), instance C Int, instance C a => C [a]) where ... | | This is the sort of thing I was thinking too. But I would probably want | to extend that to classes and types. For instance | | module M (class Eq a=>C a (...), type A, instance C A, instance C a => C | [a]) | where ... Yes, that's also what I had in mind at the more verbose end of the spectrum (which is not to say that I think it would be a bad thing). A richer, more explicit syntax for export lists might provide some useful documentation and be easier to read than a syntax that leaves you guessing whether C(..) refers to a type or a class. On the other hand, if things start to get too wordy, you might instead want to add a separate notation for describing interfaces. The following is an throwaway syntax, intended only to hint at the basic idea: interface I where class C a where f :: a -> a instance C Int instance C a => C [a] module M implements I where ... ... Start allowing parameterization and other interesting features and this begins to look somewhat like ML style modules (and related systems). All the best, Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: instance declarations
Marcin 'Qrczak' Kowalczyk wrote:
> There is another problem: even if we created a syntax to name them,
> if they would not be exported by default then current programs would
> have to be changed.
Well, the default could be to export, unless explicitly hidden. If it
_is_ exported, you could have the option to write it explicitly, or just
have it go by default.
>
> Perhaps in the future it will be possible to specify the interface
> of a Haskell module more formally, with types of exported values
> for example. Then we should remember about instances and solve both
> problems simultaneously.
I guess that may be true... It could be really useful to have a tool to
take a source file and automagically make an approximate header for
it...
--
/Times-Bold 40 selectfont/n{moveto}def/m{gsave true charpath clip 72
400 n 300 -4 1{dup 160 300 3 -1 roll 0 360 arc 300 div 1 1 sethsbcolor
fill}for grestore 0 -60 rmoveto}def 72 500 n(This message has been)m
(brought to you by the)m(letter alpha and the number pi.)m(David Feuer)
m([EMAIL PROTECTED])m showpage
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: instance declarations
Fri, 7 Dec 2001 11:38:14 -0800, Mark P Jones <[EMAIL PROTECTED]> pisze:
> There's no solid technical reason for this, but Haskell doesn't allow
> it at the moment because there isn't an easy way to name an instance
> declaration.
There is another problem: even if we created a syntax to name them,
if they would not be exported by default then current programs would
have to be changed.
An instance is usually meant to be exported, so even not considering
compatibility it would be tedious to list all those instances in
the export list (unless you want to export every named thing as well
and omit the export list). It's easy to overlook some and the point
when somebody tries to use a particular instance might be far in the
future. Each instance is often a "small" part of an interface.
I agree that the ability to selectively export instances would be good.
Only it's hard to combine with the current policy of exporting all
instances by default.
Perhaps in the future it will be possible to specify the interface
of a Haskell module more formally, with types of exported values
for example. Then we should remember about instances and solve both
problems simultaneously.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^
QRCZAK
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: instance declarations
(sorry to mess up mail threading, but I couldn't properly reply to the message the way I'm using email right now--broken mail clients) >Recently, however, there has been some interest in using named instance >declarations in other ways, so perhaps we will see features like this >creeping into future versions of the language. In what kinds of ways? Sounds interesting. >[Of course, there is a way of naming instance declarations with the >current Haskell syntax, although it is a little verbose, and would >require more work on the implementers part than simple matching of >strings. The syntax I'm thinking of would look something like the >following: > > module M(C(..), instance C Int, instance C a => C [a]) where ... This is the sort of thing I was thinking too. But I would probably want to extend that to classes and types. For instance module M (class Eq a=>C a (...), type A, instance C A, instance C a => C [a]) where ... If I am not mistaken, this would allow separation of the type namespace from the typeclass namespace, and would make it obvious whether the thing being exported is a type or a class. It could also potentially allow the context(s) for class and instance declarations to be more restrictive in the header or in imports than in the module body. The latter could perhaps allow resolution of overlapping instances at import time, by restricting the instances to the point of non-overlap. I'm not sure that the former would actually be useful. Hmmm speaking of overlapping instances... Would there be a practical way to add negation (of classes and possibly even types) to the context syntax? This would let you say instance (Integral a) => C (T a) where ... instance (not Integral a, Real a) => C (T a) where ... instance (not Num a) => C (T a) where ... It would also seem nice to be able to say instance (Integral a, not a Int) => C a where and instance C Int where . but this seems even more questionable. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: instance declarations
Hi David, | 1. Why can't they be hidden in module imports/exports? Is this an | implementation issue (I guess I could see it as a problem with the | dictionary-passing approach...)? It seems kind of bad that instances are | not allowed to overlap, but can't be hidden. There's no solid technical reason for this, but Haskell doesn't allow it at the moment because there isn't an easy way to name an instance declaration. And if you can't name it, then you can't put it in an import/export list. Also, I don't think people thought it was worth the hassle of introducing a syntax for naming instances when the only thing it could be used for was controlling imports and exports. Recently, however, there has been some interest in using named instance declarations in other ways, so perhaps we will see features like this creeping into future versions of the language. [Of course, there is a way of naming instance declarations with the current Haskell syntax, although it is a little verbose, and would require more work on the implementers part than simple matching of strings. The syntax I'm thinking of would look something like the following: module M(C(..), instance C Int, instance C a => C [a]) where ... Other variations, either more or less verbose, are possible. Personally, I think it would be nice to be able to document class instances explicitly like this as part of module interfaces.] | 2. Why can't you simultaneously declare a type to be an instance of | multiple classes? i.e., why can't you write the following? | | class C1 t where | a::t->t | class C1 t => C2 t where | b::t->t | | instance C1 t, C2 t where | a=... | b=... Again, there's no problem with this in theory, but it has the potential to be messy in practice. What would the syntax for this look like in the general case? What if you wanted to include contexts on the instance declarations? A nicely worked out proposal that answers questions like these in the general case, without seeming ad hoc or arbitrary, might attract some interest from implementers. As things stand, however, I'm guessing that most people don't find they need this feature often enough to justify extra complexity in the language definition. All the best, Mark ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
