Dan Ingalls wrote:

What I'd like to do is to propose an operational approach which may

***********

help to guide us to getting the "best of both worlds" -- in this case a simple small kernel, but that can support a great group programming engine for large software projects.

[snip]

Basic Modules:

1. A minimal kernel
2. Basic Graphics
3. Full Files
4. Development system kernel

5a. MVC kernel 5b. Morphic kernel 6a. MVC development system 6b. Morphic development system

7.. Rest

Perhaps one could exchange 4 and 5a/b.

I like this approach!!

Hannes Hirzel

--On Saturday, August 18, 2001 9:27 PM -0400 Marcio Marchini mqm@magma.ca wrote:

...

1. A minimal kernel

This would be something like the 240k "tiny" image I made from Squeak a few years ago (had compiler, files, minimal graphics (only enough to put up a transcript), collections, strings and numbers). I would like to go farther with this by using the OS for the transcript, so that all this thing can really do is read in the next package.

If you have a mini web server (headless) running in Squeak, I'd say the

Smalltalk compiler and the Transcript support aren't really needed.

Perhaps, but should we really optimize for the absolute minimal case?

You're not compiling new code, and you can log messages to stdout or a file. So, I'd say they do not belong to a minimal kernel.

Well, I disagree at *least* as far as the compiler. Dan *did* say "I would like to go farther with this by using the OS for the transcript, so that all this thing can really do is read in the next package."

Two points: yes on the "Transcript to stdout or file" but also this is a kernal minimal enough for bootstrapping (i.e., reading in the next package).

As I said before, I like the list from PocketSmalltalk:

http://www.pocketsmalltalk.com/whitepaper.html#builtins

Which has stuff one could remove. Minimality isn't the only goal, IMHO.

The next level up would be the above with compiler support, so that you

could maybe use this as a TTY scripting language. Still no GUI, just stdout.

Then on top of that GUI, etc.

I heartily agree that *whatever* we have, it should run well headless.

That means that it should run well *without* a gui per se, but that doesn't mean that it needs to *not* include the GUI support. After all, you might want to switch headlessness on or off.

Given how *tweensy* minimal compiler/gui support is (a few ks of bytecode) I'm not sure I see the advantage of leaving it out, especially first round.

Cheers, Bijan Parsia.

--On Sunday, August 19, 2001 9:50 AM -0700 Allen Wirfs-Brock Allen_Wirfs-Brock@Instantiations.com wrote:

At 12:39 PM 8/19/2001 -0400, Bijan Parsia wrote:

...

--On Saturday, August 18, 2001 9:27 PM -0400 Marcio Marchini mqm@magma.ca wrote: ...

...

    If you have a mini web server (headless) running in Squeak, I'd

say the Smalltalk compiler and the Transcript support aren't really needed.

Perhaps, but should we really optimize for the absolute minimal case?

We shouldn't be optimizing for the minimal cause; however, we should be enabling the minimal case.

Yes.

...

...

You're not compiling new code, and you can log messages to stdout or a file. So, I'd say they do not belong to a minimal kernel.

Well, I disagree at *least* as far as the compiler. Dan *did* say "I would like to go farther with this by using the OS for the transcript, so that all this thing can really do is read in the next package."

Two points: yes on the "Transcript to stdout or file" but also this is a kernal minimal enough for bootstrapping (i.e., reading in the next package).

This is where it's important to make the distinction between "components" and "modules". When thinking about modules, you don't have to worry about bootrstrapping.

Aha, yes, ok.

Modules get externally assembled. If you have a set of proto-kernel modules with orthogonal functionality you can assemble them into a variety of actual kernels that support different usages. Some of those kernels wound support dynamic component binding (hence booting strapping) while others might only support complete, self-contained applications.

Ok, this all sounds good.

From the point of view of initially chunking the system, I suspect Dan's

minimal kernal is still the *right* kernal or close to it. I.e., from there you can build up (to what we have now) or pare down (to the microkernal).

