Lambda the Ultimate

Even though message passing can be thought of as a special case of the generic functions approach, there still seems to be something appealing about grouping procedure implementations and their shared data into logical units as in Smalltalk. I understand that polymorphic dispatch need not be conflated with program modularity / encapsulation, but for some reason it still feels like a good idea to me. I looked around this afternoon for a good discussion of multi-methods vs. message passing and came up empty, so I'm wondering if anyone could point me to one or share their thoughts on the issue.

I am interested in writing a lispy scripting language that integrates with the Apple's Cocoa environment, which is based on Smalltalk and therefore hardcore message-passing based. I would like a seamless connection into that world from this language. But I also want the power of multi-methods. I am imagining a language in which first-class namespaces could be blended with the Smalltalk approach to objects, exposing methods that respond to messages. But within these namespaces multi-methods could be used when they seemed appropriate. Therefore, in the large, the program would be assembled out of modules that resembled Smalltalk objects, but the implementation of methods exposed by these modules could have a lispier style. This is all very vague I know... and there's the obvious question of where multi-methods would belong. Any ideas?

Is it possible to do type inference of an object oriented language (such as Java) without any type annotations? I've never seen it done and I'm curious about why that is. During my limited exposure (to type inference in general) I've been taught that it is possible to do type inference of rank 1 polymorphic functions but the general case (rank 2 and up) is undecidable without type annotations. How does this relate to the type of polymorphism used in object oriented languages?

One of my best friends is a Ph.D. student in a well-respected geology department, and an avid R user. He informs me that the programming language "R" is highly fashionable in his department, and is increasingly popular across his field.

I mention this because R encourages functional programming, and I have not heard it mentioned on LtU. Here is a quote from the language manual:

R is a system for statistical computation and graphics. It provides, among other things, a programming language, high level graphics, interfaces to other languages and debugging facilities. This manual details and defines the R language.

The R language is a dialect of S which was designed in the 1980s and has been in widespread use in the statistical community since. Its principal designer, John M. Chambers, was awarded the 1998 ACM Software Systems Award for S.

The language syntax has a superficial similarity with C, but the semantics are of the FPL (functional programming language) variety with stronger affinities with Lisp and APL. In particular, it allows “computing on the language”, which in turn makes it possible to write functions that take expressions as input, something that is often useful for statistical modeling and graphics.

It is possible to get quite far using R interactively, executing simple expressions from the command line. Some users may never need to go beyond that level, others will want to write their own functions either in an ad hoc fashion to systematize repetitive work or with the perspective of writing add-on packages for new functionality.

Here is another quote from the FAQ:

The design of R has been heavily influenced by two existing languages: Becker, Chambers & Wilks' S and Sussman's Scheme. Whereas the resulting language is very similar in appearance to S, the underlying implementation and semantics are derived from Scheme.

The upshot is that "S" is dynamically scoped while "R" is lexically scoped. I applaud R for getting this right, but the FAQ makes an interesting counterpoint that I paraphrase here:

Nested lexically scoped functions also imply a further major difference. Whereas S stores all objects as separate files in a directory somewhere (usually .Data under the current directory), R does not. Having everything in memory is necessary because it is not really possible to externally maintain all relevant environments of symbol/value pairs. This difference seems to make R faster than S.

The down side is that if R crashes you will lose all the work for the current session. Saving and restoring the memory images can be a bit slow, especially if they are big. In S this does not happen, because everything is saved in disk files and if you crash nothing is likely to happen to them. (In fact, one might conjecture that the S developers felt that the price of changing their approach to persistent storage just to accommodate lexical scope was far too expensive.)

Other than scope, R tries to be as close to S as possible. I'll end with two amusing remarks from the introduction:

Warning: for() loops are used in R code much less often than in compiled languages. Code that takes a `whole object' view is likely to be both clearer and faster in R.

Note that any ordinary assignments done within the function are local and temporary and are lost after exit from the function. Thus the assignment X <- qr(X) does not affect the value of the argument in the calling program.

Enjoy.