Squid language (was: Looking for tools for support of theoretical informatics research)

Andreas Raab andreas.raab at gmx.de
Fri Jul 11 21:14:13 UTC 2003


Just FYI:
> Right now I'm designing the language and am leaning towards 
> lambda-based objects a la E (erights.org).  That is, every object
> is a block.

This was what inspired me to do the "objects as methods" stuff - just being
able to experiment with these notions is incredibly powerful.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Anthony Hannan
> Sent: Friday, July 11, 2003 7:50 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Squid language (was: Looking for tools for support 
> of theoretical informatics research)
> 
> 
> Hannes Hirzel <hannes.hirzel.squeaklist at bluewin.ch> wrote:
> > In this context it might be noted that Anthony began a 
> little subproject 
> > called Squid which could be very
> > interesting from a theoretical point of view as well; just 
> search the
> > mail archive for 'Squid' (and perhaps ask him for a status report).
> 
> Thanks for remembering.  You can check out the Squid web page at
> http://minnow.cc.gatech.edu/squeak/Squid.  However it is not 
> up to date.
>  I am still experimenting.
> 
> Right now I'm designing the language and am leaning towards 
> lambda-based
> objects a la E (erights.org).  That is, every object is a 
> block. When a
> message is sent to an object its block is invoked with the message
> object as is sole argument.  Dispatching on the message 
> selector is done
> by calling #dispatch:.  For example:
> 
>  false _ [
> 	here dispatch: {
> 		#and: -> [false].
> 		#or: -> [here arg value].
> 		#not -> [true].
> 	}
>  ].
> 
> 'here' is synomynous with 'thisContext'.  The sole message argument is
> not explicitly specified since it is the same everywhere.  It can be
> accessed via 'here message' or its components can be accessed 
> via 'here
> selector', 'here args', 'here receiver'.
> 
> A "class" would look like:
> 
>  Message _ [
> 	receiver _ nil.
> 	selector _ nil.
> 	args _ nil.
> 	instance _ [
> 		here dispatch: {
> 			"instance methods"
> 			#receiver -> [receiver].
> 			#selector -> [selector].
> 			#args -> [args].
> 		}
> 	].
> 	here dispatch: {
> 		"class methods"
> 		#receiver:selector:args: -> [
> 			receiver := here args first.
> 			selector := here args second.
> 			args := here args third.
> 			instance
> 		].
> 	}
>  ].
> 
> 'Message receiver: 1 selector: #+ args: {2}' would return the
> instance block with free vars (receiver, selectors, args) bound
> appropriately.  It will understand #receiver, #selector, or #args.
> 
> If a message is sent to an object that it does not understand 
> directly,
> it will delegate to the selector's default block if one exists.  For
> example,
> 
>  #arg _ [here receiver args first].
> 
> When 'arg' is sent to an object and the object does not specify an
> implementation for #arg, then the #dispatch: method will invoke the
> block assigned to #arg with the original message as its 
> message.  So the
> above block will be invoked with 'here receiver' referring to the
> original message instance.  This #arg message will work on any object
> that understands #args, which in our case includes both Messages and
> Contexts.
> 
> These "default" blocks replace inheritance.  Although inheritance can
> be implemented by the user by implementing his own dispatch method.
> 
> Finally, a nice side-effect of block-objects is that the same block is
> invoked for every message sent to an object, allowing us to implement
> "method wrappers" easily.  For example,
> 
>  nil _ [
> 	Transcript show: here message printString.
> 	here dispatch: {
> 		#isNil -> [true].
> 		#ifNil: -> [here arg value].
> 		...
> 	}
>  ].
> 
> 'Transcript show:...' will be called on every message sent to 
> 'nil' even
> if it does not understand it.
> 
> Comments?
> 
> Cheers,
> Anthony
> 
> 



More information about the Squeak-dev mailing list