=?ISO-8859-1?Q?st=E9phane_ducasse?= wrote on Thu, 25 Nov 2004 21:40:24 +0100

Is NeoSmalltalk running on mac os X? Because I want to have a look.

No, since I am implementing it from the transistor level up it only runs on special hardware. But the software will use an MIT-style license (like Slate and OpenCroquet) so if anyone is really interested they will be able to port it to Macs or PCs. Since these already have Squeak, I am not sure it would be worth the effort.

The hardware I am currently use has a very weak VGA output, but I should have a new one with TV output soon. That will make it easy for me to make a movie showing what is cool about Neo Smalltalk (which is still being implemented).

http://www.merlintec.com:8080/Software/ is extremely outdated, but I currently don't have any other description of the software.

http://www.merlintec.com/download/plurion.pdf has low level details, such as the bytecodes used and hardware blocks. There is still a lot missing, specially the more interesting parts about the object model in Neo.

On a slightly related subject: the other day Colin was asking me about my future hardware design (non Von Neumann) so I added a brief introduction to http://www.merlintec.com:8080/hardware/19

-- Jecel

lex wrote on Sun, 28 Nov 2004 12:32:30 -0400

It does not violate POLA in Squeak's case, because the LA is simply very large. Squeak is a late-bound computer authoring system,

Exactly: "system" and not language.

and it is a *feature* that you can type "Display" to access the low-level bitmap, "Sensor" to talk to the mouse, and "Smalltalk" to talk to the system itself.

True.

You are supposed to be able to read in audio and, in response, change the globals table and recompile classes. Yes it's weird, but that's the point. We don't know what future designers will want.

You lost me in the "read in audio" part. Do you mean a "voice fileIn" sort of thing in some future version?

Thus, if you were to implement Squeak in a language without global variables, what you'd do is create one scope that has all of Squeak's current globals, and then do everything inside that scope. All you'd do is replace global variables, with practically global variables.

Right, so let's think about the *system* thing again.

Imagine something very like Squeak but without any globals at all. But somehow I am able to create an instance of some class I have written and then invoke an inspector on it. On the other side of the screen I can see a window/icon/whatever that represents the mouse input (previously known as the global Sensor). What if I can drag-n-drop that into one of the instance variables in the open inspector? Now my object instance has access to the mouse, but not to the display - the least authority it needs to do its job.

I, as the all powerful programmer and the environment as my proxy do have lots and lots of authority. I don't see why I should have to give it all to every single object in the system.

But before people go crazy, yes I think it is possible to make an authoring system where the least authorities aren't so large. In fact, I agree that such an authoring system would be marevelous to have. It's just a completely different system than Squeak. Squeak is an environment for building its own successor! To achieve that goal, Squeak should allow fast iteration of design ideas. This fast iteration is incompatible with chopping authority into little bits.

That is not how it looks to me.

Let's plan that, if and when people do build secure authoring environments similar to Squeak of today, we still continue to have something highly maleable like the current Squeak. Speed of iteration matters, and is one of Squeak's biggest selling points. Squeak has lots of goodies, and it also has lots of flexibility for doing whatever crazy thing you can dream up. This is a rare and important combination, and we should be careful to hang on to it.

Good plan, but once again I see no relation between making things simpler and stricter at the language level and slowing things down or making them less flexible for the programmers.

Finally, if we had to choose just one system, for some reason, I would vote for the maleable one instead of the secure one. It is more important to build the next Great Thing, than to make a better Current Thing.

Think of SUnit tests and eXtreme Programming. In theory, the tests get in the way of changes but in practice they are a powerful help in doing radical refactoring since otherwise you are always too afraid stuff will break without you noticing it to ever do serious changes.

My opinion is that a proper factoring the system that would make it much more secure will have similar advantages in terms of maleability. Intentions will be clearer and you can be more confident that any problems with your changes will have instant consequences and will be easy to fix.

-- Jecel

Hi folks!

Just can't resist. :)

Noury Bouraqadi bouraqadi@ensm-douai.fr wrote:

Stef,

In PocketSmalltalk globals are replaced by class variables in Object... But, in PocketSmalltalk there is a set of things done behind the scene developpers don't seem to have access to them.

Now, if we make the decision to remove gloabals we need to bootstrap the system somehow. Eg. how will we kow that Smalltalk refers to the global system dictionary?

Actually, I didn't think a lot about it. But, I have the feeling that we still need globals but need some extra scoping hierarachical mechanism: a kind of namespaces where the root namespace would named... Smalltalk...

Noury

Well, my Namespace package on SM allows this. I just installed it into 3.8-6465, and played with it. Read the class comment of Namespace, and then you can try these steps in a workspace:

"Let's create a namespace for globals:" Namespace newNamed: #Globals

"And put the Transcript in there:" Globals at: #Transcript put: Transcript

