The Wizard of Oz
Oz is a multi-paradigm programming language that combines likely all the features from every language you've ever seen and then some. But how easy is it to do useful work with it? What are its pros and cons as a language?
Our final review of Oz, summarizing the work below, can be found here. This page contains a modified version of the Google Document that we were mandated to maintain during the course of this project. It should be noted that this page is not intended to be a thorough review of Oz and it should be taken as merely a review of pseudo-random language features over the course of several months.
Proposal: The Oz programming language is unique in the sense that it is a multi-paradigm programming language. It combines aspects from eight different paradigms to give the programmer the most in terms of flexibility and power. Whereas some programming languages have caused dedicated users to pit off against one another (think Java v. C/C++ or functional language users v. imperative language users), Oz is designed to bring programmers together.The eight different paradigms employed in Oz (with an example application in Oz) are:
- Concurrent: Has built-in language constructs for message passing, locks, and transactions.
- Constraint: Some operators are overloaded, and the language's implementation can reason and deduce conditions about the given constraints.
- Dataflow: If a variable is used without having a value defined to it, the thread it belongs to blocks until another thread defines the value.
- Distributed: Dataflow values describes previously allow for any value to be a built-in network synchronization value.
- Functional: Allows for the use of anonymous functions, functions to be executed lazily (they can be flagged as such), and function currying.
- Imperative: If/then blocks, case statements, and local blocks allow for imperative-style coding.
- Logic: Keywords are added to support logic programming and existing control flow keywords are implemented in a similar way by the compiler.
- Object-oriented: Supports a class and object model with multiple inheritance. Exceptions can also be thrown by the user or the system.
The two main areas we wish to investigate are (1) how Oz consolidates features across multiple programming paradigms, and (2) how to implement a simple GUI web browser using the Oz programming language.
The main reference material used for Oz is the definitive book, Concepts, Techniques, and Models of Computer Programming, by Peter van Roy and Seif Haridi. The Amazon link can be found here, and a draft of it can be downloaded for free here.
Update for Week ending 01/25/08: Implementing a GUI web browser may be easier than we originally thought. When declaring new files, Oz allows the user to point to a web address instead of to a file on the local system. After doing so, Oz fetches it (but dies if it can't be found), and saves the returned page in a String. The following Oz code fetches the contents of my UCSB CS web page and displays it on the screen:
functor
import
File at 'x-oz://system/File.ozf'
QTk at 'x-oz://system/wp/QTk.ozf'
define
InfoHdl See={NewCell true}
WebPage = {File.readList 'http://cs.ucsb.edu/~cgb'}
D=td(title:"My First GUI"
label(text:WebPage handle:InfoHdl glue:nswe))
{{QTk.build D} show}
fun {Msg}
if @See then {Delay 50} {InfoHdl set(text:Msg)} end
end
end
Since no parsing is done, the resulting string still contains all the HTML tags of the given page. However, this proof-of-concept shows how simple it is to fetch web information. We still need to explore how Oz deals with exceptions to deal with 404's in a more graceful manner. Having done this, we are considering other applications which would better use Oz's capabilities.
Update for Week ending 02/01/08: Currently trying to implement basic quantum computation functions in Oz. At a high level, doing so allows us to examine many varied features about the language, including how to deal with lists, using math libraries / functions, and single assignment variables. May return to this at a later date.
Update for Week ending 02/08/08: Have been investigating the various quirks of Oz. Oz is a dynamically typed language, and variable names must begin with an uppercase letter. We are unable to find the mechanism used for standard input in Oz (stdin), having checked both the book and official online tutorial.
That being said, there are three input mechanisms we have seen in Oz. The first is making a GUI interface and using events to read input from text fields. An API is provided for reading and writing to files. Finally, the runtime / development system for Oz, Mozart, allows the user to run regions of code dynamically. With this, the user can write code to declare variables, feed that to the runtime, and later instantiate them or use them however they please. The latter method appears to be the preferred way to input data to programs, as it is overwhelmingly used by the book in examples and the like.
As far as output mechanisms go, the web site gives a function that can be used for standard output, but it is never used in the book. The book (and majority of the site) use a module called the 'Browser', which is an intelligent GUI that displays data.
It is inteligent in the sense that in Oz, using an undeclared (undef'ed) variable causes the containing thread to block until a different thread gives it a value (defs it). The browser is not subject to this restriction, and prints values of undeclared variables as "_". Later, once a value is assigned, the browser overwrites the "_" with the value. A simplified version of the code the book gives is this:
thread A in
{Browse 'Value of A'#A}
{Delay 3000}
B = A + 1
end
thread
{Delay 1000}
A = 1
{Browse 'Value of B'#B}
end
Note that # is the string concatenation character, and that the Delay function causes a thread to sleep for the given number of milliseconds. At the initialization of the program, the output looks as follows:
Value of A#_
The "_" indicates that A has not been bound to a value yet, and that although # concatenates strings, it (unfortunately) still prints out when it is passed to Browse. After a second, A's value is updated and the second thread finishes execution. The output now looks like this:
Value of A#1
Value of B#_
After two more seconds, the first thread resumes execution and assigns a value to B. It then finishes execution and the final output looks as follows:
Value of A#1
Value of B#2
Will return to the quantum functions next week after we find the function that determines whether a value is a list or a scalar, as there is no syntactic sugar to produce 2-D arrays (asides from making arrays of arrays).
Update for Week ending 02/15/08: We have spent this week looking over how to perform basic network communication. Although strings can be created whose content is fetched from a web page, we are unable to find material in the book referencing network traffic.
Ports are (abstractly) provided in an different sense: they are implemented as data types and are essentially mailboxes / FIFO queues, paying an homage to C.A.R. Hoare's Communicating Sequential Processes. The paper is cited and the implementation is the same: any thread can pass around capabilities (references) to a mailbox, and any thread with the reference to a mailbox can read a value from it (dequeue) or write a value to it (enqueue). Thus two threads can message each other through the use of these mailboxes in a very simple manner. We are still examining how to do this over the network or through network ports, as these abstract ports fail to name a specific actual port they are listening on for traffic (if any).
The Mozart (Oz Runtime environment) repository online does provide some libraries for network communication protocols (XML-RPC), but they are designed on Windows and appear to only work on Windows (we are running a Mac). Mozart claims portability across platforms through the use of a virtual machine, but this does not appear to be the case with packages. This may be because Oz allows communication between code in its language and code in C/C++, which is not always portable. There are also only 68 packages available on the MOzart Global User Library (MOGUL), and as a new version of Oz has not been released in two years, more packages do not seem to be coming in the near future.
The Mozart web site does have information on creating sockets, however. More on this soon.
Update for Week ending 02/22/08: We have been examining forms of distributed computation and concurrent primitives provided by Oz. Locks and monitors are provided in a similar fashion as is done with Java, but may be more useful in Oz since its threads are more lightweight than in Java. Locks are also used to implement transactions in Oz, and monitors are implemented as they were originally designed by Hoare (note they are different than POSIX monitors).
Remote Method Invocation (RMI) is provided in Oz, but their implementation seems to be for the local case only. Presumably it scales up, but it is not clear from their implementation. Callbacks are also possible, and these invocations can be specified to be synchronous or asynchronous (specified by the programmer). Message passing is also implemented for the programmer in a simple fashion.
Update for Week ending 02/27/08: We have spent this week building on the last two. Whereas before we examined concurrency (multiple processes on one system), we now discuss distributed computing (multiple processes on multiple systems). The Oz book describes the ability to pass dataflow variables and functions over the network, but does not describe the implementation of this. It is hinted at that the runtime on each system silently checks for changes to exported variables / functions, but not explicitly stated. Furthermore, all the implementations are concurrent despite being in the distributed chapter of the book. They do say that this works over TCP, but all the sample code is for local machines only. At one point, it is stated that we can pass around 'tickets' (an object's world-unique reference) and these tickets can be used by other systems. However, the tickets are unique strings containing the system's IP and seemingly random numbers, and the book and web site state that this ticket data must be hand-copied from server to client, thus ruining any hope at automation.
Distribution can be done in other ways. There are sockets, although their syntax is somewhat limited, and creating one will block all processes on the Oz runtime. Alternatively (and much more interestingly), since functors (interfaces that define functions imported and exported in a program) are first-class values, we can create and export them to web addresses on the fly. We are unable to test this, but the code is as follows:
functor
import Pickle Connection
define
% Create server
thread Str Prt Srv in
{NewPort Str Prt}
thread
{ForAll Str proc {$ S} S="Hello world" end}
end
proc {Srv X}
{Send Prt X}
end
% Make server available through a URL:
% (by using a filename that is also accessible by URL)
{Pickle.save {Connection.offerUnlimited Srv}
"/cs/student/cgb/public_html/test"}
end
end
Running this server code saves the contents of the 'Srv' method and anything it needs to function in the given directory, which can then by accessed by a web browser (in this case http://cs.ucsb.edu/~cgb/test). The client's Oz runtime then runs it and would receive back "Hello World", but it is unclear how far the current Oz runtime integrates with today's web browsers (presumably little). That being said, the concurrency options in Oz (and extensions provided by the book) are excellent. The distributed options, unfortunately, are quite lacking. This is compounded by the fact that the online libraries are not platform independent. Looking over the remainder of the book (and this proposal), our final update will either be an extension to the GUI talk from the first update, an exploration of constraint programming, or logic programming.
Also, apparently simple printing to standard out and standard error is supported via simple calls System.printInfo and System.printError, despite the fact that this feature is completely unreferenced in the book or on the tutorials. Had to dig around the system call list, of which a small subset is here.
Chris Bunch
Last Modification on 05/13/08
First Revision Complete 01/30/08
CSS Style Sheets and Web Layout designed by Ben Meadowcroft
The CSS style sheets used here are licensed under a Creative Commons License.