The Slate Smalltalk Blog

Michael-Lucas Smith has been dabbling in language design and prototype-basis, which is always good, since as people dive into unexplored areas, they learn more and become better informed. He updated it with some more infomration. I like various points, but want to correct various fallacies as well:

...So given that we're blue skying, one thing we can try and do is give our systems more meaning. What does that mean? Well generally, it means less data and more information.

To quibble, information is built on and higher-order than data. It's a meta-transition, and it's better for the audience if they learn this.

The Metaclass structure is one example where we get information from our system. By having it, we get tremendous reflection. Without it, we have no way of reflecting on our information and new organisation. One cry that arose out of my last post was that I was dumping classes which were really useful.

And there are other ways to have meta-object protocols than classes and meta-classes.

Okay, so instead of classes, let's say we have Prototype's. Prototype's are prototypical objects for something.. eg: a Cup. One interesting thing about Prototype's is that the "deep" hierarchies problem you get with classes doesn't exist. The structure to get to a Prototype is artificial and only meaningful when you want to see how code is inherited.

The use of prototypes does not eliminate or elide any idioms from class-based languages, including inheritance. It just removes restrictions and generalizes a bit - the object-class or object-meta relation just becomes a slot. A lot of prototype-enthused quacks think that because there are no classes, that the old patterns will/should/might be thrown out, but this is simply a fallacy, usually generated by undue enthusiasm or reaction to it.

So how do you recognise a Prototype? In Smalltalk you recognise a Class because it subclasses form.. well.. Class. I think this is a bit of a waste personally. Why force something to "subclass" just to give it a symbolic identity.

In Self and Slate, you ask an object if it isWellKnown, which checks for a conventional path from the root object which acts as a global namespace to the given one via name-oriented paths. Regardless of how "cool" prototypes are, well-known-ness is a useful property since you can think of it as something that has been published (by the definer) and subscribed to (by each user).

While I'm on the subject of symbolic identity - why is it we name instance variables? Presumeably it's so we know what they are - right? Well, interesting you should say that (even if you didn't ;>). A name is only useful to a human. Computers need something more for it to be useful - take the Metaclass hierarchy - it's complex, but not too much. It's just complex enough that a computer can use it.

Sure, and Smalltalk-80 traditionally throws out the names at run-time already. The names are for the programmers, and for identifiability per se.

So what if I say that I think instance variables are crime against programming? - Instead, we should be describing relationships and associations. When I say "children" do I mean tree nodes, literally the children of a person, or something else entirely. If it's on a Person, a human can assert that it's literally the children of a person. But that's not good enough - our machine should be able to know this too. So instead of having names, let's have relationships. I'll say that Person has children "the kind that are actual children" and a TreeNode has children "the kind that is a structure".

This is a good idea, but you have to remember that these relationships you describe still must be identifiable. This is very significant, as you can create multiple relationship descriptions which mean the same thing to a person. This sort of problem is just like using synonyms for various slot-names which mean the same thing. Synonym or equivalent phrase/formula... it amounts to the same thing on a different level. And, if you use Smalltalk object-identity for this identification, or introduce a canonicalization, it is the same thing as a Symbol only not based on the String datatype! Common Lisp's symbol design has acknowledged this for years; its symbol design is abstracted from mere byte-string tossing. So you wind up emulating the same design pattern as the original Symbol pattern on a different level - and without the integration, something is lost.

Now to go back around on myself, if I want to identify a Prototype, I relate to it from my Package that "said object" is a Prototype by having a prototype "the language concept" relationship to it.

Ah, and if a package has multiple prototypes, it will have multiple relationships labeled such. Congratulations! You have re-discovered frames, an old (and still quite useful) information-structuring concept born in the AI field! (Made by this obscure guy who goes by the name of "Marvin Minsky"! (sic)) But frames and the notion of an object in a prototype system are different concepts with different resulting philosophies, and you should be aware of that and use the label usefully.

This has a lot of implications. I can now write components that traverse known relationships. I can allow any object to have structure:children relationships and I can then make a widget that knows how to render a Tree from structure:children relationships. Now -any- object structure in the system that uses that kind of relationship can use my relationship!

Yes, and this is a nice generalization of a pattern we have been cooking up for Slate, although we have been using block parameters so far. I will keep this in mind when our syntax has been abstracted as well (this has been planned for a while, but depends on our particular UI framework working).

In fact, code browsers would be following various kinds of relationships, such as "prototype" or "package" or "method". We are now modeling information in our system. Instead of having method names and instance variables, we have relationships that end at some data or a method. On my Person I can now have genealogy:children, security:children, genealogy:parents, security:parents and they know the difference. I can now render my Person in a security editor and also render my Person in a genealogy editor!

And you can also use RDF to describe all of this in a serialized public format; I wouldn't doubt that that's your inspirations, and it's no coincidence that RDF was made by people well-informed of frame systems.

Now that we're unconstrained by the kinds of relationships we can make in the system, we can also extend the system at infinitum. If I wanted to add a comment to each method in the system, I'd simply write a comment editor which used and made metadata:comment relationships to methods in the code browser.

Ok, so you want to make a language directly oriented to dealing with RDF. What does this have to do with Smalltalk? Will you keep some of the syntax and semantics around just for sentimentality's sake (you'll have to justify it, as you'll discover)? If you don't, you have very little reason to relate a frame language design to Smalltalk.

Remember - I dumped instance variable declaration? Here's the implication - I could attach my comment editor (hell, metadata editor) to any object in any subsystem of my application.

If your language (let alone the editor) is that powerful, then generating the instance slot declaration is trivial by comparison. You abstract the syntax away, and then claim that variable declarations being inferable is an extra gain? I don't see the point here, except as a rhetorical device to obscure your actual intent and design goal, especially since the actual semantics require knowledge of where the somewhere is that some relationship's object points to.

Pretty powerful eh?

Yes, but you spend too much time off by yourself not checking out the relevant projects, and not knowing the lessons of those who have gone before.

Hello, World!

This weblog is set up to talk about the Slate programming language and environment, a Smalltalk dialect that I (Brian Rice) have been building up for a few years. The website says quite a bit and is probably a better introduction than I can squeeze into one short article, but I'll get to the various aspects over time. It's an ongoing project that has involved a lot of research, and I felt that not enough people understood the background and intentions and plans behind the system.

There are also a lot of specifics about what actually works that aren't well-known - even though the project is visible and pretty open, it takes energy to dig through things, so I thought I'd discuss some interesting things that it can do, and get that all out in the open where people can refer to it and maybe take it and improve it further.

The project works around two people, mainly: myself and Lee Salzman. I think of myself as a designer and I take care of the overall user-land experience - the libraries and conveniences. Lee complements me as the systems implementor - he knows and architects the inner workings of the system from the core semantics to the low-level gritty details that make Slate go. We are both relatively young developers, not old hands from any industry sectors, but we've taken the time to learn and read up on others' past experiences, and we've both worked on some other interesting projects that kind of led us here over time.

Slate does have some specific choices about what kind of system we want it to be, and we'll point those out or probably even have them shown to us as we use them implicitly, but there's also a broad plan that exceeds what you might infer from our publicly stated goals. The way we talk about the language publicly is very understated - we don't make big promises until we have something substantial to show for it.

Finally, we of course have opinions about software development in general, and there's a certain kind of stance we take that is reflected in the design. Some topical ones will show up, hopefully to give some idea of the implications of what we've looked at and to point out some interesting, but largely ignored, ideas in computing.