[Haskell-cafe] Data constructors versus types
I know nothing about theoretical computer science, but I was wondering if it possible to forget about types, and just keep the concept of data constructors, and have an analyzer determine correctness of the code and staticness of the data? Basically this is what SCHEME does no? Doesn't SCHEME have static whole program analyzers to remove the overhead of the symbol tags and check correctness of a program (Stalin, Petit-Scheme, ...)? What are to pros/contras? Thank you, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data constructors versus types
bf3: I know nothing about theoretical computer science, but I was wondering if it possible to forget about types, and just keep the concept of data constructors, and have an analyzer determine correctness of the code and staticness of the data? The analysis would be type inference and checking. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data constructors
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data constructors
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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data constructors
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.138Austin, Texas 78712-0233 [EMAIL PROTECTED][EMAIL PROTECTED] -- ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data constructors
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
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