"Here we can see it has been added:" Globals keys ==> a Set(#Transcript)

"It is still also referenced in Smalltalk though:" (Smalltalk at: #Transcript) == Globals::Transcript ==> true

"Given how my namespaces work we have two keys in Smalltalk now:" Smalltalk keys select: [:k | k endsWith: 'Transcript'] ==> an IdentitySet(#Globals::Transcript #Transcript)

"So let's toast the old entry!" Smalltalk removeKey: #Transcript

"Now this should work:" Globals::Transcript show: 'Hi!'

"But this also still works! It gets expanded to Globals::Transcript:" Transcript show: 'Hi'

"So if you recompile a method that looks like this:" method Transcript show: 'Hi'. Globals::Transcript show: ' there!'

"It will autocontract because there is just one entry (in all Namespaces) that is called Transcript so the short name still fully identifies it." method Transcript show: 'Hi'. Transcript show: ' there!'

"But if you decompile it, you will see that it actually says this in the stored source:" method Globals::Transcript show: 'Hi'. Globals::Transcript show: ' there!'

---- Note though that the Namespace package is not fully working yet. But it is sufficiently working that you can play with it using a helmet.

regards, Göran

On Nov 26, 2004, at 4:27 AM, Trygve Reenskaug wrote:

Stef, A bad idea, IMO. A namespace should be a place for mapping names to objects, the behavior kind is a special case.

This argument seems unconvincing to me. The behavior kind may be a special case, but in practice it is probably 99%+ of the actual uses in Squeak. This creates the expectation that an unfamiliar capitalized name in some code is going to be a class. (Not counting class variables.)

You get a significant benefit in readability/clarity/uniformity of code if you know that all of these capitalized names are classes, with "Smalltalk" as the only exception.

And of course you still have global variables in a sense if you still allow access through the Smalltalk global dictionary. (e.g. "Smalltalk transcript") They just become a teeny bit less convenient, which seems appropriate to me... the less common usage should be more verbose, and the more common usage should be less verbose.

I don't know... it just seems that it's probably worth getting rid of a language feature that is relatively little used and so easy to replace with other mechanisms. This ain't C++, after all. ;) ;) ;)

So Stef, you have my vote to proceed. :)

Although I admit I haven't thought deeply about how a real namespace mechanism (such as Goran's or something like classboxes) would affect all of this.

- Doug

In UML, a *component* is a model element that encapsulates other elements, its named parts. In BabyUML, a component is an object that encapsulates a number objects, its named parts. This component maps names to parts in a private namespace.

In general, I feel that we do not get the full benefit of object orientation by exclusively focusing on classes and class structures. This was a weakness of early UMLs, it is also a weakness of current Smalltalks.

So let namespaces bind names to objects in general. Your work on multiple workspaces opens vistas of different kinds of system modularization, their namespaces will contain many interesting objects the like of which are not found in the current Smalltalk dictionary.

Cheers --Trygve

At 25.11.2004 16:43, you wrote:

...

Hi

I wanted to get feedback about the idea of removing global variables in Smalltalk. The fact that system dictionary or a namespace can contain variable ie (a binding to something else than a class) makes the code quite ugly since we have to always test if this is a class or not.

I think that we could easily remove the possibility to have global variable and move the ones we have into classVariable of Smalltalk or appropriate classes. This would lead to a more modular system.

Smalltalk keysAndValuesDo: [:k :v | v isBehavior ifFalse: [Transcript show: k ; cr]]

ImageImports Display ScheduledControllers ScriptingSystem Smalltalk CustomEventsRegistry World SystemOrganization References ActiveHand Transcript Undeclared SourceFiles Processor ActiveWorld TextConstants Sensor ActiveEvent

Now we would have to type Smalltalk transcript instead of Transcript.

Any thoughts.

Stef

PS: Backward compatibility is not a reason since we are about inventing the future not the past

--

Trygve Reenskaug mailto: trygver <at> ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway

The notion of "what is a program" has remained almost unchanged since ST-76. Even the default browser is the one that was created by Larry Tesler at that time. Those of us who are satisfied with the original system architecture can make some surface refactorings and be happy.

I am not happy because I find I spend an inordinate amount of time reading code without really understanding it. I can read almost every statement, but cannot envision what the objects are and do at run time. (And this applies to code I wrote a year ago.) I need to change the very notion of a program to get through the barrier to the run time objects. This means introducing higher level, object oriented notions to give me leverage and to hide some of the most obfuscating facilities.

I don't believe I am alone in this. The current work on namespaces is one initiative, traits could be another part of a future solution.

Cheers --Trygve

At 27.11.2004 23:39, Colin wrote:

On Nov 27, 2004, at 10:30 PM, Doug Way wrote:

...

On Nov 26, 2004, at 4:27 AM, Trygve Reenskaug wrote:

...

Stef, A bad idea, IMO. A namespace should be a place for mapping names to objects, the behavior kind is a special case.

This argument seems unconvincing to me. The behavior kind may be a special case, but in practice it is probably 99%+ of the actual uses in Squeak. This creates the expectation that an unfamiliar capitalized name in some code is going to be a class. (Not counting class variables.)

You get a significant benefit in readability/clarity/uniformity of code if you know that all of these capitalized names are classes, with "Smalltalk" as the only exception.

And of course you still have global variables in a sense if you still allow access through the Smalltalk global dictionary. (e.g. "Smalltalk transcript") They just become a teeny bit less convenient, which seems appropriate to me... the less common usage should be more verbose, and the more common usage should be less verbose.

I have to agree with Trygve here.

A namespace is a mapping from names to objects. If we find we need to do a lot of special casing around certain of those objects which happen to be classes, it's a sign we don't have the abstractions of the system very well separated. It may well make sense to have a mapping of names to classes, but if so, it's a ClassDictionary, not a Namespace, and we need to understand what that means for our design.

It seems to me that we need to clarify the lexical scoping rules for Squeak, particularly as they relate to environments. If we do that, the abstractions we need will be obvious, and then it's just a matter of getting the compiler to use them correctly.

Regarding globals vs class names, there's no reason they have to be in the same namespace. Each environment could have a class dictionary and a global dictionary; as long as we search them in a consistent order, all is well. On the other hand, I don't see how having only one global is any better than having a few of them; you still have to special case it or move it to another namespace.

Finally, consider this: removing globals is a significant change to the semantics of Smalltalk. If we decide to do that, fine, but it should be because we think it's an improvement to the language, not because it's marginally easier to implement.

Colin

Alan, AFAIK, I'm not inventing anything new. I am collecting some concepts and ideas that I happen to have come across (Mainly Smalltalk +Squeak + UML +some of my own) and try to cast them in a consistent architecture. Currently, I am creating and implementing a first architecture and kernel. In theory, practice should be straight forward, but I find that practice is surprisingly hard. The work isn't finished before I can share it with other people and they ask me how I could spend such a long time to get such such obvious results.

Mainstream is still to use OS and programming technology from the sixties (Unix and 3GLs). I am surprised that so many have been satisfied with so little for so long, and that the many innovations that must be out there aren't better known.

Cheers --Trygve

At 27.11.2004 22:36, Alan Grimes wrote:

...

I am not happy because I find I spend an inordinate amount of time reading code without really understanding it. I can read almost every statement, but cannot envision what the objects are and do at run time. (And this applies to code I wrote a year ago.) I need to change the very notion of a program to get through the barrier to the run time objects. This means introducing higher level, object oriented notions to give me leverage and to hide some of the most obfuscating facilities.

=) I think you are on the brink of re-inventing something I've developed, at least conceptually.

