Smalltalk wish list

Late note (2018):
this page was originally written in the late 90s, and nothing has happened since. ST/X will not wait for these changes any longer and started to get extensions to fix those shortcomings.

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. (late note 2020: some of them disappeared more or less; others appeared, such as Squeak and Pharo)

  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).

  The newer ST/X versions support C-style strings; but to not break backward compatibility, they need a special prefix to the string constant. Regular string constants still behave as usual, c-style strings are prefixed by a "c"-character.
  I.e.: c'foo\nbar\nbaz' defines a C-style literal string with embedded newline characters.

  ---

• 16bit (or more) string constants

  There should be some Smalltalk syntax for 16bit string constants.
  ST/X supports both single- byte and multibyte string constants, and chooses whichever representation is required.

  ---

• 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.

  ---

• immediate objects (aka anon-class objects)

  These are extremely useful to return multiple values in a structured way; other languages (JavaScript, Python etc. support those and make heavy use of them). In Smalltalk, you'd have to either define a simple data-holding class, or return a dictionary. Both are inconvenient. An extended literal syntax might look like:

      #{
  	foo: 'someFooString'.
  	bar: 1234
      }
  

  and a computed inline object like:

      {
  	foo: 'someFooString'.
  	bar: (1234 + a).
  	baz: Date today
      }
  

  Both can be parsed and distinguished from eg. brace arrays or literal arrays.

  ST/X supports such objects, where the object is kept in the literal array, and the set of their anon classes is remembered in a global dictionary and reused. The classes are simple data-holding classes only, providing getters and setters for computed objects, and getters only for their literals.

  ---

• 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.

  ---

• a standard UI framework

  There should be a common UI framework, possibly with limited functionality, which could be mapped onto the native framework. This could eg. be done by defining a simple spec format (aka literal window spec as in VW or ST/X, or XML-like), and dialect specific builders.
  Currently users are more or less locked into their dialect on the UI side. Things look a little better on the model side, but there as well are pitfalls to expect.

  ---