<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Feb 13, 2014 at 5:39 AM, 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 22:49, 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 12:58 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
> wrote:<br>
>><br>
>> 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<br>
>> >> >> 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<br>
>> >> > what is<br>
>> >> > written by people that consider themselves to be Smalltalkers.<br>
>> >> ><br>
>> >> > Is everything an object? Do objects have classes? Do objects<br>
>> >> > 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<br>
>> >> > 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<br>
>> > 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>
>> 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>
>><br>
>> > And<br>
>> > hence method combination is very different in CL to Smalltalk's simple<br>
>> > super<br>
>> > send.<br>
>><br>
>> 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>
>><br>
>> > While Newspeak extends Smalltalk's send semantics with<br>
>> > lexically-scoped sends, the extensions are still very much like<br>
>> > Smalltalk<br>
>> > message sends (polymorphic, dispatching on a single receiver). The<br>
>> > other<br>
>> > major difference is encapsulation. In CLOS there isn't any.<br>
>><br>
>> 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>
>><br>
>> > Generic<br>
>> > functions imply that not everything is an object.<br>
>><br>
>> 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>
><br>
><br>
> No, I mean that generic functions can discriminate on anything, including<br>
> singletons, s-exprs, right? So they're more general than message sending<br>
> and allow one to access the Lisp types CLOS is built from.<br>
<br>
</div></div>They can, yes. But singletons and sexprs are still just objects. So<br>
for instance, discriminating on a particular object is still just a<br>
message send (well, in my head it is), albeit the definition of the<br>
method isn't attached to a class.<br></blockquote><div><br></div><div>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. </div>
<div> </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"><br>
>> > 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>
>> 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>
><br>
><br>
> I'm not sure I'd call CLOS's approach messy. It /is/ very different.<br>
> Smalltalk's designers put a lot of effort into designing a simple but<br>
> powerful syntax (including for literals). And in doing that they avoided<br>
> some of CLOS's flexibility.<br>
<br>
</div>I didn't say CLOS's approach messy.</blockquote><div><br></div><div>"<span style="color:rgb(80,0,80)">Yes, Common Lisp has a bit of a mess here." ;-)</span></div><div> </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">
I find it odd that Common Lisp<br>
allows both keyword args and optional args, when keyword args are<br>
inherently optional (in Common Lisp, that is). Plus you don't have to<br>
argument-count if you just have keywords (in addition to the normal<br>
parameters).<br>
<br>
I think that the before/after/around method combinations to be very neat.<br></blockquote><div><br></div><div>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.</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"><br>
>> > A<br>
>> > final significant facility is multiple return values. Smalltalk has a<br>
>> > neat<br>
>> > hack (providing a block to receive the results), but that's not as<br>
>> > convenient.<br>
>><br>
>> The hack - do you mean 1 in: [:x | x + 1] ?<br>
><br>
><br>
> I mean this idiom:<br>
><br>
> self accessorsAndAssignmentsForMethod: method<br>
> actuals: {}<br>
> depth: 0<br>
> interpreterClass: interpreterClass<br>
> into: [:theRoots :theAccessors :theAssignments|<br>
> roots := theRoots.<br>
> accessors := theAccessors.<br>
> assignments := theAssignments].<br>
><br>
> It's nicer to be able to write<br>
><br>
> roots, accessors, assignments :=<br>
> self accessorsAndAssignmentsForMethod: method<br>
> actuals: {}<br>
> depth: 0<br>
> interpreterClass: interpreterClass<br>
><br>
> But as an implementor I'm not sure the complexity pulls its weight. The<br>
> closure hack works well enough.<br>
<br>
</div>Yes, this is the hack I meant. And I agree re the closure hack: it<br>
looks a lot like a let binding, too. (It was #into: I was thinking of,<br>
not #in:, obviously) I suppose the only thing I don't particularly<br>
like is that the value comes before the variable, so instead of<br>
<br>
(let [f 1]<br>
;Clojure stuff)<br>
<br>
it's<br>
<br>
1 into: [:f |<br>
"Smalltalk stuff"].<br></blockquote><div><br></div><div>Yes, again I accept it because of its minimality. </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">>> 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>
><br>
><br>
> Yes, I use something similar a fair bit<br>
><br>
> [:a :b ... | ... ] valueWithArguments: tuple<br>
><br>
> etc.<br>
><br>
> And the Selector>>value[:...] hacks are clever too:<br>
><br>
> (2 to: n) select: #even<br>
<br>
</div>Don't say that to Gilad :) "Inherently reflective" (and therefore<br>
problematic from a stratification point of view) was how he described<br>
them last time I said that I liked them. I think I did at one point<br>
understand why he said that... and I should have written it down.<br>
<a href="https://groups.google.com/forum/#!topic/newspeaklanguage/m2PO5RSQwFk" target="_blank">https://groups.google.com/forum/#!topic/newspeaklanguage/m2PO5RSQwFk</a><br>
has the conversation.<br></blockquote><div><br></div><div>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.</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"><span class=""><font color="#888888">frank<br>
</font></span><div class=""><div class="h5"><br>
>> 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]<br>
>> <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></div></div></blockquote></div>
-- <br>best,<div>Eliot</div>
</div></div>