http://users.rcn.com/alangrimes/UCE/sphere.txt

my point was simply that we have 12 global variables in the system and that we all know that global variables is not a so good ideas so I was thinking that this would be nice to remove them. There is a lot of clunky logic in SystemDictionary just to deal with these globals isBehavior sent to all the binding values to make sure that we get only classes (of course we could have two dictionaries one for classes and one for variables we did that in a previous version but we would have to test also a lot more to make sure that we can't have a variable and a class with the same names if we want to keep the current shared namespace semantics of smalltalk). Now the idea of having classVariable in Object could be one way to do that. But you argument about typing less is not really sexy since this is true that is is shorter to type Smalltalk than Namespace smalltalk but you block the fact that we can have multiples ones. So everything is a question of cost and World current vs World to get rid of a not so good concept would be a deal I would sign for today. Except if there are other problems such as: it is easier for the VM to access to this globals than to have a msg send (which would be solve via Object classVariables)

Now about the future of Squeak I agree with you I prefer something malleable and simple. Because simplicity is also beauty for me. I'm just thinking that sometimes it may be easier to simply hack something in our corner without any idea of sharing it because we could go much faster and further and with much more fun (but this is my dark face that is talking of course). Our current goal is to make sure that we or other can invent the future (this is why we clean the kernel not for fun or masochism).

Stef

On 28 nov. 04, at 16:54, lex@cc.gatech.edu wrote:

It would be good to use class variables of Object instead of globals, just so that we can have one fewer kind of variable. The global variables would then be the class variables of Object. That's a pretty nice way to go: it simplifies the language while having no practical cost that I can think of.

It would also be possible to invent new classes and stuff the current globals into them. So it would be "World current" instead of "World". But that actually seems to be a step backwards. If I want the current world--an important concept for Morphic programmers--why should it require more than one word to name what I want? Maybe you are thinking that when I write "World", the semantics should be other than a simple variable lookup like right now? Well, if that ever happens, then let's revisit the idea. Right now, variables are the only way in Squeak to get one-word names for things.

I do not understand the multiple types issue that you bring up. I agree with Trygve that it is nice to have a *general purpose* mechanism for mapping names to the *objects* they denote. It is hard to predict what individual words we would like to be globally acceptible in the future, but notice that we already have some (World, Smalltalk, Sensor, Display) which do not denote classes and which have been proven convenient over the years. I don't want *any* of these to require multiple words to specify, and so I am not convinced that only classes should be named at the global scope. You mention testing for whether something is a class or not, but when should this happen? For one, there are already plenty of methods for navigating the class hierarchy; for another, they can just as well be implemented with code like "ProtoObject withAllSubclasses" instead of by rooting around in the global variables.

So in short, reimplementing globals as class variables of Object: good. Replacing all globals with a two-word designation: bad. Yes, we want the language design to be pretty and concise, but we should also strive for things *written* in the language to be pretty and concise.

Lex

On Nov 28, 2004, at 4:37 AM, Avi Bryant wrote:

On Sun, 28 Nov 2004 13:03:51 +0100, stéphane ducasse ducasse@iam.unibe.ch wrote: This is, of course, assuming that we have global variables at all. I'd also be happy with a Self-like approach, where a reference to Smalltalk was simply a shorthand for "self Smalltalk" (and Array was a shorthand for "self Array", etc).

Ditto. (and that's about all I have to say on this whole thread!)

-- Brian T. Rice LOGOS Research and Development http://tunes.org/~water/

Ned Konz ned@squeakland.org wrote:

Date: Sun, 28 Nov 2004 10:49:00 -0800 From: Ned Konz ned@squeakland.org Subject: Re: About removing global variables To: squeak-dev@lists.squeakfoundation.org reply-to: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org

On Sunday 28 November 2004 4:03 am, stZphane ducasse wrote:

...

my point was simply that we have 12 global variables in the system and that we all know that global variables is not a so good ideas so I was thinking that this would be nice to remove them.

Actually, at least three of the global variables are (or could be) class variables in Morph. These are:

World ActiveHand ActiveWorld

Sounds good to me, provided you figure out a way for World to be accessible in workspaces as well. I don't care about ActiveHand and ActiveWorld. I don't even know what ActiveWorld is....

Still, I don't see a reason to take the attack on globals as more than a guideline. It's a good guideline, but we've already been following it. 12 sounds like a good number to me. That's one variable for each of a small number of fundamental concepts in the system. Fundamental concepts *should* be accessible by just typing the name of it. Sure global variables have problems, but that's all we have right now. And anyway, if a concept is global and widely used and singleton, isn't that just what a global variable is for? Squeak has one Display. Thus, why not make it a global variable?

Maybe a good alternative would be to move them into pool dictionaries or some other kind of namespace? Then anyone who imports the "Morphic" namespace has access to World, and others can leave it alone. Anyone who imports the "LowLevelDisplay" namespace has access to Display and Sensor. (And before doing this, please make workspaces auto-import a customizable list of namespaces. If we lose the ability to do things like "World flash", then we are taking a step backwards!)

As food for thought, notice that you can keep adding more abstraction indefinitely:

World flash

World current flash

Flasher flash: World current

Flasher defaultInstance flash: World current | flasher | flasher _ Flasher new. flasher flashingAlgorithm: #default. flasher flashTarget: World current. flasher beginFlashing.

In short, let's not to pretty up the language at the expense of ugly programs. Squeak is supposed to be programmed, not just talked about, and there will be tradeoffs that are necessary.

-Lex

stéphane ducasse wrote:

but lex

you could have World as a classVariable or

world ^ World current

and only get this problem in workspaces and we write much more code in method bodies than in workspace.

Stef,

There could be a lot of discussion about the disadvantages of removing globals (and there are many, in fact so many that I predict without any hesitation that it is not going to happen), but what, in your opinion, are the *benefits*?

I hope you're not going to simply tell us that 'everybody knows that globals are bad' :-).

Frankly, I am worried by your comments. You are a Prof. Dr. (i.e., a professor and a PhD) and people listen to what you have to say, and think that you probably know what you are talking about. Your students, but many others as well.

Then you come with this ludicrous suggestion of removing globals from Squeak, without apparently having thought through even the most obvious consequences.

I admit that when I first saw your suggestion I assumed you weren't really serious, but rather trying to make a point. But now it appears you are in fact serious.

I don't expect you to go and discuss this with me here, so I'm simply telling everyone who wants to hear it that this suggestion of removing globals seriously, is an idea that is going nowhere, and essentially a waste of time.

Cheers,

Peter

Hi lex

something else occurred to me today. Your workspace can have extra bindings and this not requires that the language has to have global.

Stef