binding vs. parameter passing

One problem in *Programming Haskell from First Principles* confuses me. (So far.) It's one where you start with the declaration and binding i :: Num a => a i = 1 (which of course works because Num a => a is the type of 1) and then change the declaration to i :: a and first try to predict and then see what happens. It fails, with ghci suggesting that you put the Num a => back. That seemed reasonable at first, but then I considered this: - id has type a -> a, and if you try to evaluate id 1 it works without complaint. - In all the work I've done on compilers, parameter passing has effectively been assignment of actual parameters to the corresponding formal parameters. In Haskell, that might mean passing along the appropriate thunk, but the principle is the same, isn't it? So, if I can't bind 1 to i which is declared to have type a, why can I successfully pass 1 to id?

This answer is likely incomplete at best and wrong at worst, but I'll give
it a shot.
When you have this type declaration:
i :: a
It means that you are declaring the symbol i that can be slotted into any
location that requires an a. It is a task for the compiler to process the
overall program specification and infer that a has a particular concrete
type. When the program is specified though, the value i has a generic type
with no bounds, and the only way to *construct* such a value is to supply a
value of type a from somewhere else.
The problem here is not that you can't *bind* 1 to i, but that you cannot
*construct* any value of type a.
A direct analog of this would be - not the application of the id function
as you called out - but that you cannot define a function with
the following signature, not including bottom:
f :: a -> b
The reason is that you can't supply a value of type b.
I have some experience with Java, and it has a similar constraint that
generic types cannot be instantiated.
--
RRI
On Mon, Jul 22, 2019 at 7:30 PM James Jones
One problem in *Programming Haskell from First Principles* confuses me. (So far.)
It's one where you start with the declaration and binding
i :: Num a => a i = 1
(which of course works because Num a => a is the type of 1) and then change the declaration to
i :: a
and first try to predict and then see what happens. It fails, with ghci suggesting that you put the Num a => back. That seemed reasonable at first, but then I considered this:
- id has type a -> a, and if you try to evaluate id 1 it works without complaint. - In all the work I've done on compilers, parameter passing has effectively been assignment of actual parameters to the corresponding formal parameters. In Haskell, that might mean passing along the appropriate thunk, but the principle is the same, isn't it?
So, if I can't bind 1 to i which is declared to have type a, why can I successfully pass 1 to id? _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
-- Ramnath R Iyer
participants (2)
-
James Jones
-
Ramnath R Iyer