Proposal: Don't require users to use undefined

[Simon Peyton-Jones]

| Users of the sizeOf or alignment methods (:: a -> Int) of the Storable
| class are pushed to use 'undefined' in their programs. Take the
| following function from Foreign.Marshal.Alloc as an example:
| 
| malloc :: Storable a => IO (Ptr a)
| malloc  = doMalloc undefined
|   where
|     doMalloc       :: Storable b => b -> IO (Ptr b)
|     doMalloc dummy  = mallocBytes (sizeOf dummy)
| 
...
| 
| I would like to propose solving this. My proposal consists of 3 sub-proposals:

I'm not keen on this proposal.
  a) The improvement is minor
  b) A lot of exixting code has to be changed
  c) There is a better way to do the job

What is really going on?  We have
	sizeOf :: forall a. Storable a => a -> Int
What we *want* is
	newSizeOf :: forall a. Storable a => Int
but in H98 we call newSizeOf because there would be no way to tell newSizeOf which type to use.  

The obvious solution is something Haskell badly needs: explicit type applications. Instead of writing
	sizeOf (undefined :: Int)
we should write
	newSizeOf @ Int
where the "@" says that the next argument is a type. As Haskell's type system becomes more sophisticated, the lack of type applications becomes more and more annoying.  For example, to get impredicative polymorphism I want to write

	Just @ (forall a. a->a) id
to get something of type
	Maybe (forall a. a->a)

It's only a matter of time before we have explicit type applications.  Indeed, the principal difficulty is *syntax*.  (My "@" notation above might just work; because "@" is already unavailable as an operator.)

Given explicit type applications and scoped type variables, it's easy to do the Right Thing for your examples. And the Right Thing works at higher kinds too.  Eg

	class Typeable1 (a :: *->*) where
	  typeOf1 :: TypeRep

Then we can say (typeOf1 @ Maybe).  This is harder with proxies; I don't think it's covered by your proposal.


Now, none of this is H98, of course.  But we already have a H98 solution.  I don't really think it's worth the disruption to switch from one workaround to another, even aside from dealing with the long-running deprecation and compatibility issues that then show up.

Simon