Smalltalk wish list

This page lists things I would like to see in any upcoming smalltalk language standard. Please feel free to send additional suggestions to the author for inclusion in this document.

• conditional compilation

  Many organizations use various dialects of smalltalk concurrently (today, mostly ParcPlace vs. DigiTalk or VisualAge). Reusing code between these dialects is especially difficult, since smalltalk provides no facilities for conditional compilation.
  Therefore, different versions of a classes methods cannot be easily kept in one sourcefile, making maintenance a nightmare.
  With other smalltalks like SmalltalkAgents, Enfin and Smalltalk/X appearing, things will become even worse.

  Smalltalk requires conditional compilation at least on a per method basis (better yet: some kind of #ifdef within a method).

  A suggestion for per method conditional compilation is a construct like:

      !MyClass methodsFor:'category' forSystem:'name of system'!
  

  where "name of system" could be something like "VV2.0", "STX" etc.

  As a first step, systems should check and ignore methods (at fileIn time) which are not meant for them. However, to allow for all those versions to be at least edited and managed in a browser, methods for other systems should be read and kept in the class as hidden and/or non-executable methods.

  Browser support for these has to be added.

  Smalltalk/X already provides the required internal mechanisms to implement such a scheme: methods can be declared as ignored. These methods are visible on the browser level, but ignored with respect to method lookup. The ST/X browser already handles those ignored methods; they can be filed in and filed out just like any other method.
  Adding a conditional ignore feature to this basic mechanism would be an easy task.

  ---

• A standard for end of line comments

  End of line comments are useful and a common standard is required.

  ST/X uses "/ (double quote followed by slash) which is backward compatible with existing code (there has not been one class in all freeware classes which failed to load due to this new comment syntax).

• A standard for token block comments

  It has always been a pain, to comment a piece of code which contains comments. Although the above mentioned "End of line" comments are helpful and at least solve the problem of commenting-out code in the browser, it is still insufficient for documentation methods, if the code there shall contain comments (either EOL or regular comments).

  For this, ST/X supports token block comments, which start with "<<token (double quote followed by two less-characters and a token word) end ends until a line is encountered which starts with the token. For example,

      "<<END
  	this is all commented
  	and may contain other "comments"
  	or
  	"/ end of line comments
      END
  

  ---

• A standard for number types

  ST-80 uses the "d"-character to mark double number literals; i.e. "1.0" generates a float literal, while "1.0d" generates a double literal.
  VisualAge uses the "d" to mark Decimal number literals, which are (to add more confusion) called FixedPoint in both ST-80 and ST/X.
  To make things more complicated: ST/X generates double floats for all number constants which contain a decimal point. In ST/X, the corresponding class is called Float.
  (ST/X does support single precision floats, but those are called ShortFloat here).

  The reason for ST/X doing things that way is to make things as easy is possible, when code is ported from other systems; Float is the one supported by any of them - therefore, this is the default here. In ST/X, Double is an alias for Float - to avoid trouble if anyone accesses this class explicitely.

  There is definitely a need for a proper standard here.

  ---

• character escapes in string constants

  There should be some way to put graphical or control characters into a string constant; similar to (for example) the way this is done in the C language, using a backslash as escape character.

  Although such an extension is easy to implement, no standard exists yet; and, worse, the backslash is already used to mark carriage returns to be replaced by the #withCRs method.

  In ST/X, you can use the #withEscapes method, which translates C-language like escape sequences. Currently, this translation is done at execution time, but future versions of the compilers will detect sends of this selector to a string constant and perform this translation at compile time
  (but only, if the immutableArrays option is turned on).

  ---

• 16bit (or more) string constants

  There should be some smalltalk syntax for 16bit string constants.

  ---

• a language standard for multiple name spaces

  ST/X already includes a mechanism to define private classes and namespaces.
  It would be nice to have a common language standard for this.

  ---

• a standard binary file format

  Although some vendors may not like this idea, a standard binary format (and of course: a standard bytecode representation) should definitely be added to all systems - this would allow code interchange the "java way".

  Even if no common bytecode-encoding is possible, an intermediate bytecode representation could be defined, which is translated at load time to the particular implementation's encoding.
  Technically, this should not be too difficult, since the various smalltalk implementations bytecodes differ mostly in their encodings - less so in the semantic of the codes.

  ---