Technical Track: Smalltalkiana (Traits for Smalltalk and OOPAL)
The papers cover the application of traits to the
Smalltalk collection classes and the array programming features of
FScript.
Traits for the collection
classes:
The speaker started with an
overview of the collection classes in Smalltalk and the differences between
them. For instance we have ordered and unordered collections, identity and
equality comparisons, etc.
There is a
problem though, that single inheritance prevents a natural catagorization
because ordered and unordered collections can both be of fixed or variable size,
etc. Each dimension adds to the single inheritance heirarchy flowering. To
overcome this, the implementors pushed subclass behaviour into superclasses who
are not responsible for them.
Then the
implementors tend to disable messages (such as #at: on
Set).
The branching vs. improperly
assigning responsibilty is the problem tackled by the authors. (via
mixins?)
traits aim to add remove the
duplication of code while avoiding the complexity of multiple inheritance or
mixins.
traits are pure behaviour. They
are like partially abstract interfaces. adding centre and radius attributes to
an object would allow it to behave Circle behaviour. the behaviour would come
along with the trait.
implementors of
traits must provide the attributes required by the traits. It's very important
that the attributes supporting a trait are unambiguous. The author went through
a few techniques that remove
ambiguity.
Back to applying traits to
the collection hierarchy.
there was a
demonstration using squeak, for which there is some tool
support.
why traits (vs. mixins or
MI):
mainly because of the flattening
property of traits.
taking questions:
the questions focus mostly on the utility (why bother), and more formal
engineering processes (the application of traits to formal type
sytems).
OOPAL:
array
programming supports the sending of a message to an entire array of
polymophically equal object at the same time (without having to use for loops or
the like).
the cononical example is
given an array of obejcts of flights (with airplanes, pilots,etc) select aspects
of the flights.
in APL, X and Y are
arrays: 'X + Y', Java involves creating iterators and looping over
them.
OOPAL extends the APL ideas into
message based OOP languages (FScript).
{1, 2, 3} * 2 = {2, 4,
6}
{1, 2, 3} * {10, 20, 30} = {10, 40,
90}
The presenter goes into some
examples that express the power of the array programming system, including
alternate ways to achieve #select: (where the elements of Array respond to
#name).
Array at: Array name >
'Smith'
vs.
Array select: [:each | each name >
'Smith']
Posted at 04:40 PM
Read More
Neo-Smalltalk
Due to a technical problem, the live demo was
impossible.
The demonstration is of a
small computer built around an FPGA. The computer also has some RAM and flash
memory (for perm storage). The last chip is the "bios", which reads from flash
and programs the FPGA.
The computer is
an instant on computer, currently boots directly into a pong
game.
The computer was developed as
part of an application for truckers. It was intended to cost ~$30 (before the
LCD/keyboard).
The original intent was
to develop a very low cost computer for the poorer people of Brazil (like the
Simputer, I think). The machine is designed to go into schools (and even be
acquirable by private individuals). The co-design focussed on Smalltalk because
of it's exploratory background. The FPGA allows the designer to experiment with
hardware implementation of VMs. FPGAs can take on characteristics of other
processors.
Previous iterations could
only implement 16-bit machines, the current version can implement a 32-bit
machine.
The 16-bit machine was very
limited due to it's limited address range. The discussion went into
implementation tradeoffs of the Smalltalk system due to the small size. He wound
up customizing a Forth processor to be more efficient at message sending. He
could achieve message dispatch in one clock cycle. Mostly because RAM
outstripped the object space requirements by a factor of four (or
so).
One really cool thing about the
implementation was that the hardware was available to the tool level. So a user
who gets into programming will find the transition to programming the hardware
very smooth.
Another thing that was
cool was the way that syntax of his language eliminated the need for a real
compiler because you would actually program the abstract syntax
tree.
In the 32 bit version, there are
actually multiple 16 bit machines which operate as separate tasks. A 32 bit
implementation may involve multiple FPGAs, splitting the tasks across hardware
so that messages actually involve inter-processor
messages.
Really cool, but mostly over
my head.
Posted at 12:55 PM
Read More
Tuesday
I'm spending today attending demonstrations and
technical track presentations. Later tonight is the Squeak and Ruby BOFs, which
are always good.
Posted at 11:59 AM
Read More