<div dir="ltr">Hi Frank,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 12, 2014 at 12:58 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 12 February 2014 19:05, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
> Hi Frank,<br>
><br>
><br>
> On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
> wrote:<br>
>><br>
>> On 12 February 2014 00:22, tim Rowledge <<a href="mailto:tim@rowledge.org">tim@rowledge.org</a>> wrote:<br>
>> ><br>
>> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>><br>
>> > wrote:<br>
>> ><br>
>> >> Any discussion of what is Smalltalk and what isn't can't get very far<br>
>> >> without first clearly defining a few things.<br>
>> ><br>
>> > In the same way that Filk is music performed by people that consider<br>
>> > themselves to be Filkers, I would suggest that maybe Smalltalk is what is<br>
>> > written by people that consider themselves to be Smalltalkers.<br>
>> ><br>
>> > Is everything an object? Do objects have classes? Do objects communicate<br>
>> > by sending messages and getting back results? Is an image saved and<br>
>> > restarted? Can you forget about having to deal with memory allocation? If<br>
>> > the answer is yes to those questions then it’s probably a Smalltalk.<br>
>><br>
>> Of course, this makes Common Lisp a Smalltalk :) (They certainly have<br>
>> a whole bunch of characteristics in common, which given Smalltalk's<br>
>> influences should not be a surprise.) (And no, I don't seriously<br>
>> consider Common Lisp a Smalltalk, just in case anyone thinks that I<br>
>> do.)<br>
><br>
><br>
> Good that you don't think CL is a Smalltalk. But why? Generic functions vs<br>
> message sends, instance encapsulation and syntax. I think generic<br>
> functions are very different to Smalltalk/Self-style message sending<br>
> (Java/C++/JavaScript message sending is much closer to Smalltalk).<br>
<br>
</div></div>Yes, as long as one also remembers that Foote, Johnson and Noble [1]<br>
showed that you can curry generic functions into single-dispatch<br>
message sends.<br>
<div class="im"><br>
> And<br>
> hence method combination is very different in CL to Smalltalk's simple super<br>
> send.<br>
<br>
</div>Yes, this is a big difference. Mainly those are macro-like, IIRC. [3]<br>
It's been too long since I last touched Common Lisp!<br>
<div class="im"><br>
> While Newspeak extends Smalltalk's send semantics with<br>
> lexically-scoped sends, the extensions are still very much like Smalltalk<br>
> message sends (polymorphic, dispatching on a single receiver). The other<br>
> major difference is encapsulation. In CLOS there isn't any.<br>
<br>
</div>Kinda. I mean, sure, slot-value gives you direct access to a slot<br>
(what Smalltalk calls an instance variable, for those following<br>
along). But (slot-value foo 'bar) translates to foo instVarNamed:<br>
'bar'. Seeing slot-value in Common Lisp source ought to make you feel<br>
as queasy as when you see #instVarAt: and friends.<br>
<br>
I am half a world away from my copy of AMOP, so I can't find out<br>
whether the MOP lets you intercede slot-value calls. I'm not sure of<br>
the differences between Common Lisp slots and Pharo's Slots, in other<br>
words.<br>
<div class="im"><br>
> Generic<br>
> functions imply that not everything is an object.<br>
<br>
</div>Surely generic functions are objects that have an apply method?<br>
Generic functions certainly do imply that functionality doesn't always<br>
belong only to one, privileged, class.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> But CLOS has a MOP and<br>
> we're in catch-up here. Pharo is doing good work with Slots. Finally<br>
> syntax is important. The mixfix syntax that Smalltalk has is simple and<br>
> powerful. CLOS has keyword arguments but they're quite different, for<br>
> optional parameters and can have default values and occur in any order.<br>
<br>
</div>Yes, Common Lisp has a bit of a mess here. I mean, if you have keyword<br>
arguments, do you really need optionals as well? And then let both<br>
happen in the same function signature?!<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> A<br>
> final significant facility is multiple return values. Smalltalk has a neat<br>
> hack (providing a block to receive the results), but that's not as<br>
> convenient.<br>
<br>
</div>The hack - do you mean 1 in: [:x | x + 1] ?<br></blockquote><div><br></div><div>I mean this idiom:</div><div><br></div><div><div><span class="" style="white-space:pre"> </span>self accessorsAndAssignmentsForMethod: method</div>
<div><span class="" style="white-space:pre"> </span>actuals: {}</div><div><span class="" style="white-space:pre"> </span>depth: 0</div><div><span class="" style="white-space:pre"> </span>interpreterClass: interpreterClass</div>
<div><span class="" style="white-space:pre"> </span>into: [:theRoots :theAccessors :theAssignments|</div><div><span class="" style="white-space:pre"> </span>roots := theRoots.</div><div><span class="" style="white-space:pre"> </span>accessors := theAccessors.</div>
<div><span class="" style="white-space:pre"> </span>assignments := theAssignments].</div></div><div><br></div><div>It's nicer to be able to write</div><div><br></div><div><span style="white-space:pre"> </span>roots, accessors, assignments :=<br>
</div><div><div><span class="" style="white-space:pre"> </span>self accessorsAndAssignmentsForMethod: method</div><div><span class="" style="white-space:pre"> </span><span style="white-space:pre"> </span><span class="" style="white-space:pre"> </span>actuals: {}</div>
<div><span class="" style="white-space:pre"> </span><span style="white-space:pre"> </span><span class="" style="white-space:pre"> </span>depth: 0</div><div><span class="" style="white-space:pre"> </span><span style="white-space:pre"> </span><span class="" style="white-space:pre"> </span>interpreterClass: interpreterClass</div>
</div><div><br></div><div>But as an implementor I'm not sure the complexity pulls its weight. The closure hack works well enough.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Dan Ingalls, IIRC, had an extension or something where you could write<br>
"a, b := self aMethodReturningaPair". Clojure's destructuring<br>
mechanisms [2] is probably the nicest thing I've seen here. A pet hack<br>
I've been working on has a #destructureIn: where you can say<br>
<br>
#(1 2) destructureIn: [:x :y | x + 1]<br>
<br>
which lets me avoid loads of local variables.<br></blockquote><div><br></div><div>Yes, I use something similar a fair bit</div><div><br></div><div> [:a :b ... | ... ] valueWithArguments: tuple</div><div><br></div><div>
etc.</div><div><br></div><div>And the Selector>>value[:...] hacks are clever too:</div><div><br></div><div> (2 to: n) select: #even</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
frank<br>
<br>
[1] <a href="http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html" target="_blank">http://www.laputan.org/reflection/Foote-Johnson-Noble-ECOOP-2005.html</a><br>
[2] <a href="http://blog.jayfields.com/2010/07/clojure-destructuring.html" target="_blank">http://blog.jayfields.com/2010/07/clojure-destructuring.html</a><br>
[3] <a href="http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html" target="_blank">http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html</a><br>
<span class=""><font color="#888888"><br>
> --<br>
> best,<br>
> Eliot<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>