[squeak-dev] what is smalltalk? (was: Smalltalk dialects and GSoC)

Tobias Pape Das.Linux at gmx.de
Wed Feb 12 23:05:13 UTC 2014


On 12.02.2014, at 23:49, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Frank,
> 
> 
> On Wed, Feb 12, 2014 at 12:58 PM, Frank Shearar <frank.shearar at gmail.com> wrote:
> On 12 February 2014 19:05, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> > Hi Frank,
> >
> >
> > On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <frank.shearar at gmail.com>
> > wrote:
> >>
> >> On 12 February 2014 00:22, tim Rowledge <tim at rowledge.org> wrote:
> >> >
> >> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <jecel at merlintec.com>
> >> > wrote:
> >> >
> >> >> Any discussion of what is Smalltalk and what isn't can't get very far
> >> >> without first clearly defining a few things.
> >> >
> >> > In the same way that Filk is music performed by people that consider
> >> > themselves to be Filkers, I would suggest that maybe Smalltalk is what is
> >> > written by people that consider themselves to be Smalltalkers.
> >> >
> >> > Is everything an object? Do objects have classes? Do objects communicate
> >> > by sending messages and getting back results? Is an image saved and
> >> > restarted? Can you forget about having to deal with memory allocation? If
> >> > the answer is yes to those questions then it’s probably a Smalltalk.
> >>
> >> Of course, this makes Common Lisp a Smalltalk :) (They certainly have
> >> a whole bunch of characteristics in common, which given Smalltalk's
> >> influences should not be a surprise.) (And no, I don't seriously
> >> consider Common Lisp a Smalltalk, just in case anyone thinks that I
> >> do.)
> >
> >
> > Good that you don't think CL is a Smalltalk.  But why?  Generic functions vs
> > message sends, instance encapsulation and syntax.   I think generic
> > functions are very different to Smalltalk/Self-style message sending
> > (Java/C++/JavaScript message sending is much closer to Smalltalk).
> 
> Yes, as long as one also remembers that Foote, Johnson and Noble [1]
> showed that you can curry generic functions into single-dispatch
> message sends.
> 
> >  And
> > hence method combination is very different in CL to Smalltalk's simple super
> > send.
> 
> Yes, this is a big difference. Mainly those are macro-like, IIRC. [3]
> It's been too long since I last touched Common Lisp!
> 
> >  While Newspeak extends Smalltalk's send semantics with
> > lexically-scoped sends, the extensions are still very much like Smalltalk
> > message sends (polymorphic, dispatching on a single receiver).  The other
> > major difference is encapsulation.  In CLOS there isn't any.
> 
> Kinda. I mean, sure, slot-value gives you direct access to a slot
> (what Smalltalk calls an instance variable, for those following
> along). But (slot-value foo 'bar) translates to foo instVarNamed:
> 'bar'. Seeing slot-value in Common Lisp source ought to make you feel
> as queasy as when you see #instVarAt: and friends.
> 
> I am half a world away from my copy of AMOP, so I can't find out
> whether the MOP lets you intercede slot-value calls. I'm not sure of
> the differences between Common Lisp slots and Pharo's Slots, in other
> words.
> 
> >  Generic
> > functions imply that not everything is an object.
> 
> Surely generic functions are objects that have an apply method?
> Generic functions certainly do imply that functionality doesn't always
> belong only to one, privileged, class.
> 
> No, I mean that generic functions can discriminate on anything, including singletons, s-exprs, right?  So they're more general than message sending and allow one to access the Lisp types CLOS is built from.
> 
> >  But CLOS has a MOP and
> > we're in catch-up here.  Pharo is doing good work with Slots.  Finally
> > syntax is important.  The mixfix syntax that Smalltalk has is simple and
> > powerful.  CLOS has keyword arguments but they're quite different, for
> > optional parameters and can have default values and occur in any order.
> 
> Yes, Common Lisp has a bit of a mess here. I mean, if you have keyword
> arguments, do you really need optionals as well? And then let both
> happen in the same function signature?!
> 
> I'm not sure I'd call CLOS's approach messy.  It /is/ very different.  Smalltalk's designers put a lot of effort into designing a simple but powerful syntax (including for literals).  And in doing that they avoided some of CLOS's flexibility.
> 
> >  A
> > final significant facility is multiple return values.  Smalltalk has a neat
> > hack (providing a block to receive the results), but that's not as
> > convenient.
> 
> The hack - do you mean 1 in: [:x  | x + 1] ?
> 
> I mean this idiom:
> 
> 	self accessorsAndAssignmentsForMethod: method
> 		actuals: {}
> 		depth: 0
> 		interpreterClass: interpreterClass
> 		into: [:theRoots :theAccessors :theAssignments|
> 			roots := theRoots.
> 			accessors := theAccessors.
> 			assignments := theAssignments].
> 
> It's nicer to be able to write
> 
> 	roots, accessors, assignments :=
> 		self accessorsAndAssignmentsForMethod: method
> 			actuals: {}
> 			depth: 0
> 			interpreterClass: interpreterClass

There used to be a syntax like this:

	{ roots . accessors . assignments } := #( 1 2 3 )

But, while there are traces of support for that, I seems largely ripped out… (to my sad-face-ing)


> 
> But as an implementor I'm not sure the complexity pulls its weight.  The closure hack works well enough.
> 
> 
> Dan Ingalls, IIRC, had an extension or something where you could write
> "a, b := self aMethodReturningaPair".

see above.

> Clojure's destructuring
> mechanisms [2] is probably the nicest thing I've seen here. A pet hack
> I've been working on has a #destructureIn: where you can say
> 
> #(1 2) destructureIn: [:x :y | x + 1]
> 
> which lets me avoid loads of local variables.
> 
> Yes, I use something similar a fair bit
> 
>     [:a :b ... | ... ] valueWithArguments: tuple
> 
> etc.
> 
> And the Selector>>value[:...] hacks are clever too:
> 
>     (2 to: n) select: #even
> 
> frank
> 
> [1] http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html
> [2] http://blog.jayfields.com/2010/07/clojure-destructuring.html
> [3] http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1625 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140213/661457ac/signature.pgp


More information about the Squeak-dev mailing list