-----Original Message----- From: squeak-dev-admin@lists.squeakfoundation.org [mailto:squeak-dev- admin@lists.squeakfoundation.org] On Behalf Of Diego Gomez Deck Sent: Tuesday, July 16, 2002 11:39 AM To: squeak-dev@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:
- 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@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