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.

>  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?!

>  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] ?

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.

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