Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Haskell
Wiki community
Recent changes
Random page
HaskellWiki
Search
Search
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Syntactic sugar/Cons
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Special pages
Page information
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Flexibility === The use of functions and functions of functions (i.e. higher order functions) allows for very flexible usage of program units. This is also true for the function notation, but it is not true for some syntactic sugar. E.g. <hask>map</hask> can be used with partial application which is not possible for list comprehension syntax. Thus <hask>map toLower</hask> can be generalised to lists of strings simply by lifting <hask>map toLower</hask> with <hask>map</hask>, again, leading to <hask>map (map toLower)</hask>. In contrast to that <hask>\s -> [toLower c | c <- s]</hask> has to be turned into <hask>\ss -> [[toLower c | c <- s] | s <- ss]</hask> or <hask>\ss -> map (\s -> [toLower c | c <- s]) ss</hask>. A function can get more arguments as the development goes on. If you are used to write <hask>x `rel` y</hask> then you have to switch to <hask>rel c x y</hask> after you added a new parameter to <hask>rel</hask>. The extended infix notation <hask>x `rel c` y</hask> is (currently?) not allowed, probably because then also nested infixes like in <hask>x `a `superRel` b` y</hask> must be handled. The prefix notation <hask>rel x y</hask> tends to need less rewriting. Guards need to be rewritten to <hask>if</hask>s or to [[Case]] statements when the result of a function needs post-processing. Say we have the functions <haskell> isLeapYear :: Int -> Bool isLeapYear year = mod year 4 == 0 && (mod year 100 /= 0 || mod year 400 == 0) leapYearText :: Int -> String leapYearText year | isLeapYear year = "A leap year" | otherwise = "Not a leap year" </haskell> where <hask>leapYearText</hask> shall be extended to other languages using the fictitious function <hask>translate</hask>. If you stick to guards you will possibly rewrite it to the clumsy <haskell> leapYearText :: Language -> Int -> String leapYearText lang year = translate lang (case () of () | isLeapYear year -> "A leap year" | otherwise -> "Not a leap year") </haskell> But what about <haskell> leapYearText :: Language -> Int -> String leapYearText lang year = translate lang (if (isLeapYear year) then "A leap year" else "Not a leap year") </haskell> So if you find that simpler why not using <hask>if</hask> also in the original definition? <haskell> leapYearText :: Int -> String leapYearText year = if (isLeapYear year) then "A leap year" else "Not a leap year" </haskell>
Summary:
Please note that all contributions to HaskellWiki are considered to be released under simple permissive license (see
HaskellWiki:Copyrights
for details). If you don't want your writing to be edited mercilessly and redistributed at will, then don't submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource.
DO NOT SUBMIT COPYRIGHTED WORK WITHOUT PERMISSION!
Cancel
Editing help
(opens in new window)
Toggle limited content width