μ Icon

1. μIcon ebbesen@itu.dk Bullets on parade

2. Preliminary: Continuation passing style • The code following a function call is wrapped up in a method - the continuation - and passed along as a parameter. • Calculating the n-th factorial recursively • In continuation passing style • Actually it’s the closure we’re passing along, so this style of programming restricts our choise of language (ML/C#/Java?), leaving out e.g. C and Object Pascal. fun fac 0 = 1 | fac n = n * fac (n - 1) fun fac (k, 0) = k 1 | fac (k, n) = fac (fn x => k (n * x), n - 1) n-th factorial = fac(fn x => x, n)

3. Icon - A crash course I • Whereas C, C++, Java and other related languages differentiate between statements and expressions, Icon has only expressions. • Icon expressions may either fail or succeed, and successful expression may generate not only one, but a (not necessarily finite) sequence of results. • A successful expression may produce either values or variables. (1 < 0) # failing "hi world" # generating a single value (0 to 9) # generating 0, 1, 2, ..., 9 (7 | 9 | 13) # generating 7, 9, 13 (x := 7) # generating the variable x (x | y | z) # generating x, y, z e.g. every ((x | y | z) := 1)

4. Icon - A crash course II • It's perfectly allowable for an expression to fail. • Icon provides many of the well-known control structures (if-then-else, while-do, etc.), where instead of boolean values, the success or failure of an evaluation determines control flow. • Failure is propagated through operators/functions, and thus the failure mechanism acts much like C#/Java exceptions. while line := read() do # read() fails on process(line) # reaching EoF while process(read()) # like above # neat isn’t it

5. Icon - A crash course III • Expression evaluation is goal-directed, in the sense that an outer expression will resume its inner subexpressions in an attempt to succeed. • Inner expressions are resumed from right to left why we use the term backtracking. write((i := (0 to 9)) & (3 < i)) # eventually succeeds, writing out 4 (7 < write(y <- (0 to 9))) # writes out "0 1 2 3 4 5 6 7 8" before # eventually succeeding, generating 8

6. Icon - A crash course IV (a few oddities) • Unlike their cousins in C/C++/Java, Icon variables are typeless. Values however are typed. • Icon variables may carry any type of value, and type conversion of the variable value will be performed automatically as required. • Icon variable are late bound, i.e. dereferenced only when the value is needed. • Procedure arguments are passed by value, however due to the late binding of variables, dereferencing is not done until all arguments have been evaluated (arguments are evaluated from left to right, C/C++ make no such promises): fun(x := 1, x := x + 1); # calls fun with the arguments (2, 2)

7. μIcon • All μIcon values are of integer type. • Regular Icon procedures are first class citizens, and may be assigned to variables, passed as arguments, etc. μIcon procedures are not, but are similar to C functions. • Only local variables are supported, global variables are not. • μIcon includes only a small subset of the full set of Icon expressions. • μIcon procedures have so far accepted only a single argument. Today we'll add support for multiple-argument procedures.

8. The inner workings of the interpreter I (data) • [Griswold] “The term outcome is used to describe the result of evaluating an expression, whether it is success or failure.” • [Griswold] “The term result is used collectively to include both values and variables.” +----------+ | Outcome | +----------+ ^ ^ | | | +----------+ | | Failure | | +----------+ | +----------+ +----------+ | Success |<>---->| Result | +----------+ +----------+ ^ ^ | | | +----------+ +----------+ | | Variable |<>---->| Store |<>---+ | +----------+ +----------+ | | | +----------+ | | Value |<----------------------------------+ |----------| | int: i | +----------+

9. The inner workings of the interpreter II • All expressions implement the Expression interface, defining a single method Eval taking as input four continuations and a run-time environment. • If the expression succeeds, we'll call the success continuation cont passing along the produced result as well as a backtracking continuation, allowing an enclosing expression to ask for more results. • The second argument fcont is the failure/backtracking continuation, to be called if the expression fails. public interface Expression { OutcomeEval(Cont cont, Fcont fcont, REnv env, Cont rc, Fcont rfc); }

10. Multiple-argument procedures I • Let’s have a look at the source code (you might want to bring along a cup of coffee).

11. Multiple-argument procedures II

12. A few perverted examples • The late binding of variables: • Generating a new set of arguments if the body fails: procedure sum(a, b) # writes 2 to return (a + b) # standard out end procedure main () x := 0; write(sum(x, x := x + 1)) end procedure backtrack(i, j) # writes "0 1 2 3 4" return 3 < write(j) # to standard out end procedure main () backtrack(x := (0 to 9), y := x) end

13. Concluding thoughts (highly subjective) • Think twice before introducing continuations and apply with care, as the readability of your code will suffer greatly (did anyone spot the error in the report?) • While the goal directed evaluation of expressions is an intriguing idea, I’ve yet to come across a problem where this brute force approach would the best answer. • Honestly, I can't for the love of God see how the late dereferencing of arguments will lead to anything but trouble. • I do appreciate how making failure of expressions an integrated part of the language allows for very elegant code (a kind of lightweight exceptions). • Keep in mind though that you’ll only be able to appreciate the value of an answer once you know the right question…