Lambda the Ultimate

Trying to itemzie the essential characteristics of a languages (e.g., everything is a process) can be quite worthehile.

Ages ago, I taguht Prolog to a few people. To help the understand the language I listed a few principles which I called The Prolog Philosophy ("The closed world assumption"). Sometime later I read Wittgenstein, and was amused to see how well his major propositions mapped to the list I made. In fact, 1, 1.1, 1.2 map directly to Prolog...

That reminds me of the OOP dogma everything is an object.

The problem with a dogma like that is that all the complexity gets collected into the target, i.e., process or object. It's fine for getting rid of some excess baggage in a language, but as a general language design principle, everything is an X is terrible (or at least, naive).

(See section 7.5.4 in CTM for my take on everything is an object.)

All Inferno resources, both local and remote, are represented as a set of dynamic files within the hierarchical file system. These files are used to represent, among other things, storage devices, processes, services, networks and network connections.

You show that syntax can be designed nicely for writing down basic data structures and for pattern matching. You also show that this isn't nearly so nice in regular C++ syntax.

But you only mention Lisp (Scheme)'s syntax briefly and dismissively. It is easy to build pattern-matching syntax in Lisp that's about as nice as in Erlang. More importantly, it's easy to invent a new pattern matching syntax to suit the occasion - for example, to match properties of abstract data types. In these cases it makes the code much more concise. This is a huge feature to just dismiss in my opinion.

The inability to use the nice pattern matching syntax for abstract datatypes is a source of frustration in the Erlang world. See e.g. Richard O'Keefe's "abstract patterns" proposal (http://www.erlang.org/ml-archive/erlang-questions/200309/msg00309.html) and Thomas Lindgren &friends's "Implementing The Mobile Location Protocol" experience report (http://citeseer.nj.nec.com/574647.html). (Oops, Thomas doesn't complain about support for ADTs in that paper - but he did when he presented it :-)

That said, I enjoy the fact that Erlang discourages the use of abstract datatypes, most of the time.

Also, I get the feeling you were holding back when you wrote "Scheme has a uniform syntax which does not necessarily make it more readable." :-)

But you only mention Lisp (Scheme)'s syntax briefly and dismissively. It is easy to build pattern-matching syntax in Lisp that's about as nice as in Erlang. More importantly, it's easy to invent a new pattern matching syntax to suit the occasion - for example, to match properties of abstract data types. In these cases it makes the code much more concise. This is a huge feature to just dismiss in my opinion.

Witness what had to be done in Flow Java, and more off this topic, but still... witness what had to be done to get nice looking pattern matching in HydroJ.

Since it's not supposed to be about the syntax, it's funny how much it is about the, well, syntax.

</syntax-discussion>

I should have asked Peter: does Oz have some mechanisms that serves a similar purpose to syntactic abstraction? It seems that e.g. Smalltalk gets along a great deal better here than Java/C++, without any form of macros. So Lisp isn't the only game in town.

(I'm actually only somewhere in Chapter 2 of the book, I just skipped ahead when I saw the reference here :-))

By the way, some Smalltalker just rewrote a 66-line Lisp program that I was pretty proud of in three lines of Smalltalk. I gotta try me some Smalltalk hacking too :-)

|class|
class := Smalltalk allClasses atRandom.
Browser fullOnClass: class selector: (class methodDict keys atRandom).

I haven't run it. The Lisp code is at http://groups.google.com/groups?selm=lhoexds818.fsf%40dodo.bluetail.com

In fairness, I don't think the Smalltalk code is a sufficiently faithful port. I want to examine specific code, so it should perhaps only consider methods contained in an image diff (or something). But it does make me think about diverting some of my Emacs hacking time to having a whack at Squeak.

In this case it does, because you don't have to go into all the source file cruft the Lisp code mucks with. You just ask Smalltalk for its classes, ask the classes for a random one, as the class for its methods, and ask the methods for a random one.