Cheers, Bijan Parsia.

Allen wrote:

Another optional layer would added the reflection protocols needed to support dynamic addition of classes and methods. Note that images without this layer must be statically generated by some sort of image writer (something like a SystemTracer). From what I've heard about the ModSqueak work it sounds like it is close to provided the necessary infra structure to do this.

I was thinking of doing something similar with Oasis- I would need to learn how to construct images from scratch, but I can already load, test, and modify Squeak code within an Oasis "Component".

Could someone point me to a nice, accurate, concise description of what an image file needs to be?

- les

Les,

...

I have a message pending (I just need to type it) on why ChangeSets may not be the answer.

It's sort of how I started out with Oasis... I just wanted a place to dump code where I could look at it without it causing trouble for my image.

[...]

What I found as I built Oasis was that there were very deep-seated non-modularities permeating everything. It's not just the tools, or even the code, but perhaps even more significantly, the attitude. Everything *knows* that there is only one namespace.

To what extent is this related to change sets?! I've seen more than a few apps that were shipped in the form of change sets and a number of them does have multiple CS to prevent the kind of problems you're mentioning. So it seems to me that what you're saying is that the equation module/component == 1 change set is not right - but I don't see anything in your post that would render the use of change sets generally questionable.

Cheers, - Andreas

There are essentially two approaches (both of which are useful and educational) to the problem of building smaller modular images.

1. Start with the Image and Toss - The most popular has been to use a tool such as Stripper of Packager as we called it to remove classes, methods, instvars, globals and instances from the image. Packager also allowed renaming of symbols to smallints as does Pocket SmallTalk I believe. This approach avoids some of the initialization problem because it always starts from an initialized image. The problem is that it requires a lot of image and package knowledge expertise to perform the work and often developers unintentionally make it challenging to untangle an image so that it can be shrunk.

2. Start with an empty Image and Add - the approach hear is to build up a set of modular images from a set of carefully selected classes. The problem of course with this approach is that it means that all interdependencies need to be fixed in the existing classes. Often people give up and decide to write their own new class libs as in Pocket SmallTalk. The risk here is that once you decide to build an image you often own it for a lot longer than you intended. <grin>

3. A compromise approach is to start with an image containing the initialized classes even if it is a cycle the they add in the classes carefully to build up the image. This finesses the hard problem of getting all classes to initialize themselves properly in some correct order. It also allows one to use the familiar classes even if the lack the modularity and independence that one might ideally like.

It would be really useful to have an Image Analysis and Planning Tool which allowed one to understand the interdependencies between classes/methods and globals. Ideally one would be able to plan a reorganize of the image without actually doing it in place. Being able to see the impact of many changes before making them would reduce the image FUD which one faces when trying to decide if you really dare make those sweeping changes that you think are either trivial or impossible. Hopefully the work by Stephan et al may come to play in such a tool. Our experience with running the Packager is that the more often people ran it the more they learned about problems in their image and the more concerned they became about writing more modular code.

Regards, Dave

Dan Ingalls wrote:

I agree it is essential to be able to do this kind of refactoring of the module structure again and again. When I did the Environments work, I took some time to refactor the systemOrganization somewhat, as this is what I used as the basis for the module structure produced by reorganizeEverything.

It ain't a tool, but the essence of a tool can be found in

Smalltalk tallyIndirectRefs

However, before I leave town, I will try to have this stuff working again to the point that the image can be refactored and stay running. Then while I'm away, people can have fun messing around with the structures and the factoring. It should be instructive whether or not we end up using any of it.

• Dan

--

Dan, this is already working (still) in 3.1a. I've been using it when I looked at the Environments stuff.

There is one fix that you would want however after converting to Environments, make this change to avoid an image crash when an exception is raised:

Dictionary>>includesKey: key "Answer whether the receiver has a key equal to the argument, key."

^(self at: key ifAbsent: [nil]) notNil

I posted this as a fix.

Do exploreIt on "Smalltalk tallyIndirectRefs" for best results.

