Common type system

• Simplified tooling for features that enable interoperability with executables coded in other languages (ie Web services, RMI, CORBA)
• Simplified mechanism for automatically representing the interface of a class in a language neutral manner (ie. via XML schema; WSDL )
• Potential performance optimizations when type information is exploited
• Potential to detect runtime problems (ie. DNU) at compile-time. If we know a parameter's type, we know the messages that it should understand.

Type specifications should be an optional feature that enables a class to provide 'hints' about its interface. Features can exploit or ignore the supplied type information.

The typing issue seems applicable to all Smalltalk implementations, and this seems like a good project for the Camp Smalltalk community to tackle.

Strongtalk and SmallInterfaces are two examples of work already done to enable types in Smalltalk. The goal of this project is to evaluate preexisting type specification strategies, select a common approach, and start implementation (or porting) of a Smalltalk type system.

Is anyone interested in working on this at CS4? Bryan Hogan

Some useful links:

Strongtalk (http://java.sun.com/people/gbracha/nwst.html)

Smalltypes (http://members.fcc.net/panu/SmalltalkTypes.htm)

SmallInterfaces (http://www.jot.fm/issues/issue_2002_05/article1)

I'm not sure how you plan to proceed, but it might be by trying to figure out pros and cons of the existing type system proposals. If you have any questions concerning "SmalltalkTypes", let me know and I'll try to answer daily during the CS4 week.

By the way, I like your term "SmallTypes" for this style of defining types - 'Small' because the types are defined with minimal amount of extra machinery.

Secondly, coming up and elaborating possible applications of a type-system for Smalltalk would seem like a worthwhile exercise.

I think generating WSDL is a great idea. If the type signature of a Smalltalk method was known, generating the WSDL should be 'easy'. (Well, we'd have to try it to see how easy.)

The allure of SmallTypes (I'm using your term already) in this respect is that it doesn't require the programmer to go to any extra efforts for defining the types - every method already has a type signature, if interpreted according to the STs rules.

This means we could automatically generate the WSDL for all the public methods in an image already. Naturally many arguments and return values would be simply of type 'Object' (because of the "Default Rule")

Another useful exercise for any type-system proposal would be to see how well and easily the ANSI protocols might be presented within the type-system. The results of this exercise might form the basis for ST-ANSI-2 in the future.

Thirdly, everybody wants to do some coding, right? I do have some code for parsing SmalltalkTypes from ST source-code. But it might be more in the spirit of Camp Smalltalk to apply the parser in the RefactoringBrowser for this purpose.

Although SmalltalkTypes focuses on defining the interface types only, with the help of a 'real parser' the information about the interface could be put to use also inside the method, to infer possibly illegal message sends. For instance once we know the type of the argument, and the parser tells us which messages are sent to it, we could easily catch any messages sent that are not part of the declared type.

As opposed to Java, this wouldn't stop the compiler from producing executable code, but would merely provide the programmer with a warning of possible misuse. It might be for instance that the called method does exist, but shouldn't be called since it is private.

Panu Viljamaa -- http://members.fcc.net/panu/SmalltalkTypes.htm