Alan,

I was going to mention ST-72 in my message, but it was too long already  
before I could get to it.  It seems to me that the
syntactic/semantic mechanisms within ST-80 may already be sufficient  
for a lot of what I am talking about if you use what I call
'trampolines'.  These are objects returned in response to 'prefix'
methods that collect subsequent messages and redirect them or do
other special things.  The example I've been working on is dealing
with collection iteration without blocks.  All of  this is
implemented in standard Smalltalk, no changes to the compiler or VM  
are needed.

The basic syntactic idea was to avoid  the use of blocks, but
instead use an extended message delivery mechanism to apply the usual  
messaging syntax and semantics to collections of objects.  The basic  
semantic idea was to have read-streams as the basis for operating on  
groups of objects at a time.  This allows operations to be composed  
and applied to external or other data sources in addition to standard  
collections.

There are some syntactic variants that I haven't fully worked out,
but here are some basic example sketches (all faked):

Select odd numbers:
	#(1 2 3 4 5 6) select odd  ->  #(1 3 5)
Compute factorials:
	#(1 2 3 4 5 6) collect factorial -> #(1 2 6 24 120 720)
Compute factorials of odd numbers
        #(1 2 3 4 5 6) select odd collect factorial  ->  #(1 6 120 )
Add two arrays of numbers:
	#(1 2 3)  collect + #(3 4 5) collect   ->  #(4 6 8)
Powers of two:
	2 collect raisedTo:#(1 2 3 4 5 6 7 8 9 10)   ->  #(1 4 8 16  
32 64 128 256 512 1024)
Odd powers of two:
          2 collect raisedTo:#(1 2 3 4 5 6 7 8 9 10) select odd  ->   
you know ...

This type of syntax will probably just be a shortcut for the general  
format

   anObject forall  msg1 msg2 msg3 ...  select|collect|reject

where msg1,msg2 etc. can have arguments that are themselves filters  
or series of filters.

The 'select' variant can be used as a powerful query language, with  
the query language being Smalltalk expressions.  This can be either  
evaluated sequentially/procedurally, or the 'trampoline' can collect  
all the expressions and run a query optimizer on them or convert them  
to SQL for passing to a database.

Going a little further on that thread, if a query optimizer were
available, the compiler could be used to run the query optimizer on  
the generated expression, similar to the way ifTrue:ifFalse and
whileTrue: are currently optimized.  To make such compiler extensions  
modular, there probably needs to be the notion of a 'generic
operation' that can be reified.  The compiler checks message
expressions with the 'known' generic operations and asks the
generic-operation class/object to transform the parse-tree.

Whoa!  Did I just reinvent Aspect Oriented Programming?  Maybe a  
squeaky version of it.  Anyway, I hope that the concept of bringing  
new functionality back into the system like this is applicable to  
other areas besides collections, but I have absolutely no idea wether  
this is the case, and wether trampolines and prefix messages can  
help or should be rejected becuse they just add confusion.

Just thinking...

Marcel


> The other comment is to recall that Smalltalk-72 embodied a solution to 
> what was considered a central problem of the sixties: that of needing a 
> powerful general purpose language that could nonetheless be extended in 
> all
> ways to better fit certain problem domains. ST-72 did this by actually 
> having the message interfaces to objects be in the form of a
grammar, and
> the objects actually parsed their messages on the fly. To extend the 
> language you simply introduced new classes with new grammars. The  
notion
> was that each object can also be thought of as a server on a
network, etc.
> This was a good idea up to a point. That point was that even good  
language
> designers (at least we thought we were!) very often implemented poorly 
> thought out extensions in the heat of programming and debugging. The 
> result
> was a gradual Tower of Babel in which it became harder and harder  
to read
> other people's ideosyncratic code. Dan solved this in ST-76 by
taking the
> most popular extensions (keywords, etc.) and making them into a fixed 
> syntax that nonetheless allowed quite a bit of expressivity while
> guarenteeing that anyone could read other people's code. I had
left PARC by
> the time Smalltalk-80 was specified, but I believe that it went
way too far
> in the ways it went, especially with regard to (un)readability,
how to deal
> with passing code as parameters, etc.