I keep running into annoyance in having to name data constructors differently if they're for different types if they're in the same module or something. I wish that something like some Type.Constructor syntax worked in order to disambiguate. Or, better still, I have that problem with function names too (e.g. Data.List.union, Data.Set.union, IIRC) and it occurs to me that a lot of this can be resolved automatically because the types only make sense with one of the choices. I'm not really proposing any changes; more, I'm wondering what others' thinking is about this sort of thing - what annoys them, how they get around it, etc. -- Mark
At 12:25 PM -0400 4/25/04, Mark Carroll wrote:
I keep running into annoyance in having to name data constructors differently if they're for different types if they're in the same module or something. I wish that something like some Type.Constructor syntax worked in order to disambiguate. Or, better still, I have that problem with function names too (e.g. Data.List.union, Data.Set.union, IIRC) and it occurs to me that a lot of this can be resolved automatically because the types only make sense with one of the choices.
I'm not really proposing any changes; more, I'm wondering what others' thinking is about this sort of thing - what annoys them, how they get around it, etc.
The nonreusability of function and constructor names comes (AFAIK) from the need to infer types in the absence of type declarations. For example, if we have types data A = X Int | Y String data B = X Float | Y String then it's not possible to determine whether f as defined by these equations f (X x) = X (x+3) f (Y s) = Y (reverse s) has type A -> A or B -> B, and thus whether the type of that (+) is Int -> Int -> Int or Float -> Float -> Float. So, in order to preserve type inference in the absence of type declarations, we put up with the nuisance of name collisions. Whether the payoff is worth the price is open to question. It seems to be widely agreed that although type declarations aren't strictly necessary, they're nevertheless highly advisable as aids to the human reader --as verified comments, if you will. In this respect the Standard Prelude sets an excellent example. If our code is going to include type declarations anyway, couldn't a type checker use them to resolve ambiguities created by reuse of names? Continuing the example, declaring f :: A->A removes the ambiguity. If this capability were added to some future version of Haskell, programmers would be required to declare functions' types only when they want to reuse names of constructors and other functions. Of course, if thisd idea is all wet because I'm missing something, I'll be most grateful to be enlightened. Regards to all, --Ham -- ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138 Austin, Texas 78712-0233 ham@cs.utexas.edu hrichrds@swbell.net ------------------------------------------------------------------
On 2004 April 25 Sunday 12:25, Mark Carroll wrote:
I wish that something like some Type.Constructor syntax worked in order to disambiguate. [...] I'm not really proposing any changes; more, I'm wondering what others' thinking is about this sort of thing - what annoys them, how they get around it, etc. I appreciate the fact that in Haskell, each name refers to one definition. The lack of overloading keeps things clear in a way that's a refreshing alternative to the C++ that I also use. I work around the interference you describe, using constructor names like EmptyList and EmptySet.
Must function concepts such as 'union' can be made into type classes, to the extent that the concept can be described in the type system. A means of disambiguating names is, to my understanding, in the realm of modules. Types explain _why_ the parts of the program fit together into a well-formed whole. _How_ the parts are connected together, e.g. ensuring each reference to name has a corresponding definition, is not a matter of types.
On Sun, 25 Apr 2004, Scott Turner wrote: (snip)
Must function concepts such as 'union' can be made into type classes, to the extent that the concept can be described in the type system. (snip)
Unfortunately, you still need the different names when you make the instances, and you can't do things like foo { bar = baz } with the "bar" as the name of the function in the class instead of the field name / selector function that's used in the instance, AFAIK. (Thanks for your other comments.) -- Mark
hi, i have thought about things like that, but the qualification Type.Constructor does not seem particularly useful. you can achieve the same by using "_", e.g data A = A_X | A_Y data B = B_X | B_Y alternatively (at least for non-recursilve datatypes) anonymous sums (ala TREX's records) could work pretty well, but they are not in Haskell. details about those can probably be found in Ben Gaster's thesis. -iavor Mark Carroll wrote:
I keep running into annoyance in having to name data constructors differently if they're for different types if they're in the same module or something. I wish that something like some Type.Constructor syntax worked in order to disambiguate. Or, better still, I have that problem with function names too (e.g. Data.List.union, Data.Set.union, IIRC) and it occurs to me that a lot of this can be resolved automatically because the types only make sense with one of the choices.
I'm not really proposing any changes; more, I'm wondering what others' thinking is about this sort of thing - what annoys them, how they get around it, etc.
-- Mark _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (4)
-
Hamilton Richards -
Iavor S. Diatchki -
Mark Carroll -
Scott Turner