The third returned dictionary is the most interesting one imo. The others mostly say that 700 classes would be happier if they were placed in Smalltalk (doh).

It lists non-modular refs by occurrence count. This shows that most go to things like the basic collections, note that Tools, Morphic et al are references to other namespaces. Hopefully most Color refs are from the graphics packages, which should be ok, and so on. But there is a lot of work cut out for us.

Henrik

269->#Array 254->#Color 168->#OrderedCollection 135->#String 111->#Tools 110->#Smalltalk 106->#Form 95->#Morphic 95->#Time 95->#Dictionary 88->#WriteStream 82->#Display 77->#Character 70->#Sensor 64->#Preferences 57->#Cursor 52->#Transcript 52->#FileDirectory 52->#FileStream 47->#ReadStream

etc.

I appreciate the need for initialization. Let's make it simpler than Java/ANSI Smalltalk by requiring a module to be a persistent immutable object. We should not care how an object came to be in a particular state, only that we can make a mutable copy of that state.

When you look at it this way, initialization code is just one way to create a copy of a particular object state and should not be fundamental to our definition of modules.

-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Allen Wirfs-Brock Sent: Monday, August 20, 2001 11:05 PM To: squeak-dev@lists.squeakfoundation.org Cc: modsqueak@bluefish.se Subject: Re: [modules] {Image Shrink and Initialization}

Dave's experience with initialization pretty much matches mine although I have tended to prefer the constructive approach.

I think part of the problem people have had adapting to additive modules is that many existing classes libraries haven't been designed with initialization or re-initialization in mind. In many cases Classes (or probably more importantly mutually dependent sets of classes) that needed complex initialization have often been initialized with ad hoc doIts that aren't captured as reusable code. Even, if the initialization code is placed in a change set or file-in as a do-it it tends to get forgotten because it doesn't show in the browser when looking at the class.

I think to make additive modules work reliably and repeatedly you need the following support for initialization:

1. Initialization code needs to be treated as first class code entities by

the language and tools. Team/V did this and this is the reason that the ANSI Smalltalk language definition includes class and global variable initializers as language elements.

[remainder snipped]

2. Initialization order needs to be well defined and repeatable. Team/V

and ANSI Smalltalk both claim this but only if a programmer completely specifies the initialization order in some inconvenient way. This is one area where I think Java has done a better job. The Java rule could be loosely stated this way: a class is automatically initialized the first time an executing method references the class by name. I think the Squeak vm (or alternatively compiler) could be pretty easily adapted to support this semantics. If anyone wants to try let me know and I'll try to provide a more complete "specification".

A bit of warning: the Java initialization is not that simple, because you need to detect cycles and also work despite concurrency. The Java spec has the steps necessary, and having implemented it myself I can say it is not that trivial, but once implemented you don't need to get back to it. But some people still don't quite understand how the initialization works, getting lost in the different initialization exceptions that can be triggered.

marcio

Dave wrote:

It would be really useful to have an Image Analysis and Planning Tool which allowed one to understand the interdependencies between classes/methods and globals. Ideally one would be able to plan a reorganize of the image without actually doing it in place. Being able to see the impact of many changes before making them would reduce the image FUD which one faces when trying to decide if you really dare make those sweeping changes that you think are either trivial or impossible. Hopefully the work by Stephan et al may come to play in such a tool. Our experience with running the Packager is that the more often people ran it the more they learned about problems in their image and the more concerned they became about writing more modular code.

Five years ago I thought this would be pretty important... so that is actually what I've spent most of my time building in Oasis. I don't recall if I've described some of those before, but basically they are as follows... throughout the last few years I've routinely used these models to analyze entire image's worth of class libraries... and in Oasis, I can indeed do this while such code is nicely tucked away in its own environment.

Referencing Model - a very coarse-grained analysis which tells me which classes refer to which globals. Very simple, easy, and fast to compute. Those of you who are looking at schemes such as partitioning along class category lines to find out what cross-references exist are doing something similar to this.

