On Thu, Feb 13, 2014 at 5:39 AM, Frank Shearar <frank.shearar at gmail.com>wrote:

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

Yeah.  I guess I have this bias that whatever existed before CLOS wasn't an
object but that's mistaken.  generic functions allows CLOS to assimilate
the existing types as objects.  The borg within :-).  Compare this with
e.g. Objective-C,Java/C++ where the C and/or primitive types are not
objects.  Good for CLOS.


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


"Yes, Common Lisp has a bit of a mess here." ;-)


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

They're very powerful.  But personally I find the Smalltalk approach more
than adequate.  super allows one to do most things CLOS method combination
is used for and is easier to understand.  I think that's the important
philosophical difference.  There's a minimality about Smalltalk that I love.


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

Yes, again I accept it because of its minimality.

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

I do say such things to Gilad.  He and I disagree on plenty of things ;-).
 That we can disagree still work together is a pleasure.  There's much
creative discussion to be had in exploring differences.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140213/caf16f16/attachment.htm