I have thought about this too. omission of type signatures seems to be an effective catalyst for code re-use yet this benefit is rarely emphasised. I was thinking about ways to make it easier and toyed around with allowing 'unkowns' in type declarations to allow you to specify only the important part of what you want in a type signature without having to over-specify the types. My idea was to allow '_' to be used in type signatures and represent any type. foo s = 4 foo :: _ foo :: _ -> Int foo :: String -> _ foo :: String -> Int would all be valid types (with different meanings) for 'foo'. This would be useful if say, you had to specify a function returned a plain Int to resolve ambiguity but you didn't want to specify the type of the input argument, perhaps because you are in the process of writing/debugging code and know the type will change. this has the nice generalization that all undeclared types are taken to be ':: _' note that this is not universal quantification because that would imply any type will work, where in actuality we just want to use the specific type infered via standard type inference for part of the declaration and specify exactly another part. The reason I didn't make the proposal was because I am not sure how useful such a thing would be in production code, even though there have been many times during the development/discovery process when such a feature would have signifigantly eased incremental development. John On Fri, May 04, 2001 at 10:40:34AM +0000, Marcin 'Qrczak' Kowalczyk wrote:
Fri, 4 May 2001 09:27:51 +0200 (MET DST), John Hughes <rjmh@cs.chalmers.se> pisze:
One good reason for NOT giving inferrable type signatures is that including them makes programs less modifiable: a small local change, such as adding a parameter to a type, may force a large number of consequential changes to type signatures.
Type synonyms should make this easier. Maybe the language should be improved somewhere here: class context synonyms? unbound type variables on the rhs of type synonyms? specifying parts of a type leaving the rest inferred?
These problems shouldn't arise for ensuring evaluation once, where the type is usually monomorphic! It's the other way around which can cause trouble (e.g. there are no class context synonyms).
-- -------------------------------------------------------------- John Meacham http://www.ugcs.caltech.edu/~john/ California Institute of Technology, Alum. john@foo.net --------------------------------------------------------------