Expectations Model - a much finer-grained model, this model can be used in lots of ways, though I've been focusing on a much harder analytical problem ( below ). "Expectations" refers to the notion that in Smalltalk we do not have types, rather we have expectations- all we know is that we "expect" to be able to send a message to a particular object, that this message send will answer some object, and perhaps we have further expectations on what messages we can send to that result. This model gathers information about where messages are being sent, and to whom, throughout a given chunk of code. From it, you can learn many things. I think that this is similar to what CodeCrawler provides.

Shard Model - Smalltalk does not have Interfaces as first class objects. But there are cases where one would like very much to be able to rapidly peer deep inside a large mass of code to find out what messages are being sent back and forth to the objects acting in the various roles in that code. The belief is that while Smalltalk does not have Interfaces, nonetheless they actually do exist, although implicitly, rather than explicitly. Shards are the fragmentary evidence that Interfaces exist.

( skipping some steps )

Facet Model - A Facet is what Java would call an Interface. That is, a Facet is a particular piece of the total Interface of an object. If you really believe that the Interfaces exist, then there ought to be a way to extract them from their implicit existence. This may or may not still be a hard problem. It has most definitely been an extremely difficult one up to this point... but perhaps that is no longer the case. The evidence from the Shard model has been overwhelmingly in favor that the Facets do exist... but getting that last step out of the way has been very difficult. This is where I've actually spent the vast majority of my time on Oasis- the problem has strong appeal, the evidence from the Shard model is very supportive, but until recently none of the algorithms I've tried to complete this process worked. I now have one that is looking much more promising, so at last I have the chance to explore this on its merits, rather than on perceptions. I am very hopeful, not just to have completion on this particular problem, but so that it will cease to devour what little time I have to work on Oasis, so that I can finally turn my attention to some other issues and get Oasis into a shareable state.

- les

I've been looking at that. The analytical tools are somewhat independent- Referencing is not very involved, but Expectations needs to walk parse trees ( other than that should be easily ported ). Beyond that, the ony requirement of the more advanced models is that the Expectations model exist.

The major thing is getting them into intelligeable shape... Referencing and Expectations are pretty good, but static models ( I haven't had the use case need for models that would be dynamic- but if Expectations were dynamic, then it could do tree-shaking algorithms for image stripping, for instance ). The Shard model is littered with the debris of many failed attempts to get at Facets... and the Facet model is brand new. In between them lies the Aliasing model, which *hopefully* is primarily an accellerator. It seem to work well, but again is a static model, as are the Shard and Facet models.

Henrik Gedenryd wrote:

Les Tyrrell wrote:

...

I've routinely used these models to analyze entire image's worth of class libraries...

<snip increasingly advanced stuff>

Les,

this could certainly be useful for us here in Squeakville in the future. How hard would it be to port them? Some of them? The easy ones? ;-)

I am guessing it might be easier than most of Oasis, since this has more of clever algorithms to it than APIs, so to speak.

Henrik

----- Original Message ----- From: "Les Tyrrell" tyrrell@iserve11.lis.uiuc.edu To: squeak-dev@lists.squeakfoundation.org; "Dan Ingalls" Dan@SqueakLand.org Cc: modsqueak@bluefish.se Sent: Sunday, August 19, 2001 5:07 PM Subject: Re: [modules] What should be the first step?

...

I have a message pending (I just need to type it) on why ChangeSets may not be the answer.

It's sort of how I started out with Oasis... I just wanted a place to dump code where I could look at it without it causing trouble for my image. Later on I made that into a place where I could compile the code, instantiate objects, and interact with them, without clobbering my image. Which sounds very straightforward- but nothing that I did in Oasis was easy to accomplish.

