The problem with programming languages is that you can't just throw up a few screenshots on the website to show off how cool it is. You need to show code and then point out how cool it is, preferably in a brief and witty way.
Oh well.
Instead, I give you the Fibinacci Examples:
You all know what the Fibonacci sequence is, right? So I don't need to explain that it's a sequence of numbers:
1 1 2 3 5 8 13 21 34 55 89 144 233 ...where each number is the sum of the two previous numbers. Which is good because explaining all of that would take forever!
It's pretty simple to code a procedure that prints out some of the Fibonacci series:
proc printFibs [count] {
var first = 1
var second = 1
for n in (1 .. count) {
say "$first "
var ns = (first + second)
first = second
second = ns
}
puts
}Obvious things:
proc defines the procedure, printFibs is the name of the procedure, [count] is the argument list and the rest is the procedure body.
var declares a variable.
say prints its argument(s). puts does that too but it adds a newline.
for itterates over a range of numbers.
Deck provides Perl/Tcl/shell-style variable interpolation in strings. (E.g. "$first " contains the value of variable first.)
Less-obvious things:
If you think of a program "line" as not ending until all the brackets are closed, then the entire procedure can be thought of as one line.
The text between braces ({ and }) is subdivided into "lines" as above, making a single "line" able to contain multiple other "lines".
Therefore, each Deck statement is a single "line". Furthermore, the first item in the "line" is the procedure to call and the remaining items are the arguments to pass to it.
Expressions bracketted by round parentheses (( and )) are parsed as infix expressions (e.g. (2 + 3) instead of [+ 2 3]).
Assignments (e.g. first = second) have imaginary round brackets around them. So does the expression after var.
Notice the round brackets around the third argument to the for statement: (1 .. count). This is an infix expression. In fact, .. creates an object (type Interval) which mimics a list containing the range of integers between the left-hand-side and right-hand-side arguments. From this, it becomes clear that what for actually does is evaluate its body for each element of a list-like object it receives. (Unlike most Lispish languages, Deck lists are actually arrays (aka vectors).)
You'll notice that a lot of statements take arguments that look like they should be evaluated but aren't: the word printFibs after proc, the n after for, the variable names, etc. In most Lisp dialects, the language has a fixed number of Special Forms--things that look like functions but have their arguments parsed differently.
Deck has one special form, the quote symbol: :. Things prefixed by a colon are not evaluated. However, there is no quoting in the example above. (Actually, that's not true: { is an implicit quote, but I'm not going into that here.)
Instead for, var and proc are all macros. In Deck, a macro is simply a function called by the compiler to modify the current expression in some way--a compiler plug-in, as it were. proc (to pick an example) invokes a macro that replaces the proc statement with another expression (a call to an undocumented internal procedure) in which all of the arguments have been normalized and the bare words quoted.
Most of Deck's built-in functionality is implemented this way.
Subject to the Laws of Computer Science, whenever I use the Fibonacci series in a programming example, I am required to show you a recursive implementation, so here it is:
proc fib {index} {
(index <= 2) && [return 1]
return ([fib (index - 1)] + [fib (index - 2)])
}Of course, it also needs this function:
proc printFibs {count} {
for n in (1 .. count) {
say [fib n] " "
}
puts
}Needless to say, it is 1) minimal and elegant and 2) pig slow because for each new Fibonacci number, it needs to recalculate the entire series. However, from this code, I can point out a few more things:
Square brackets ([ and ]) delimit subexpressions in the standard Deck form (i.e. prefix expressions). For example: [fib n].
Like assignments, expressions made up of && and || also have implicit round brackets. This lets you do Perl-style flow control with short-circuited boolean operators, as I do in the first line of fib.
Counter-intuitively, the <= expression needs to be surrounded by round parentheses so that the outer expression it lives in continues to be made up of only && and || operations.
proc lets you wrap the argument list in braces ({ and }) instead of square brackets. This is pure syntactic sugar by proc in order to make Tcl programmers a bit more comfortable.
Now, we start getting to the contrived examples:
proc fibFn {} {
var {first = 1; second = 1}
return {} => {
var newSecond = first + second
var result = first
first = second
second = newSecond
next result
}
}
proc printFibs {count} {
var ff = [fibFn]
for n in (1 .. count) {
say [ff] " "
}
puts
}As you know Bob, a closure is an anonymous function that has access to the scope in which it was created. The Deck operator => creates a closure: the left operand is the argument list and the right is the function body.
So proc fibFn defines and initializes the variables first and second, then creates and returns a closure. printFibs takes the closure (referenced by variable ff) and calls it repeatedly to generate each new number in the Fibonacci sequence. The current and next Fibonacci numbers are stored in first and second in fibFn which, having exited, are now only visible to the closure.
Things to note:
The => expression in fibFn doesn't have round brackets around it, even though it should. That's because the parser automatically surrounds a => expression with them in an infix expression. This is more syntactic sugar.
The return statement has been renamed next inside a closure. This is so that you can return from a closure without returning from the function that created it.
While you never see it in this document, => is actually a convenient alias for sub which also creates closures but in a prefix way. => is more convenient but sub also lets you add a final block the closure.
return and nextWhile we're talking about return (and next) I should explain just how frickin' cool they are.
In most languages, return is a control structure. Using it makes the compiler (or interpreter) exit the current function. In Deck, return is a callable object of type Continuation. Calling it like a function returns the function in which it was defined and if necessary, every function it's currently calling. For example:
proc i2 {ret} {
ret 42
puts "i2 done"
}
proc i1 {ret} {
i2 ret
puts "i1 done."
}
proc i0 {} {
puts "starting i0"
i1 return
puts "done i0"
}
proc outer {} {
puts "calling i0"
i0
puts "done i0"
}
outerwhen run, produces this output:
calling i0
starting i0
done i0i0 passes its return as an argument to i1 which calls i2 with it. When i2 finally calls the continuation, the call sequence is completely unwound and i0 returns. If ret had been given an argument, it would have been used as the return value.
(In closures, return has been renamed to next but is otherwise the same.)
Since unexpectedly returning from a procedure can leave loose ends, a proc (or method or closure) may take a final block. The final block is just another chunk of code added to the end of a procedure with full access to namespace. However, it is guaranteed to execute, no matter how the procedure returns. This lets you do stuff like this:
proc readDataFile {fileName} {
var fh = [openDataFile filename]
[readHeader fh] || [return false]
[readBody fh] || [return false]
return true
} {
closeDataFile fh
}Because the second block always executes, closeDataFile is always called, even if readDataFile returned when readHeader called a continuation stored in a global variable or some equally idiotic thing.
As mentioned above, Deck has macros. Unlike Scheme, there is no effort to make Deck macros hygenic or simple. They're just procedures that the compiler calls when it finds a matching expression. The compiler passes the expression to the macro and then tries to compile whatever it returns. This is simple, powerful and ugly. If you've led a good life, maybe you won't ever need to use them.
Deck also has a nicer lightweight macro called an mproc. An mproc is just a procedure whose calls get modified in various simple ways by an automatically-generated macro. MProcs can add default arguments to a procedure, automatically quote a bare symbol or list or turn a list argument into a closure.
This latter feature is often used to add new control structures. For example, this:
mproc repeat {
count
sub 1 pr
} {
for i in (0 .. count - 1) {pr i}
}can be called like this:
repeat 5 {puts "I like pie!"}The special declaration of argument pr turns its second argument into a closure.
Okay, back to Fibonacci.
The third implementation uses an infinite stream. This is an infinitely-long linked list which fakes infinity by computing the n'th element just before you need it. We do this by putting a procedure at the end of the list and evaluating it when we get there. The procedure computes a new node containing the next value and another procedure and this gets attached to the end.
Since Deck lists are not linked lists the way they are in $FAVOURITE_LISP_DIALECT, I first need to implement linked lists using a class:
class Node {
public head tail
method _init {h t} {
head = h
tail = t
}
}This is pretty straightforward:
head and tail are instance variables (aka object fields). The public declaration means (obviously) that external code can read and write the value.
_init_ is called when an instance of Node is created to initialize it.
This is a "dumb" data structure. It holds information but any processing is done by external code, just like a C struct. Since we need to process tail, we need a function to evaluate it:
proc getTail {node} {
if (node.tail.isCallable) {
node.tail = [node.tail]
}
return node.tail
}This function returns the tail field of Node instance node. If node is a callable object, it first calls it and replaces the value of node with the result. (It also breaks if the list contains real callable values, but we're not going to worry about that now.)
The list gets set up by the function fib:
proc fibs {v1 v2} {
return [new Node v2 {}=>{fibs v2 (v1 + v2)} ]
}So the last item in the list is always a closure which returns a new Node containing the Fibonacci value in its head and a new closure in tail and the new closure does exactly the same thing for the next item.
The printFibs procedure looks like this:
proc printFibs {count} {
var stream = [fibs 0 1]
repeat count {
say stream.head " "
stream = [getTail stream]
}
puts
}As you can see, it uses fibs to create the first node, then calls getTail on the stream to generate the next node.
Some more details:
The . operator is used to access the (public) fields of Node. It can be on either side of an assignment.
., like => is treated specially by the parser. The sequence left . right is automatically surrounded by round brackets whenever it is seen in a prefix expression.
Calling getTail is pretty cumbersome. Fortunately, Deck's object system lets us fold that functionality into the Node class. The new Node looks like this:
class Node {
readable head
var tail
method _init {h t} {
head = h
tail = t
}
method tail_get {} {
(tail.isCallable) && (tail = [tail])
return tail
}
}There are three changes:
head is now readable, which means it can't be modified by external code. This change is not strictly necessary (and we could have made it readonly in the previous example) but it makes for better code overall.
tail is now declared private with the var word.
Method tail_get has been added. This is what gets called when external code tries to read tail. It contains the functionality that used to be in getTail so now, just accessing the tail field does the right thing.
And here's the (slightly) modified printFibs:
proc printFibs {count} {
var stream = [fibs 0 1]
repeat count {
say stream.head " "
stream = stream.tail
}
puts
}This looks a lot cleaner.
Here are a couple of other things you should know about object attributes:
In addition to var, public and readable, fields can be declared writable. This makes then settable but not readable.
It is also possible to override writing to a field by defining a method which takes one argument and has the same name as the field with _set appended. E.g. for field head, it would be named head_set.
So far, it looks like I'm implying that the _get and _set methods are being called by a field access. It's actually backwards. All class fields are private and declaring a field public (or readable or writeable) causes the compiler to generate trivial getters and setters.
You may write a getter or setter for a non-existent variable. That is, the public interface does not need to correspond to the internal structure of the class.
(Attribution: I stole the idea of infinite streams from Mark Jason Dominus's book Higher Order Perl who stole it from somewhere in Lisp Land.)
The examples in this document aren't particularly good at highlighting all the interesting corners of Deck's object system, so I'm taking a few paragraphs to drop knowledge on you.
In Deck, everything is an object. This includes classes, which are all instances of the class Class. This includes Class itself which is its own class. Classes can be passed around and queried but all classes have the same interface. This means that there's no such thing as a class (aka "static") method or field. Instead, you should use packages. (See the reference manual for a long, tedious description of those.)
Instance variables in classes are only visible to the methods defined in that class, not in any subclass. Their scope is the equivalent of private in C++. This doesn't work:
class Inner {
public foo
method _init {x} {
foo = x
}
}
class Outer Inner {
method bar {m} {
puts m foo # ERROR: foo not visible
}
}But this will work:
class Outer Inner {
method bar {m} {
puts m self.foo
}
}This is because self.foo invokes the getter method defined by public. (self is a reference to the current object.)
(Note that there's a bug in the current implementation of Deck that prevents you from defining an instance variable with the same name as an instance variable in a parent class even though they are unambiguous.)
Methods are normally invoked using the -> operator:
var x = [new Outer]
x->bar "Value: "(-> is syntactically magical just like . and =>.)
The semantics of -> are interesting by themselves. The result of x->bar is a callable object called a MethodCall. This encapsulates the result of the method search for bar in x. When called like a procedure, it calls the method found (usually bar) with self set to x and with whatever arguments it was given. The MethodCall can thus be stored or passed around:
var barMethodCall = [Outer->new]->bar
...
barMethodCall "Value: "If the method lookup fails (i.e. there is no method with that name in the object's class heirarchy), the lookup calls the special method doesNotUnderstand instead. Default behaviour for doesNotUnderstand is to exit with a backtrace but individual classes may override this behaviour.
If the left side of a -> or . is the word super, it is used as an alias for self but the method search starts in the superclass instead of the base class. This lets you override a method but call its base implementation:
class MoreOuter Outer {
method bar {m} {
super->bar m
puts "MoreOuter!"
}
}Methods whose names begin with an underscore (_) are considered private to the class heirarchy (what C++ calls "protected"). It is an error to use a name starting with an underscore in a -> expression unless the left-hand-side is either self or super:
self->_privateThingy 42 # Correct
super._kindOfPrivate = "maybe" # Also correct
foo->_reallyPrivate "yes" # Error!As you can see, this works on attributes too, so you can give instance variables a "protected" scope.
Note that it is possible to defeat the underscore rule. -> is a macro and it performs the check at compile time. The code that the macro emits could be hand-written instead, bypassing the check. Thus, you may need to enforce the underscore rule yourself with a blunt instrument.
(Hah hah, just kidding! Use a knife.)
(Still kidding! I don't condone violence, even against really idiotic coders. Just glare at them.)
As you have seen in the above examples, there are two ways to create a new object from a class. You can use the built-in new function:
new SomeClass "this is an argument"or you can use the class's new method:
SomeClass->new "this is also an argument"The two forms are equivalent and you can use whichever one looks nicer in context.
Early on, I explained that the (1 .. count) sequence in a for statement actually created an object which mimicked a list of integers in increasing order. From that, you may have suspected that it would be easy to create a class which mimics a list of Fibonacci numbers. And you'd be right.
With such a class, printFibs becomes almost trivial:
proc printFibs {count} {
for n in [FibonacciList->new count] {say n " "}
puts
}The class FibonacciList does all of the heavy lifting:
class FibonacciList {
var first second
var prevCallIndex
readable size
method isIndexable_get {} {return true}
method _init {sz} {
size = sz
self->_reset
}
method _reset {} {
first = 1
second = 1
prevCallIndex = 0
}
method at {index} {
self->_update [self->_sanitizeIndex index]
return first
}
method _update {reqIndex} {
(reqIndex >= prevCallIndex) || [self->_reset]
repeat (reqIndex - prevCallIndex) {
var ns = first + second
first = second
second = ns
}
prevCallIndex = reqIndex
}
}The method _update does all of the actual work. It computes the reqIndex'th Fibonacci number. If the previous call's results come before reqIndex in the list, then it computes them from there. This is reasonably efficient if you only need to read the list from start to finish.
This class implements everything required to mimic a list. We call this the Sequence Protocol. Specifically:
A readable isIndexible attribute must return true. Class Object already implements a version of this that returns false so it is safe to use this to test a class for the presence of the rest of the sequence protocol.
size needs to be implemented to return the number of items in the list. In the example, it's an actual readable field but as with all attributes, this can also be implemented with a _get method.
at takes one argument--the index--and returns the corresponding element. The index must be an integer between 0 and (size - 1). In addition, negative indexes are allowed and interpreted as being relative to size. E.g. index -4 is treated as (size - 4). The private Object method _sanitizeIndex converts negative indexes to positive ones. How the object handles out-of-range indexes is undefined. This one allows them.
Two optional items: atPut to store values and readable attribute maker which returns a function to create an empty sequence of a compatible type. (The default implementation returns a List.)
Most of the time, you won't need to call at or atPut directly. Instead, the @ and = macros are used. Reading a list item looks like this:
puts "Item: " (theList@42)In this case, @ is a macro that expands into to a call to the at method of its left argument.
Storing looks like this:
theList@42 = "item 42"In this case, the assignment macro (=) expands the entire expression into a call to atPut method of the first item with the second (right of @) and third (right of =) as the index and value arguments.
If you're still interested in Deck and want to read more manuals, there is a language reference manual.pod and a library reference lib.pod.
The library reference lists every procedure, macro, mproc and class available to you along with a maddeningly brief description of each. The language reference, meanwhile, explains the minutia of every nook and cranny of the Deck language as well as its deficiencies.
If you just want to see source code, the Deck library source code is in the lib-deck directory and a number of example programs (including the ones seen here) are in the directory progs.
Finally, the Deck interpreter itself is written in (ahem) highly readable Perl.