Then browse that method.

(Seems like everything being an object might *not* be a bad idea after all?)

8^)

By the way, after you build all this infrastructure in Lisp, the code for *your* Lisp task would be also only a couple of lines, as with Smalltalk.

It's not that the Smalltalk system does not have to parse text, it's just that the code for doing so is assigned to an appropriate object, i.e. in the compiler. Once the code is compiled, you are working with objects in the image. Which makes sense.

Ha.

Andrew, we missed you.

In VisualWorks I'd have a look at the implementation of the Store repository. It has code for all the diff stuff. In fact I probably would not have to diff images at all if I were using Store.

If I were not, and I had to diff images, I'd run them both, passing messages back and forth. e.g.

"Send me your list of class symbols."
"Send me your list of method symbols for this class."
"Send me your code for this method."

Then I might have to write the code to compare two versions of the code for a method. But that's probably not a *lot* of work. (I'd probably try to use "diff" at first.)

the three lines of Smalltalk
Well, that works in ye olde Smalltalks where there's a single namespace, and no other organizational structures. Long ago, they moved on to versioned configurations and applications (as well as versioned classes and methods), and now VisualWorks has moved to multiple user-definable namespaces.
So first, you'd have to pull the classes out of each application or namespace, then select a class, then select a method (bumps-up the line-count a bit.)

image diff
Why?
To extend Patrick's Kent Beck quote - "I mean, source code in files. How quaint. How 70's."
The big Smalltalk projects of the last decade were probably using a fine-grained code repository, and that's were we'd do the diff - at multiple levels: versioned configurations, applications, classes, methods.

gotta try me some Smalltalk hacking too
Seems like this would even be easier in C# than 66 lines...

   GetCallingAssembly()
   GetReferencedAssemblies()
   GetTypes() from each assembly, select one at random
GetMethods() from the type, select one at random

|methodRef|
methodRef := (PackageInfo named: 'MyPackage') methods atRandom.
Browser fullOnClass: methodRef actualClass selector: methodRef methodSymbol.

FWIW.

I doubt it. The goal is to bring up the source of a random method from within your editor/IDE. The reason Smalltalk wins here is that the IDE has a good model of the code available to it (which happens to be the live object memory of the program, but that wouldn't be necessary), and lots of high level convenience methods. Even if VS.NET has such a thing (does it?), I'd be surprised if it were much less than 66 lines to write a plugin that makes use of it... the culture of convenience just isn't as strong.

No, that's missing in Oz. I feel the miss, since I was used to term_expansion in Prolog (and extended DCGs, etc.). Lisp is definitely not the only game in town.

Being able to define linguistic abstractions from within the language is important. But I don't think that one should sacrifice the readability of a language on that particular altar. Can't we come up with a mechanism that has the power and elegance of macros, and use it with a syntax that is built for readability and not for being parsable with 1950s technology (sorry, Lisp, but you feel old too!)? There has been some research there, but no definitive solutions yet as far as I know.

"high level convenience methods"

"the culture of convenience"

Even without defmacro, I'd still take sexp-syntax for its structural-editing (kill-sexp, transpose-sexps, etc).

In fact, I just had an interesting thought. I prefer sexps over convention syntax, Unix shell over Gnome and KDE, Emacs over Integrated Development Environments, Gnus over Netscape Mail, LaTeX and texinfo over Word or OpenOffice, and so on. It just occured to me that the trade-off in each case is pretty similar. It buys some extra programmability, but it makes some people gag when they look at my screen :-)

(I don't use a Dvorak keyboard, though, so there's hope for me yet.)

I have not found this to be a problem in practice. And in a couple of cases I can think of that were kind of a problem, it was due to working with someone's really bad code. I've found that to be a problem in any language. Lisp macros per se did not add significantly to the problem.

Documentation, good code, tests, Meta-. and so on obviate the concern. Just as in any language and significantly complex system.