What I found as I built Oasis was that there were very deep-seated non-modularities permeating everything. It's not just the tools, or even the code, but perhaps even more significantly, the attitude. Everything *knows* that there is only one namespace. That was true, of course, an entirely reasonable assumption at the time. But that means that there are much bigger mountains to move ( forget about getting to do something as easy as climbing them ) than you may be thinking. To give an example- In Oasis, I can load the entire class library for VisualWorks into a single module. There you have all the code in one module, just like it wanted to be. But... you can't use it, because you can't initialize this class library- over 200 classes need to be initialized, but the code to do it trips over itself... if I remember correctly, it went something like this: can't initialize Object, because Collections are initialized... can't do Collections, because something else isn't ready... Symbol and String are cyclicly dependent on each other, neither can proceed... The issues go deeper than just having some mechanisms like namespaces. "Just add namespaces" will not solve these problems.

As a counter-example, I *can* load a modified version of PocketSmalltalk's class library into a module, and I *can* instantiate and interact with objects defined by PocketST's classes. The reason is simple- I *can* initialize PocketSt's class library, because it was designed to be brought up from scratch. So, this is the route I would pursue, given that I already have Oasis- construct a class library similar to PocketSt's, but using Squeak's code ( I'd just use PocketSt's, but I don't believe it is open-source, though I could easily be wrong about that ).

All the PocketSt work is under an open-source license similar to the Apache license.

                          The benefit of such an approach is that I have a very clear picture of just what I have

in the module, and whether it works. The hurdles I would have to overcome are that I would have to be able to generate Squeak's bytecodes, ( meaning that I might have to either port Squeak's parser and compiler to VisualWorks, since that is where Oasis lives these days, or run them on top of PocketSt inside Oasis, which I've explored a bit in the past ), and I would have to know how to generate a new Squeak image from scratch. Both of these things are justifiable extensions to the existing Oasis capabilities, as far as I'm concerned, so I'd be willing to give it a try if someone will tell me what I need to know about the image formats, and what the VM expects.

• les

I noticed that when the "help bubble" contains longer text, the text tends to stick out of the bubble in upper right and lower right corners. Also, there seems to be too much space on the left of the text. See the attached GIF. I am using the image with latest (yesterday's) updates.

I don't own a copy of Everquest so I'm not 100% sure, but I'd bet that when you carefully read through the EverQuest license agreement, you'll find out that the thing you propose is quite illegal. I'm very sure that "Ultima Online" agreement specifically says that if you play it using anything else than the official client, your account can be immediately terminated without any compensation.

Lawson English wrote:

It is so cool that I think it could be the "killer" app for Squeak if a limited client/server Squeak implementation could be devised and made part of the default image or at least available as a standard module.

EverQuest is a first-person-shooter graphical MUD with upwards of 1,000 players online simultaneously. The interactions are overwhelmingly complex and quite fun.

At 05:09 19.08.01 -0700, Lawson English wrote:

For my son's birthday I bought him a 6-month subscription to the EverQuest online adventure game. If you haven't played it, then I suggest that you obtain a copy and try it

Sounds like the father who buys his newborn child an electric model train :-)

I never played EverQuest or Ultima Online or any other graphical MUD, but I know the old MUDs, am an enthusiastic fantasy role player, and can therefore perhaps imaging that this kind of game as a high coolness factor.

Actually, I'm playing with the idea to create such kind of game (perhaps with a much smaller scale) on my own for a long time now some of my friends would love the idea to flesh out and build a fantasy world and/or play such a game, but they lack the skill to program such a system.

If you were suggesting to create a EverQuest client in Squeak, that would be illegal, I think, but if you think about creating a whole client/server system, let's continue to talk about that :-)

I admit, for various reasons I thought about writing such an environment in Java, actually, writing a Self-like language in Java which then would be the language to code the world in. But Squeak might be an alternative, at least for a prototype.

In addition to the "wow" factor of letting every kid host his/her own baby graphical MUD, a Squeak-based implementation would allow all sorts of collaboration between researchers, teachers, students, etc. Sorta a graphical realtime Swiki.

Sure, gaming is just one aspect of such a virtual universe.

Perhaps, this will also fit somewhere in the strategy of Squeakland? I don't know.

