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

Eliot Miranda eliot.miranda at gmail.com
Wed Feb 12 22:49:07 UTC 2014


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

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". 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
>
> > --
> > best,
> > Eliot
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140212/cfb3d952/attachment.htm


More information about the Squeak-dev mailing list