On 12 February 2014 22: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.

They can, yes. But singletons and sexprs are still just objects. So
for instance, discriminating on a particular object is still just a
message send (well, in my head it is), albeit the definition of the
method isn't attached to a 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?!
>
>
> 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.

I didn't say CLOS's approach messy. I find it odd that Common Lisp
allows both keyword args and optional args, when keyword args are
inherently optional (in Common Lisp, that is). Plus you don't have to
argument-count if you just have keywords (in addition to the normal
parameters).

I think that the before/after/around method combinations to be very neat.

>> >  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.

Yes, this is the hack I meant. And I agree re the closure hack: it
looks a lot like a let binding, too. (It was #into: I was thinking of,
not #in:, obviously) I suppose the only thing I don't particularly
like is that the value comes before the variable, so instead of

(let [f 1]
   ;Clojure stuff)

it's

1 into: [:f |
    "Smalltalk stuff"].

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

Don't say that to Gilad :) "Inherently reflective" (and therefore
problematic from a stratification point of view) was how he described
them last time I said that I liked them. I think I did at one point
understand why he said that... and I should have written it down.
https://groups.google.com/forum/#!topic/newspeaklanguage/m2PO5RSQwFk
has the conversation.

frank

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