bye -- Stefan Matthias Aust \ Truth Until Paradox

on 8/19/01 1:00 PM, Kevin Fisher at kgf@golden.net wrote:

There is a project that aims to create a free Ultima Online/Everquest-like server called World Forge (www.worldforge.org).

They have a number of clients written in a variety of languages...I think the "goal" is to have a server that can have it's world rendered isometric (UO style) or 3D (Everquest-style). It might be an interesting project to create a client in Squeak...the spec is totally open, unlike UO and EQ.

Thanks for the pointer. It would be interesting to see if a Squeak-based version of World Forge *server* could be made. Making such a beast work AND making it work fast enough for a commercial-quality game would tax the design philosophy of Squeak, Modular Squeak and the native code interface, I think...

On Mon, Aug 20, 2001 at 10:19:37AM +0200, Stefan Matthias Aust wrote:

At 16:00 19.08.01 -0400, Kevin Fisher wrote:

...

There is a project that aims to create a free Ultima Online/Everquest-like server called World Forge (www.worldforge.org).

I just browsed though the provided documentation. The screen shots look great and it's interesting that there ATLAS protocol is a classless SELF-like object system but I couldn't find enough details to guess the current project state and/or the features.

Most of the real discussion goes on in their newsgroups...I occasionally stick my head in there to see how the project is progressing.

They seem to move in experimental stages, releasing specialized test servers to test some new concept or another. I think they just finished with a test server that had a small "economy" experiment where you would play the role of a pig farmer. :)

IMHO, the real work isn't setting up a client/server protocol but to come up with a flexible world object model, interesting, easy to learn rules which still allow great flexibility and finally with a rich game world that doesn't become boring after a few hours.

MUD - to answer the other email - is a Multi User Dungeon (often also Dimension). Something like a text adventure combined with a chat program which can be played by multiple players simultaneous. One unique feature of MUDs is that players can help to create, extend and flesh out the world buy using a simple (unfortunately often C-like) in-game language.

...

They have a number of clients written in a variety of languages...

Well, it looks like "variety" means C or C++ :-)

Oh? I thought I saw a Python client there at one time...the clients seem to live and die by the season though, so it could have been abandoned for something else. :) The "stock" client they do their tests on is an isometric engine..I haven't tried the 3D clients.

...

I think the "goal" is to have a server that can have it's world rendered isometric (UO style) or 3D (Everquest-style).

...or even textual like in nethack.

Well, you can always use the AAlib if you want ascii graphics. I still remember that demo of Quake using AAlib...fragging in ASCII is..um..unique. :)

...

It might be an interesting project to create a client in Squeak...

But it look like to get at least some documentation, one has to read the source and extract the information. That's IMHO a large barrier to start...

You may want to check their newsserver for documentation information. I know at one time they did have the protocol written down..perhaps the web site has fallen behind?

At 10:18 20.08.2001 -0400, you wrote:

Stefan, did you see my post about http://spair.swiki.net/21 ?

No, not yet. I just came back to the Squeak list last weekend.

However, did you see my effort, porting the original SELF system to VisualWorks? --> http://www.3plus4.de/self/

I hope that someone might take the initiative and use it to create a complete Self implementation in Squeak.

Sounds interesting. I'll have a look at it.

bye -- Stefan Matthias Aust // Truth Until Paradox

At 14:00 20.08.2001 -0400, Stephen Pair wrote:

...

However, did you see my effort, porting the original SELF system to VisualWorks? --> http://www.3plus4.de/self/

No, that's the first I've seen of it. It's interesting that you took the approach of trying to load the Self snapshot file. I hadn't thought of that.

Well, originally I only wanted to test whether my parser works but then I wondered, how many primitives do I need to bootstrap the thing. After a few hours of work I noticed, a lot of. Most of them are crude hacks but I eventually managed to read in most non-UI files.

I think the first step would be to get a Self compiler working in Squeak.

That would be easy. I've a working scanner/parser/compiler.

