Personal info for water

This person is currently certified at Journeyer level.

Name: Brian Rice

Homepage: http://briantrice.com

Notes:

My interests are high-level programming languages, logic, mathematics, systems design, user interface architecture, and cognitive sciences.

I was first inspired by the TUNES Project website in 1995, and began a long process of research and learning that led to my current projects.

I've been working in Squeak for 6 years, ran the IRC channel for 4, teaching newbies over the years and working with people to develop patches and development plans.

I am also the co-creator of the Slate programming language, which takes some ideas I've been working on and implements them in a single system built on an extension of the ideas of Self Smalltalk and Common Lisp, with influences from other systems thrown in. It is intended as a whole environment, and has a new thoroughly-designed user interface architecture.

I have been a member of TUNES since late 1998. Recently, I took on the task of coordination of the project, and rewrote the entire web site and cleaned up much of the ambiguity and terminology.

I am also a contributor to version 2 of the Maude executable specification language which was released from SRI as Free software.

My general philosophy in programming is to unify as much as possible, and reduce the total amount of code needed to satisfy all constraints that the world needs. When in doubt, I do not code, but simplify or clean up someone else's. My involvements with the above projects are an extension of these kinds of actions.

This person is:

Recent diary entries for water:
RSS

16 Mar 2004 (updated 16 Mar 2004)  »

An update is in order for Pidgin, the C-style dialect of Slate that corresponds to Squeak's Slang. (See my post from January about it.)

Before I describe it, just take a look at some example code to get a concrete feel for it; it looks a lot like both C and Slate, without being too quirky, thankfully; the more complete examples are in the same directory from the Slate distribution as the VM sources.

First, we found that in order to get the full correspondence between accessor methods that Slate relies on and C low-level structures, we had to abandon the direct prototype mapping, and make a more explicit structured representation. So the language is a little less direct in terms of basic definitions.

The real benefit was that now we could (and did) replace almost all of the direct pointer arithmetic and unclear shifting around of values with accessors and method calls (with the overloading "flattened" with dispatched type names into C's single function namespace). Also, the ability to use type declarations to cast, and some extensions of the inference engine kept down the number of calls needed.

The general goal has been to reduce the impact in the actual Pidgin code of design decisions while still giving the C compiler as much a chance as possible to produce the same straightforward output. Additionally, clarity of the code output could mean easier use of diagnostic tools on the runtime, and possibly better chances for the C compiler to perform optimizations without having to override safety features.

A simple example of "reduced impact of design decisions" is word-size; we are noticing so far that word-size is hard-coded into very few places in the code, and may possibly be reduced to a set of generation-time macros for determining the memory layout and binary code used. Something more complex (and complete) was our ability to tease apart the VM interfaces into core object layout, heap management, garbage collection and forwarding, and finally the method and role records used to manage the operations of the interpreter and primitives, which is in turn separate.

Update: I wrote a diary entry earlier today, but it looks like this one shadows it. It's a new syntax for calling blocks;maybe someone will be interested in it.

16 Mar 2004 (updated 16 Mar 2004)  »

This month's Slate language change:

The whole value, value:, value:value:, value:value:value:, and values: protocol for explicitly invoking blocks on arguments has irked me for sometime, and I found a solution recently, prompted by some issues we were having with some of the selectors, notable value and value:, being of the same name and not polymorphic with various slot setters/getters, and some pseudo-accessors of other objects. So we looked for an alternative, and made a parallel.

To explain, currently in Slate, selectors can be sent with sendTo: for an argument array, or sendWith:[with:[with:]] to pass the arguments without aggregating an array. So, we pulled the old "eval/apply" type of protocol separation and created applyTo:, applyWith:[with:[with:]] to directly take a block or method and call it (without lookup) on the given arguments. Voila! A clean protocol that conceptually make sense and has "phrase value", as I like to call it.

The remaining issue was with value itself, which has lost its "kin", but we can't say we're applying it the way you apply a method you've looked up from a message-send, so we looked for another family of selectors to group it with. We threw around a few ideas, but do seemed to make the most sense, much as do: commonly means the same thing, but with one argument instead of none. So I think this'll work, barring huge protests or better suggestions from others, and in any case, Slate has "Smalltalk compatibility mode" and an inlining compiler if people want the old style for transition or habit without loss of performance.

Anyway, I thought I'd share. I'll watch in case someone has comments, or you can email me or a mailing list I'm on (Slate or Squeak).

10 Jan 2004 (updated 10 Jan 2004)  »

I've been working on a successor to Slang, which I've been calling "Pidgin", for some time now for Slate. There are a lot of issues involved.

Anyway, some of the ideas could translate back to Squeak pretty easily. Mostly, the idea of developing a CProgram (or TProgram?) object which the translator decorates directly, and refactoring according to that is a big deal. Also, making a notation to translate certain classes (prototypes in Slate) into a C pointer type so that casts can be performed and functions documented a little more clearly seems to be helping. Mostly I develop accessors as pidgin functions on the class which get translated to C functions which take a pointer to something of that type, making it "type-safe" (Ack. I find that a hard word to use about C) for the target program, and inlineable. What helps about that is that I can separate format-specific details from ObjectMemory. In a related note, I'm also interested in separating the Interpreter as a structure from the heap, allowing for some multi-threading possibilities, but this needs looking into before taking advantage of it.

Also I've been automating the inline annotations based on the size of the expression tree times the number of calls made to it. This makes the second pass a little more intensive but avoids the details of messing with the self inline: aBoolean manual overhead.

I wrote up my plans, guide, and such in this email to the Slate mailing list recently. Maybe this will inspire someone to offer suggestions or backport the relevant ideas. Any takers?

15 Nov 2003 (updated 15 Nov 2003)  »

So, Andreas Raab plays around with the language a bit. I'm glad someone else does; without this kind of exploration in a few directions, it's hard to weigh the merits of any one of them.

Anyway, it's interesting what features he brings up, since I've been thinking about the same thing for Slate. For optionals, we use "optional keywords", basically keywords with & in front, like Set new &capacity: 40 would return a new Set sized for 40 elements. It's pretty simple, but of course it raises the effective precedence to a keyword send for the core-message plus optionals.

He also mentions variable/positional arguments. I'm not sure what value this has over valueWithArguments: (values: in Slate), but then I'm also used to my methods being blocks themselves where you get that for free. Anyway, there's an idea we've been tossing around to use the Slate ability to have an "empty keyword" (: on its own), and using repetition to get the variable position-style arguments in, again the code receiving it in an Array. Say, if I wanted this to work for blocks, i would define m@(Method traits) value:: values and then call [| :a :b :c | 3 + 4] value: 1 : 2 : 3. It's not a huge win over explicit literal arrays, but it does fit in with the main Smalltalk syntax idea, and it's not ambiguous, although the empty keywords need spaces around them to be unambiguous.

I guess I should just say that I think the Smalltalk core syntax has a value on its own (when used correctly, trying to express a phrase), and parentheses should just be for disambiguation rather than function-call syntax, which is pretty idiosynchratic, really.

And, oh yeah, I do have misgivings over value: and value:value: and so forth. I mean, why not move to applyTo: and applyToAll:? It has the "phrase value" that I prefer. Any opinions, at least for Slate?

This person has certified others as follows:

Others have certified this person as follows:

[ Certification disabled because you're not logged in. ]

[ Home | Articles | Login/Account | People | Projects ]