Implict parameters and monomorphism

[John Meacham]

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
--------------------------------------------------------------