binding vs. parameter passing

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

binding vs. parameter passing

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
Reply | Threaded
Open this post in threaded view
|

Re: binding vs. parameter passing

Ramnath R Iyer-2
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 <[hidden email]> wrote:
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners


--
Ramnath R Iyer

_______________________________________________
Beginners mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners