Create how to define functions #16
Conversation
| let z = myDouble' 146 | ||
| putStrLn (show z') | ||
|
|
||
| -- CURRYING: |
There was a problem hiding this comment.
I do think we should talk about currying, but I'm wondering if it might be a little too much here - I'm thinking maybe we could leave this page as an extremely gentle introduction to functions, and then have a second page entitled "partial function application", what do you think?
There was a problem hiding this comment.
Yes, that makes sense. Should I add currying in another pull request or just leave it here?
There was a problem hiding this comment.
It's fine that you left it here; we might separate it out when we get ready to create the Phrasebook pages for them.
argumatronic
left a comment
There was a problem hiding this comment.
I like the progression you've used for the currying and partial application topic. I think it might be helpful if we introduce lambdas as anonymous functions in the introduction to functions before we get to using them to visualize currying, but otherwise, I think this is a good way to handle the topic.
| f x = (x, x + 1) | ||
|
|
||
| g :: Int -> (Int, Int) | ||
| g x = (x+1, x) |
There was a problem hiding this comment.
Hi, I was wondering if you could clarify your intent in transposing the tuple elements between f and g. We have some guesses based on how you use them below, but we'd like to make sure we understand your goal. Thank you.
There was a problem hiding this comment.
Hi! I didn't have any particular goal, I just thought it would be better to have functions slightly different.
| f x = (x, x + 1) | ||
|
|
||
| g :: Int -> (Int, Int) | ||
| g x = (x+1, x) |
There was a problem hiding this comment.
Type signatures: Yes, I think we should talk about them on this page. I like how you've included a type signature for g but not for f so we can highlight how type signatures are optional.
There's one complication I'd like to address: the type of g with the type signature (Int -> (Int, Int)) is different from the type that would be inferred implicitly (Num a => a -> (a, a)). This is a more subtle concern than I'd like to impose on readers at this point, so I'm wondering if we could instead do this demonstration of optional type signatures on an example where the inferred type would be monomorphic.
Changed example which shows that type signatures are optional
added examples explaining lambdas
Improved example with lambdas
added examples with pattern matching
|
Thanks for the updates! This'll be released under the creative commons CC BY-NC 4.0 license - Please let us know if that's okay and how you'd like to be attributed (your name, and a link to a blog or social account if you'd like). |
|
I am very glad to be helpful :) Everything's okay, and I think a link to my GitHub and my username would be more than enough. |
No description provided.