278 what the function is supposed to do. What the \code{collatz} |
278 what the function is supposed to do. What the \code{collatz} |
279 function does should be pretty self-explanatory: the function |
279 function does should be pretty self-explanatory: the function |
280 first tests whether \code{n} is equal to 1 in which case it |
280 first tests whether \code{n} is equal to 1 in which case it |
281 returns \code{true} and so on. |
281 returns \code{true} and so on. |
282 |
282 |
283 Notice a quirk in Scala's syntax for \code{if}s: The condition |
283 Notice the quirk in Scala's syntax for \code{if}s: The condition |
284 needs to be enclosed in parentheses and the then-case comes |
284 needs to be enclosed in parentheses and the then-case comes |
285 right after the condition---there is no \code{then} keyword in |
285 right after the condition---there is no \code{then} keyword in |
286 Scala. |
286 Scala. |
287 |
287 |
288 The real power of Scala comes, however, from the ability to |
288 The real power of Scala comes, however, from the ability to |
604 |
604 |
605 \begin{lstlisting}[ numbers=none] |
605 \begin{lstlisting}[ numbers=none] |
606 (Int, Int) => (Int, Int) |
606 (Int, Int) => (Int, Int) |
607 \end{lstlisting} |
607 \end{lstlisting} |
608 |
608 |
609 Another special type-constructor is for functions, written |
609 Another special type-constructor is for functions, written as |
610 as the arrow \code{=>}. For example, the type |
610 the arrow \code{=>}. For example, the type \code{Int => |
611 \code{Int => String} is for a function that takes an integer as argument |
611 String} is for a function that takes an integer as input |
612 and produces a string. A function of this type is for instance |
612 argument and produces a string as result. A function of this |
|
613 type is for instance |
613 |
614 |
614 \begin{lstlisting}[numbers=none] |
615 \begin{lstlisting}[numbers=none] |
615 def mk_string(n: Int) : String = n match { |
616 def mk_string(n: Int) : String = n match { |
616 case 0 => "zero" |
617 case 0 => "zero" |
617 case 1 => "one" |
618 case 1 => "one" |
618 case 2 => "two" |
619 case 2 => "two" |
619 case _ => "many" |
620 case _ => "many" |
620 } |
621 } |
621 \end{lstlisting} |
622 \end{lstlisting} |
622 |
623 |
623 \noindent It takes an integer as argument and returns a |
624 \noindent It takes an integer as input argument and returns a |
624 string. Unlike other functional programming languages, there |
625 string. Unlike other functional programming languages, there |
625 is in Scala no easy way to find out the types of existing |
626 is in Scala no easy way to find out the types of existing |
626 functions, except by looking into the documentation |
627 functions, except by looking into the documentation |
627 |
628 |
628 \begin{quote} |
629 \begin{quote} |
660 |
661 |
661 \noindent In each case we can give to \code{map} a specialised |
662 \noindent In each case we can give to \code{map} a specialised |
662 version of \code{chk_string}---once specialised to 2 and once |
663 version of \code{chk_string}---once specialised to 2 and once |
663 to 3. This kind of ``specialising'' a function is called |
664 to 3. This kind of ``specialising'' a function is called |
664 \emph{partial application}---we have not yet given to this |
665 \emph{partial application}---we have not yet given to this |
665 function all arguments it needs, but only one of them. |
666 function all arguments it needs, but only some of them. |
666 |
667 |
667 Coming back to the type \code{Int => String => Boolean}. The |
668 Coming back to the type \code{Int => String => Boolean}. The |
668 rule about such function types is that the right-most type |
669 rule about such function types is that the right-most type |
669 specifies what the function returns (a boolean in this case). |
670 specifies what the function returns (a boolean in this case). |
670 The types before that specify how many arguments the function |
671 The types before that specify how many arguments the function |
685 scala> apply_3(mk_string) |
686 scala> apply_3(mk_string) |
686 res6 = true |
687 res6 = true |
687 \end{lstlisting} |
688 \end{lstlisting} |
688 |
689 |
689 You might ask: Apart from silly functions like above, what is |
690 You might ask: Apart from silly functions like above, what is |
690 the point of having function as arguments to other functions? |
691 the point of having functions as input arguments to other |
691 In Java there is indeed no need of this kind of feature. But |
692 functions? In Java there is indeed no need of this kind of |
692 in all functional programming languages, including Scala, it |
693 feature: at least in the past it did not allow such |
693 is really essential. Above you already seen \code{map} and |
694 constructions. I think, the point of Java 8 is to lift this |
|
695 restriction. But in all functional programming languages, |
|
696 including Scala, it is really essential to allow functions as |
|
697 input argument. Above you already seen \code{map} and |
694 \code{foreach} which need this. Consider the functions |
698 \code{foreach} which need this. Consider the functions |
695 \code{print} and \code{println}, which both print out strings, |
699 \code{print} and \code{println}, which both print out strings, |
696 but the latter adds a line break. You can call \code{foreach} |
700 but the latter adds a line break. You can call \code{foreach} |
697 with either of them and thus changing how, for example, five |
701 with either of them and thus changing how, for example, five |
698 numbers are printed. |
702 numbers are printed. |
781 SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r'))) |
785 SEQ(CHAR('f'), SEQ(CHAR('o'), CHAR('r'))) |
782 \end{lstlisting} |
786 \end{lstlisting} |
783 |
787 |
784 \noindent This gets quickly unreadable when the strings and |
788 \noindent This gets quickly unreadable when the strings and |
785 regular expressions get more complicated. In other functional |
789 regular expressions get more complicated. In other functional |
786 programming language, you can explicitly write a conversion |
790 programming languages, you can explicitly write a conversion |
787 function that takes a string, say \dq{\pcode{for}}, and |
791 function that takes a string, say \dq{\pcode{for}}, and |
788 generates the regular expression above. But then your code is |
792 generates the regular expression above. But then your code is |
789 littered with such conversion functions. |
793 littered with such conversion functions. |
790 |
794 |
791 In Scala you can do better by ``hiding'' the conversion |
795 In Scala you can do better by ``hiding'' the conversion |