isomer - Alright - looked it up again and, yes, my bad. So, Scintilla sounds like the perfect basis for a Source Code Editor for Visual Works.

About the VS(E) part, we only discovered that Scintilla exists after having finished something similar (CodePane) for my (former) company's VS implementation.

This looks really, really nice, Antony. Very well done.

As an aside, Scintilla runs natively on OS X, and most other platforms. In a previous life, I wired it into VSE and even hooked up a code completion facility using their callback mechanism. Worth looking into, imo. It's a well written piece of software.

Claus,

I'm 'proposing' anything. I've built something, and published it, but I'm not sure if you're talking about that.

As far as 'bar := Foo new' is concerned, my point is that for a type inferencing system to be complete and correct it must deal with semantics of the langauage as is exists, without the layering of convention. I understand you are talking about manual annotation. I think manual annotation (as used in e.g. Lisp) is strictly useful for performance tuning. It's the worst of both worlds when used in code that is changing - your annotation can be wrong but the system can't tell you that. IMO inferencing is the only practically useful approach for Smalltalk.

As for the code editor, I spend most of my Smalltalk time in the code editor, sometimes writing, more often editing. Yes, ST allows me to do more with less, but in my case that allows more output, rather than less input. I'm sure it seems less annoying if you are not on MacOSX. And as a comparison, I've been investigating Squeak for the last few days, and the fact that it recognises the command key is such a sweet joy.

What you propose is something like a Meta-Database which has a mapping of methods (are method signatures unique?) to argument types and return value types?

About foo := Bar new. :

Are there actually Factories which use "new"? Of course, this is possible and propably useful in cases, but I would simply forbid this in lights of having something useful to help with type checks or even type inference.

And I know realize you misunderstood me, adding the tags to the method arguments is not something which should be inferenced, it is something the programmer should be able to do (which basically is just like public String getBla (Integer b){})

Honestly, we had a few discussions concerning types at my former (smalltalk) shop - and the general agreement was that there are certain things which you simply cannot do in Smalltalk and a lot of things which you can do because it is Smalltalk and that there are things which you can do but never should, like trimming the first method argument and concating it to a new string, turning it into a symbol which then gets performed by the second method argument.

About the code editor - it appears as if my own expectations towards Smalltalk implementations are not as high as they should be, I do not know why. Probably it is because you can do so much in so few lines that there is not so much need for code write helpers.

My general opinion towards a type system is that if you need static types, you do not understand what your code does. The optional annotations would be a great help to understand foreign code, but as I said, it should be optional.

Claus,

We'll just have to agree to disagree about the code editor. IMO it's nowhere near acceptable. And in any case, isn't this Smalltalk? The best language every invented for this stuff? Is this REALLY the best we can do after 30 years?

As far as type annotations are concerned, RoelTyper already exists to do those kinds of type inference. IMO inserting type assertions on the basis of fuzzy inferencing isn't a great idea. If you want that information then it shouldn't be part of the code, it should be a visual annotation. I've usually found the inferred types in my code to be too general to be useful because there are enough reliable constraints.

Furthermore, in code like this 'foo := Bar new', there is no guarantee that foo is actually a Bar. It could be anything, and that's just the tip of the iceberg. It is only a common expectation that patterns of code have a certain meaning, let alone a certain type. You need to operate on something more rigorous than expectations in order to do reliable type inferencing.

More like TextMate than a CAD Tool :)

It's not about the number of commands in the RB. The published system isn't fully configured. All of the Launcher commands should be available in every context, and then when you add code snippets, and custom commands, you end up with many more commands in the list.

There are two points to this. Firstly, separating the concept of the command from the menu system - the menu system should be derived from the commands, not the other way around. Secondly, providing a scalable keyboard-only way of both operating VW and navigating and exploring every operation available. So it addresses the first part of your argument about why you like pragmas-as-text-in-code. I'll deal with your C/C/P-convenience argument in a separate post.

In the back of my mind is a Quicksilver-like extension. To give a trivial example: when you use one of the ivar commands without an ivar selected, the RB will bring up a selection list. I would like to see that incorporated in the Commando UI. Then the 'Find Class...' style commands could also be integrated in the same way. Thus commands could become command templates which are further parameterised using integrated exploration/selection/filtering facilities, within a GUI but completely controlled by the keyboard, and faster to use than typing. That last point is trivial in my mind, but neccessary to avoid criticism. The big advantage is in the seamless leveraging of the live code model.

ok, then in words:

You could annotate the type of a method argument and then even do something like:

read: aString [aString]

(added by compiler)self assert: [aString isString].

That way, you could pretty much add an implicit type checking system.

that should be

read: anArgument <String>

Clau

I think the normal SystemBrowser CodeEditor is acceptable - not as good as it could be.

Minor improvement suggestions:

1. If a message is sent to either self or super, you definitely know what the messages can be.

2. If the receiver is a Class, then you do know it can only understand its own class methods or the inherited ones.

3. If a receiver is explicitly declared (i.e. foo := Bar new) in a method, and a message is going to be sent to that receiver within that method, it is also definitely known what messages it can understand.

Pretty much everything else depends on a Type System.

Of course, you could allow something like this:

read: anArgument

[...]

or even do this for Instance Variables and Class Variables, sorry, Shared Variables in VW-Speak, but that would mean to enhance the class definition format but still maintain backward compabitility.

This is cool. I've never been convinced that the RB has too many commands that we'd need it, but may be I'm wrong on that.

Yes, I've used that in Dolphin. The only issue I ever had with Dolphin was the lack of documentation, which was understandable given that the economics for OA weren't really working well before they ceased development.

My interest now is in OSX for development and Unix for deployment, and in any case I'd not want a platform-specific editor IN VisualWorks.

It's not a huge amount of work to do a decent editor. And you could make a significant difference by replacing the editor used in a few key locations (RB and derived tools + the debugger) i.e. don't 'fix' the current ParagraphEditor at all. Sure, improvements don't flow backwards, but it would be a lot easier.

Maybe we'll see that in a 2010 or 2011 release?

Did you have a look at Scintilla? Though I fear it is a Windows-Only CodeEditor Control. It works wonderfully in Dolphin, though.

If you are at ESUG, have a look at this:

http://www.esug.org/Conferences/2008/A+Moribund+Smalltalk+still+alive+and+kicking%3A+The+APIS+VisualSmalltalk+IDE?_s=2Eg0waKSz026YsTg&_k=B-4G1mq2&_n&24

Outside of perhaps some Java Tools, the CodePane is the best Source Editor Control I had the pleasure to use.