Also, how do you like the Self syntax overall?

In the last squeak, I changed my mind an nowadays, Self has not enough syntax for my taste. You really have to get used to all that (| .. |) object declarations ( ) method declarations, implicit self sends and the fact that even local variables doesn't exist. I really the clean concept, but using "name := 'sma'" instead of "name: 'sma'" or even "objects[1] := objects[2]" instead of "objects at: 1 Put: objects at: 2" would be more readable IMHO.

Another thing that I thought would be interesting is running Python in Squeak (interesting to see how well it could perform that is).

Well, look at http://www.3plus4.de/squeak (bottom of the page) for my start for the parser. A abandoned that project because Ruby is so much cooler than Python.

bye

-- Stefan Matthias Aust // Truth Until Paradox

Henrik Gedenryd wrot:

Stefan Matthias Aust wrote:

...

In the last squeak, I changed my mind an nowadays, Self has

not enough

...

syntax for my taste. You really have to get used to all

that (| .. |)

...

object declarations ( ) method declarations, implicit self

sends and

...

the fact that even local variables doesn't exist.

I'd like to hear your opinion: do you think it is an advantage to allow receiver self to be implicit? I have started to think that this breaks the simple principle of always having the "receiver message" pattern and thereby causes more irregularity than advantages. But I'd like to hear others' opinion on this, I don't have a strong opinion yet. Jecel and John Maloney might have something wise to say about this as well?

I have questions about the notion of name resolution being tied in with message lookup. My gut tells me that these shouldn't be so intertwined. If you really want name resolution via a message send, then do "self orderedCollection" otherwise just use "OrderedCollection" and allow the compiler to resolve it. You could take it a step further and have the compiler ask the mirror to resolve the name (in which case, you can resolve names however you want)...this is analagous to the current implementation where the compiler looks to the class for help in resolving names.

Therefore, if you want to have flexibility in name resolution, dropping the "self" keyword would make that a challenge.

Regarding delegation in Squeak and compiling methods, there are really three issues to resolve:

- a syntax for a directed resend (the current super syntax will accomplish an undirected resend). I had thought about using a * following the variable name (i.e. "parent* doSomething"))...I don't particularly care for the Self syntax here, however it does allow for other types of messaging (i.e. "anObject async.doSomething). I think the Self syntax is "parent resend.doSomething".

- Allowing for overriding of slot getters and setters: For this, I was thinking that the using the normal Smalltalk instVar access and assignment operators would be fine (the compiler would turn these into bytecodes appropriate for prototypes). In this way, you could also do direct instvar access in other methods (but obviously this impacts the re-usability).

- Saving of method source: I thought a simple solution to this would be to have the ProtoBehavior hold onto the source strings, and allow one to instruct it to not to keep method source if that isn't desired. (it would also be a simple matter to write something that could install a constructor on an existing method in the class system). On the other hand, we could go for something more advanced that would allow source to be written into the changes file, we could accomplish that by allowing prototypes to be owned by some existing class, given a name, and kept in some dictionary off the class. OTOH if we had a nice virtual object memory system, we wouldn't need a source or changes file in the first place, and storing source in the virtual image wouldn't be an issue. ;)

- Stephen

Thanks Jecel,

these are all very informative comments. I don't want to start a flame war and I know you like Self (ok, an understatement perhaps), but neither of the three issues is an uncontestably perfect solution.

Jecel Assumpcao Jr wrote:

But having used the "implicit self" trick in NeoLogo as well as Self and variations, I can say it is much more readable than what you might think from a first impression. It does make a missing statement separator (".") harder to spot since it becomes a run time error instead of being flagged by the compiler as in Smalltalk.

It seems this would mean that you cannot simply read the code to see that it is syntactically correct either (since its correctness is not a static property). Unless you take clues from line breaks and such. But in all fairness some ST syntax mistakes slip through the compiler in much the same way.

...

It is wacky that you also address temps with the "temp: value" syntax. In effect 'self' is the inner context (cf. thisContext), not the object owning the method!

