Animorphic ST (Strongtalk) released!

David Simmons David.Simmons at smallscript.com
Sat Jul 20 00:16:14 UTC 2002


> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org [mailto:squeak-dev-
> admin at lists.squeakfoundation.org] On Behalf Of Diego Gomez Deck
> Sent: Tuesday, July 16, 2002 11:39 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Animorphic ST (Strongtalk) released!
> 
> Hi Dan,
> 
> [snip]
> >Some questions are:
> >
> >         Would the system benefit from being cast into StrongTalk?
> >                 and how much work would this be?
> 
> Some type of typed system lead us to some sort of multiple
inheritance.
> The
> types could be:
> 
> 1) ala C++: Multiple inheritance of implementation and protocol -> no
> comments.
> 2) ala Java / Objective C: Multiple inheritance of protocol.
> 2) ala StrongTalk: Multiple inheritance but based on mixins.

FYI -- to add to your list:

SmallScript, which is an extended dialect of the Smalltalk language, has
a full optional type system with dynamic type based binding
(multi-methods). This allows optional runtime enforcement of interfaces
and contracts.

It also provides multiple-inheritance of behavior and synthetic
multiple-inheritance of structure through (under-the-hood) aggregation
via concrete interfaces.

Although designed without explicit knowledge of Strongtalk, the type
annotation mechanism in SmallScript bears some similarity to Strongtalk.
Specifically, SmallScript uses the "<" and ">" characters for its
general annotation-operator expression form, which subsumes
type-annotations. 

Strongtalk uses suffix based type-annotations. SmallScript's annotation
declaration is a "prefix" operator. 

SmallScript's type declaration prefix semantics are consistent with
almost all other popular/major typed-languages. In doing so, it provides
consistent patterns for declaration of field/variable types within
classes/namespaces, and allows general use of "<...>" operator forms
throughout Smalltalk without introducing possible ambiguities.

For multiple-inheritance, SmallScript provides:
----------------------------------------------
o Abstract mixins via <Specification> (aka AbstractMixin).

o Pure behavior mixins via <Mixin>.

o Concrete fields with lazily instantiated mixins via <Interface>.

SmallScript also provides a fully optional type system and rich
extensible annotation architecture:
-----------------------

o Multi-methods based on arbitrary, extensible, binding predicates.
Offering generics based type-equations including limited support for
dynamically parameterized type binding.

o Type annotations on any expression or declaration.

o Consistent and unified definition of type with
classes/interfaces/mixins.

o Reflective use of type and type behavior for automatic and transparent
marshalling of method calls between Smalltalk and statically typed
(external/foreign) languages. This additionally includes direct support
for inline C/C++/assembly within Smalltalk method bodies.

o Reference types, value types, capturing and directionality semantics
[in/out/etc].

o Typing of fields within objects, as well as shared-variables. Field
definitions can be explicitly declared to be struct (value and unsafe
ptr) types, or reference (oop slot) types. Thus a given object layout
can be designed to correspond exactly to a c/c++ struct, including
support for unions, bitfields, etc.

==============================

As part of exploring work on type systems and their integration with
Smalltalk, you will find the SmallScript systems rich facilities for
optional type declaration and its support for dynamic typing to be of
value in your research. The SmallScript work in this area is the
outgrowth on my commercial Smalltalk language and runtime system work
since 1991. 

The SmallScript system is freely available [with technology previews for
Win32 x86]. It targets both its own AOS [Agents Object System] runtime
architecture, and the Microsoft .NET runtime architecture.

The above listed features, and many others, have been of key importance
in enabling the SmallScript system to support transparent Smalltalk
interop with other languages and to offer modularized componentization
of Smalltalk. This includes, but is not limited to, cross-language
interop with typed languages within the Microsoft .NET and COM/IDL
typelib systems.

SmallScript, unlike Strongtalk, currently only provides limited simple
case inlining within its runtime execution engine. The inlining
infrastructure including multi-method support is in place and used
throughout the JIT and cache binding processes. Extension of the
infrastructure to provide actual general case inlining has been deferred
to future releases since it only provides performance and not
functionality enhancements.

It is, otherwise, generally benchmarking with state of the art
performance which is typically equivalent to that of Cincom VW,
sometimes faster. It has a shared-library runtime deployable footprint
in the ~1MB range, allowing creation of applications and components as
small as 4kb, delivered as native shared-libraries and executables that
offer transparent exporting of Smalltalk methods as C/C++ callable
entrypoints.

-- Dave S. [SmallScript Corp]

SmallScript for the AOS & .NET Platforms
David.Simmons at SmallScript.com | http://www.smallscript.org

> 
> IMHO, the benefits (if any [*]) don't pay the complexity.
> 
> [*] I'm not a very old smalltalker, but I have some years of
experience
> and
> never the type-less system was a problem to me.... on the contrary, I
feel
> that the type-less system helps in the process of development.
> 
> >         Would anyone care if it ran 10 times faster?
> >                 and how much work would this be?
> 
> Yes... of course!  I use Squeak (for example) to simulate complex
systems
> and the extra performance is ever welcome.
> 
> >         Would it be fun to do?
> 
> I don't know, you tell me :-)
> 
> >Comments?
> >
> >         - Dan
> 
> Cheers,
> 
> Diego Gomez Deck
> 





More information about the Squeak-dev mailing list