Smalltalk Program Model for Interchange

Update after Camp Smalltalk 2000 San Diego

• The group working on this project is now called the PPR group (for Portable Program Representation).
• You can subscribe to the PPR mailing list by sending a message with subscribe smalltalk-ppr yourName@yourDomain to Majordomo@mojowire.com. It is a closed list so I will need to approve you first.
• We achieved our goals of a) extracting a simple program present in a development image into a PPR, b) installing a program from a PPR into a development image, c) transporting a program to another dialect using its PPR and installing it there. We started with VA and ported to VSE.
• Join the PPR mailing list to find out which direction(s) we are going to explore.
• The project page is now at Portable Program Representation.Peter van Rooijen

Signup/Members:

• Giorgio Ferraris
• Your name here

Goal

Enabling interchange of arbitrary Smalltalk software between dialects.

Approach

• Start with enabling interchange of simple types of components (say Class with minimal constituent elements), then gradually building our way up to more complex ones (say Full Class, Package, Library, System).
• Reuse as much as we can from the Refactoring Browser program model and implementation to help enable portability of the RB in the process.

Things we will need to create

• We will start from things that already exist, and particularly try to reuse and extend the program model that the Refactoring Browser (version 3.5.1) uses.
• It looks like Les Tyrrell's Oasis also has a code-model we can steal from.

• An issue that arises here is that we would presumably like to create a program representation that consists of objects which can be interchanged using an arbitrary object interchange mechanism (using binary, XML, or whatever). As my expertise here is quite limited, I do not know exactly what properties the objects need to have to be interchangeable in such a way. My guess is that if they are state-only objects, we will be OK, but I'd like to get some (dis)confirmation of that.
• We will try to reuse here in the same way as proposed under 1).

• Ralph has told me the RB can already do a lot of that Peter van Rooijen.

• Ralph has told me the RB can already do a lot of that Peter van Rooijen.

6) A binding of the abovementioned to several object interchange mechanisms (being produced at the Camp), such as binary and XML.

7) ...

Comment:

• How is 1 different from 2?
• 5 is basically just doing 3 and 4. Ralph Johnson End comment

• 1 is the design, 2 the implementation
• 3 and 4 are for 1 dialect, 5 for multiple Peter van Rooijen End response

Things we will need to find out

1) What constraints are placed upon the SPM objects to make them interchangeable using the results from the object interchange efforts.

2) What the available stuff for potential reuse can already do.

• I'm planning to study the architecture and capabilities of the RB Peter van Rooijen.

3) Issues we are likely to run into concerning the incompatibilities between the different (source and target) Smalltalk languages and environments.

4) ...

Things we will need to decide

1) Which dialect(s) we will start with.

• My familiarity is primarily with VA Peter van Rooijen.

If you start with the RB program model then you want to start with VA and VW because it already runs on them. After that, it all depends on who you have who can help you port. It will be 5 times easier to port to a dialect if you have somebody who knows that dialect. Note that porting to a dialect will often require an expansion of the program model. For example, I've been told that MT lets you assign a COM class ID to a Smalltalk class. Unless you port to MT, there is no need to include this in the program model. So, each port raises the possibility of adding something to the model. Ralph Johnson

3) Our timetable.

I'm not on the team, so I don't have a vote. However, it seems to me that the sequence of events will be to make a program model that can translate programs between VA and VW and then to keep adding dialects. You probably ought to make some test programs and to move them around between dialects and make sure that they work. The number of dialects you can handle depends on the number of people who are working. I predict that two people working together can port the program model to a dialect in one day if one of them knows the dialect well, and the other one knows the program model well. It will take a day or two to get the original program model in place. Ralph Johnson

4) Division of labor.

Worry about each morning based on what you are going to do that day. It will depend on who you can get to work with you on a particular dialect. Ralph Johnson

5) ...

Simplifications we could make in earlier iterations

1) Minimal Class has Object superclass, only has methods, which only have portable source Peter van Rooijen.

This is simpler than the RB program model, so I don't think it is necessary. Ralph Johnson

2) Source body is first encoded as one item, only split up in code nodes later Peter van Rooijen.

It is good to separate the selector from the rest of the method. You'll probably figure out other things along the way. I agree that you should split up later. Ralph Johnson 3) ...

Richard A. Harmon harmonra@webname.com

In regards to:

1) A reference Smalltalk Program Model.

my implementation of SIF contains a fairly robust Smalltalk Program Model.

I have been told it is somewhat similar to VSE Packages (I think).

It has program components with prerequisites that contain program elements (class def. or method def.), or grouping elements (all of the elements of a class, or any arbitrary grouping) that contain program elements or grouping elements (may be nested).

It sounds to me like what you are looking for in 1.

I haven't used the RB, but I had vague thoughts that it would make sense for my SIF implementation to eventually use RB facilities it needs.

My code is butt ugly (especially the code formatting) but may already have a great great deal of what you want. I'm told that it is a fairly good approach. It's free, implemented, and portable.

I think it would take very little work for it to use "Eric Arseneau" less complex SIF implementation. This may already be in progress. He has ported it to a number of platforms including Dolphin, Squeak, and VW.