Exactly. If you write "self temp: value" it will work for "instance variables" but fail for "temporaries".

But this is unfortunately still inconsistent, the implicit receiver is sometimes self, sometimes "thisContext".

Since the context is seen as an extension of the object (the context has the object in a parent* slot), I thought the simple solution would be to simply consider (the implicit) self to be this "extended" version of the receiver object.

...

A second effect of not having := is that there must be a lot more parentheses in the code. Ie.

x := y blah: z becomes x: (y blah: z)

This is a second thing I've come to think of as a possible disadvantage.

Self has two things that combine to make it need less parentheses than Smalltalk: all but the first keyword of a selector are capitalized and keywords parse from right to left. So the above expression would be

x: y blah: z

and Smalltalk's

x := y between: 0 and: (z min: 255)

would become

x: y between: 0 And: z min: 255

Whoa. Less parentheses yes. More readable? Hmm. Also, making the parsing be sensitive to the capitalization of selector substrings is an "unorthodox" approach to say the least. And parens help the eyes to segment things.

Another problem with the automatic accessors instead of assignment is that you can't protect state from outside access and modification (unless you add other mechanisms for hiding methods from the outside). There was some feature of that kind in early versions IIRC?

In all, weighing the pros and cons of the syntax changes doesn't as obviously come out in Self's favor as one first thinks. But of course it is in the skill of an author to present any feature to its best advantage, letting the downsides slip in the editing process ;)

Henrik

I suspect that implicit self probably makes Self code more difficult for beginners to read for exactly the reason you state: it doesn't follow the "receiver message" pattern. However, I must add that:

1. I haven't taught Self to anyone who didn't already know Smalltalk, so I have no evidence one way or the other, and 2. The expert Self programmer quckly becomes used to implicit self.

I'll also add that I find Smalltalk code a little more pleasant to read. I like look of assignment arrows. That, of course, is purely a matter of personal opinion and aesthetics.

-- John

At 11:14 PM +0200 8/22/01, Henrik Gedenryd wrote:

Stefan Matthias Aust wrote:

...

In the last squeak, I changed my mind an nowadays, Self has not enough syntax for my taste. You really have to get used to all that (| .. |) object declarations ( ) method declarations, implicit self sends and the fact that even local variables doesn't exist.

I'd like to hear your opinion: do you think it is an advantage to allow receiver self to be implicit? I have started to think that this breaks the simple principle of always having the "receiver message" pattern and thereby causes more irregularity than advantages. But I'd like to hear others' opinion on this, I don't have a strong opinion yet. Jecel and John Maloney might have something wise to say about this as well?

Folks -

What a joy to read mail this morning. I think we're on the way.

Jon, Marcio, Allen, and Stefan, I agree completely about your improved layering for the kernel; clearly the compiler does not belong in the real core, which is should only be the support for the execution engine.

At the same time, I'm more partial to working with a live image than with static composition (as you know). It's just my sense of urgency to go forward, which I can see how to do with our live image. I have no problem with a follow-up project that might restructure a few things so that both approaches were equally well supported.

Obviously, the dynamic image model has some problem starting with a compiler-free core (though image segments could be used to bring in the compiler), but I see no problem with a core that is layered, and the compiler can be thrown out, but not brought back in.

Phil, I don't have an immediate answer to your question about layering of the mathematical support, but isn't it great to be thinking about it! I had fun in my tiny kernel project (which as all point out could be tinier still), using Floats to cover the few cases where LargeIntegers were needed. Clearly the inner kernel has some minimal support for numbers and math, and then there's a more comprehensive package that gets added later for those applications that need it.

Andreas and Henrik, I like (of course ;-) your enthusiasm for taking a simple step forward that will allow us to start factoring the system, and that will provide a target for the higher-level support of modularity and group development. I await Henrik's proposal for how to go about this, and meanwhile I'll dust off the old environments code to make sure it works, and remind myself of what else is needed.

- Dan