Is Self a Smalltalk? :) -- Best regards, Dennis Schetinin 2014-02-12 13:35 GMT+04:00 Frank Shearar <[hidden email]>:
|
In reply to this post by Frank Shearar-3
Of course Lisp came first, we must all be dealing with Lisp’s influences.
Guy On 12/02/2014, at 10:35 pm, Frank Shearar <[hidden email]> wrote: > On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote: >> >> On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]> 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.) > >> Oh and course the big one - do I like it? > > Why, yes I do! (To both!) > > frank > |
In reply to this post by timrowledge
Smalltalkers have diferent points of view about "what is" Smalltalk;
and in most cases it (the pov) change over time (sometimes without reflection about when/what/how changed). Smalltalk as a content (a set of virtual "objects") is not a good model because it do not consider time and the (side) effects of living creatures changing the objects. Smalltalk considered as an evolving content (e.g. contents where changes can't be predicted) face us to the problem that we cant say that smalltalk "is" what it content (nor what is "declared" to be there)... What is preserved in any smalltalk instance through time is the identity of the system.(***) We download/obtain "aSmalltalk" from anywhere and after the first seconds it change (using our hands) to become "my" smalltalk (*). The "super smalltalk" instance is an abstraction (it do NOT exist, and it is not related with life). Each individual smalltalk instance use one or more smalltalkers to change; the code and the contents (tools, frameworks, the VM, etc) can change using our hands/mind... what is preserved is the identity of the system (that includes people). It is frequent this days that smalltalkers "go out", and say: I changed, this... and this and it is NOT a smalltalk... (I am not a smalltalker anymore... or I have changed to become another kind of developer... or it is "my" invention/idea) IMHO it is part of the effects of feeling "outside the world" (that are required to start learning about smalltalk), and the convenience to be someone that show "something new"; in the world we live today it is accepted that changes are good (no matter what are the effects of the change, nor how it scales). In short, Smalltalk is what we do with something we started to change, preserving it/our identity. (it is matter of identity) We can start our smalltalker life downloading one or more smalltalk execution environments, and after some years we can be running on other smalltalk env., or over other VMs (e.g. a javascript VM like my case with S8, after +20 years using multiple smalltalk platforms, adn wasting time and resources waiting for better smalltalk VMs :-) on multiple devices... smalltalk in that case will be one system on multiple devices, on top of multiple O.S. and on diferent VMs (with or w/o bytecodes, on top of intermediate runtimes, and in mixed environments like using S8 running on top of js and .net VMs at the same time, in the same system with heterogeneous object models, or as android/ios apps, or in browser as U8 contribution (**) )... IMO any Smalltalk HAS a compiler for "smalltalk syntax", but the syntax defined at the time of Smalltalk-80 defines the experiences of smalltalkers of the '80s and not the experiences of MOST of the smalltalkers (the same feeling that when we realize that most of human beens are down the grass, and we are live instances of something that HAS changed) So.. we can relax and do NOT try to constrain "what smalltalk is". IMHO We can try to accept other POVs about smalltalk, and use others pov to try to join forces w/o trying to change someone, nor excluding from "smalltalk community"; that under my pov, the community is an abstraction.. an instrument for exclusion of some souls that do not trust in votations, or do not communicate what they are doing... we dont need that, we are free to change anything and we have been doing that for decades. cheers, Ale. (*) "my" as in "my God", "my love", "my son", "my smalltalk", it define that we are for the thing... (we do not own the thing, the idea/ideal own us, our resources and our life time) (**) cant resist to mention S8 and what we are doing to run our smalltalk systems on javascript execution engines, in an unique social development effort with smalltalk... refs. http://u8.smalltalking.net/browsecontributions.aspx http://u8.smalltalking.net/profile/aleReimondo/239/index.html (***) we have been reflecting about preservation of identity of smalltalk systems in Smalltalking for more than a decade and the effects of that reflections are observable today in most smalltalkers that has been related with latin smalltalk communities. The concept of identity, time, life and its effects on systems helped us to relax and let people think the way they want about informatics, and what "in-formation" is... :-) ----- Original Message ----- From: "Jecel Assumpcao Jr." <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Tuesday, February 11, 2014 10:02 PM Subject: [squeak-dev] what is smalltalk? (was: Smalltalk dialects and GSoC) > Any discussion of what is Smalltalk and what isn't can't get very far > without first clearly defining a few things. Are we assuming that > "Smalltalk" and "Smalltalk-80" are equivalent? Does the ANSI Smalltalk > standard play any role in the discussion? > > Even if we make our assumptions clear, there is still a lot of > subjectivity involved. Many people consider Scheme to be a different > language than Lisp, but its creators do not and the famous "Structure > and Interpretation of Computer Programs" course uses the name "Lisp" > exclusively except for one initial note saying that the Lisp they use is > Scheme. On the other hand, everybody can easily agree that Scheme is not > a Common Lisp. > > It seems silly to have a definition of "Smalltalk" that would exclude > Smalltalk-72 to Smalltalk-76, and yet Smalltalk-72 is more different > from what we have now than NewSpeak (which I would not call a > Smalltalk). So perhaps we should have such a definition. On the other > hand, at one point I got tired of people considering Self to be a > different language so I renamed my project from Self/R to Neo Smalltalk. > In the Self 4.0 "images" that included Mario Wolczko's patches you could > file in all of the GNU Smalltalk libraries and they would work > perfectly. > > -- Jecel > > > |
In reply to this post by Janko Mivšek
Janko, Thank you for sharing the details of your concern. It is better to deal with facts rather than hints and allusions, since the former is something the defendant and community can respond to and the latter can conjure the worst imagination and polarise both defendant and community. I can understand your need for hinting since it can be difficult to call out a leader in the community, and perhaps is why you've shouldered this burden since 2010. Unfortunately such burdens can sour our perspective on matters. As a reasonably independent observer (in Australia doing Smalltalk just 2 years by myself) looking at the facts you've presented, this seems to me more to a difference of opinion and perspective than a violation of ethics. Certainly your perspective as a GSoC Admin will be different from me observing from the outside, but I think that Stéphane as a representative of ESUG has some right to specify parameters for a project like GSoC running under their name. It just would have been better this was done more transparently/publicly, and also that the project parameters are publicly defined up front before the project begins, but then life doesn't always happen like the ideal - there always ends up gray areas that were not previously considered. I hope that having shared these details, even if community sentiment did not go the way you assumed, there is some sense of a burden has lifted. I particularly appreciate that you've stepped back from the GSoC Admin role you obviously care a lot about, to allow the project to proceed with someone outside the conflict. Personally I would be glad to see you involved again at a later time, though some bridge building may be needed. Stef, I hope that after some time, even though this was damaging to you, you might consider there were some honorable intentions that drove Janko's motivations over the last three years, even if these were poorly communicated. My kind regards to you both, -ben Janko Mivšek wrote: > Time therefore to expose that sad story from GSoC 2010. So that the > community can judge by themselves if my claims are insults or real. > > For the start, this was not a money matter but meddling into project > selection process. > > Here is the story: > > On GSoC 2010 Gilad Bracha proposed a Newspeak/Smalltalk Import/Export > Tool project idea [1]. After the idea was put on ideas list [2], > Stéphane Ducasse ordered my co-admin to remove Gilad's idea from the > list. Co-admin told that to me. I was shocked that someone can come to > such an idea to remove something even in the idea phase from the GSoC. > Of course I rejected such an order immediately. > > Even more, co-admin was at that time just starting the postgraduade > study under the Mr.Ducasse mentorship. You can imagine how he felt, like > between two fires. It is reasonable therefore to suspect that Mr.Duccase > uses his power as a mentor over postgraduate student to try to achieve > his goal. > > What was the motivation of Mr.Ducasse to made such a blatant act was not > quite clear to me. And is also not important. Important is that such > removal attempts are totally unacceptable. Only GSoC mentors have that > right by reviewing and voting on the projects to be finally selected for > stipendiums. > > In any case, this incident was a start of my thinking and working on > GSoC to be as transparent, neutral and independent as possible. > > Best regards > Janko > > [1] http://gsoc2010.esug.org/projects/newspeak-tool > [2] http://gsoc2010.esug.org/ideas > |
In reply to this post by Frank Shearar-3
On 12-02-2014, at 1:35 AM, Frank Shearar <[hidden email]> wrote: > [snip] > 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.) > I don’t know enough about Lisp to really comment. My impression is that it has message sending as an add-on and not the entire point. It’s something I might be wrong about. (Treasure that thought.) >> Oh and course the big one - do I like it? > > Why, yes I do! (To both!) No, no, no. ‘do I like it?’ refers to *me*, not the generic first person. ;-) tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim I haven't lost my mind; it's backed up on tape somewhere. |
In reply to this post by Ben Coman
Thanks, Ben. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS) |
In reply to this post by Guy
Guy Bloomfield wrote:
> Of course Lisp came first, we must all be dealing with Lisp's influences. Actually, the influence graph would be: Lisp ==> Smalltalk Smalltalk ==> Flavors (MIT Lisp) Smalltalk ==> Loops (Interlisp-D) Flavors ==> New Flavors Loops ==> CommonLoops New Flavors + CommonLoops ==> CLOS (Common Lisp Object System) Note that if we are talking about general language families (like you might say that Modula-2 and C belong to the Algol family) then I would place Smalltalk firmly in the Lisp family. -- Jecel |
In reply to this post by Dennis Schetinin
Dennis Schetinin asked:
> Is Self a Smalltalk? :) Yes. To quote Mario Wolczko, "Self is like Smalltalk, only more so." It seems that I have the only copy of his "Self includes: Smalltalk" paper online: http://www.merlintec.com/download/mario.pdf The pages are in the reverse order, which makes it nice to print on simple printers but a bit complicated to read on a screen. It is very important to notice that this is *not* like a Lisp or Prolog implemented on top of Squeak. A casual reading of this paper might give this impression, but it really is something different. Self is treated as a kernel Smalltalk which is then expanded into full GNU Smalltalk compatibility. There aren't two layers, but a single language. This is in contrast to PEP, which implemented Java by compiling it to Self bytecodes. That is like NewSpeak using the Squeak VM: > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.23.6906&rep=rep1&type=pdf Since this paper ("Towards a Universal Implementation Substrate for Object-Oriented Languages" by Mario Wolczko, Ole Agesen and David Ungar) talks about both projects it is easy to get the impression that they were the same kind of thing and that saying "Self is a Smalltalk" would be as silly as saying "Self is a Java". The details are important. -- Jecel |
In reply to this post by Frank Shearar-3
Hi Frank,
On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <[hidden email]> wrote:
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). And hence method combination is very different in CL to Smalltalk's simple super send. 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. Generic functions imply that not everything is an object. 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. 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.
best, Eliot
|
In reply to this post by Dennis Schetinin
Hi Jecel,
On Wed, Feb 12, 2014 at 11:52 AM, Jecel Assumpcao Jr. <[hidden email]> wrote: Dennis Schetinin asked: I have to quibble here. Newspeak isn't entirely compiled to Squeak bytecodes. Lexically bound and dynamic super sends require special run-time support. In the first implementation that took the form of escaping from bytecodes into a perform:-like invocation that was very slow. In the second implementation we added two bytecodes that find the effective receiver, one for a lexically-bound send, and one for a dynamic super send. But this is a security hole. In the third implementation we have a new bytecode set, which sits alongside Squeak's, and this contains absent receiver sends for lexically-bound and dynamic super sends. [and note, Newspeak, not NewSpeak]
Since this paper ("Towards a Universal Implementation Substrate for Yes, the details are important, but Self is an evolution of Smalltalk, just as Newspeak is. Java is /not/ an evolution of Smalltalk.
-- Jecel best, Eliot
|
In reply to this post by Eliot Miranda-2
On 12 February 2014 19:05, Eliot Miranda <[hidden email]> wrote:
> Hi Frank, > > > On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <[hidden email]> > wrote: >> >> On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote: >> > >> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]> >> > 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 |
Hi Frank,
On Wed, Feb 12, 2014 at 12:58 PM, Frank Shearar <[hidden email]> wrote:
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.
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 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, 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 frank best, Eliot
|
On 12.02.2014, at 23:49, Eliot Miranda <[hidden email]> wrote:
> Hi Frank, > > > On Wed, Feb 12, 2014 at 12:58 PM, Frank Shearar <[hidden email]> wrote: > On 12 February 2014 19:05, Eliot Miranda <[hidden email]> wrote: > > Hi Frank, > > > > > > On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <[hidden email]> > > wrote: > >> > >> On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote: > >> > > >> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]> > >> > 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. > > > 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. > > > 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 { roots . accessors . assignments } := #( 1 2 3 ) But, while there are traces of support for that, I seems largely ripped out… (to my sad-face-ing) > > But as an implementor I'm not sure the complexity pulls its weight. The closure hack works well enough. > > > Dan Ingalls, IIRC, had an extension or something where you could write > "a, b := self aMethodReturningaPair". see above. > 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 > > 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 signature.asc (1K) Download Attachment |
On 13.02.2014, at 00:05, Tobias Pape <[hidden email]> wrote:
> On 12.02.2014, at 23:49, Eliot Miranda <[hidden email]> wrote: > >> It's nicer to be able to write >> >> roots, accessors, assignments := >> self accessorsAndAssignmentsForMethod: method >> actuals: {} >> depth: 0 >> interpreterClass: interpreterClass > > There used to be a syntax like this: > > { roots . accessors . assignments } := #( 1 2 3 ) > > But, while there are traces of support for that, I seems largely ripped out… (to my sad-face-ing) > >>> 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. For (1) we do need new syntax (or revive old syntax). For (2) we have #in: for a single value and #valueWithArguments: for multiple values, although the order is counter-intuitive. So maybe we could add an #allIn: (or another selector if there is precedence in other dialects)? For the multiple assignment syntax I don't remember what the actual problem was. Decompiler support maybe? - Bert - smime.p7s (5K) Download Attachment |
In reply to this post by Eliot Miranda-2
On 12 February 2014 22:49, Eliot Miranda <[hidden email]> wrote:
> Hi Frank, > > > On Wed, Feb 12, 2014 at 12:58 PM, Frank Shearar <[hidden email]> > wrote: >> >> On 12 February 2014 19:05, Eliot Miranda <[hidden email]> wrote: >> > Hi Frank, >> > >> > >> > On Wed, Feb 12, 2014 at 1:35 AM, Frank Shearar <[hidden email]> >> > wrote: >> >> >> >> On 12 February 2014 00:22, tim Rowledge <[hidden email]> wrote: >> >> > >> >> > On 11-02-2014, at 5:02 PM, Jecel Assumpcao Jr. <[hidden email]> >> >> > 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 |
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:
> I have to quibble here. Newspeak isn't entirely compiled to Squeak bytecodes. > Lexically bound and dynamic super sends require special run-time support. In > the first implementation that took the form of escaping from bytecodes into a > perform:-like invocation that was very slow. In the second implementation we > added two bytecodes that find the effective receiver, one for a lexically-bound > send, and one for a dynamic super send. But this is a security hole. In the third > implementation we have a new bytecode set, which sits alongside Squeak's, > and this contains absent receiver sends for lexically-bound and dynamic super > sends. [and note, Newspeak, not NewSpeak] Thanks for this history - I am *very* interested in this kind of detail. Prior to 2009 I worked on several different VMs and while I am happy with the results I achieved I came to the conclusion that they didn't matter too much. I had come up with a simple patch to the Squeak VM that would allow it to run the Slate programming language. I also noticed that Self could run on top of the Squeak VM either with no changes or a little bit better with changes similar to what you just described. So I was convinced by discussions with a group of people that "perfect is the enemy of the good" (Voltaire) and that any extra elegance in my own designs was not worth not working with others (by sharing the Squeak VM). > Yes, the details are important, but Self is an evolution of Smalltalk, just as > Newspeak is. Java is /not/ an evolution of Smalltalk. Indeed, but the two issues are independent. When I implemented tinySelf 1 on top of Self the two languages were almost identical and yet the implementation technique was of a completely independent layer (like the Lisp or Prolog on top of Squeak examples I gave). So the three alterantives are: 1) extend a language, like Objective-C or C++ extend C 2) add a layer, like Ruby is implemented in C 3) target an existing VM, like Clojure on the Java VM In the first case the languages have to be related, but in the other two we can't say anything. I only took a very superficial look at Newspeak and my impression was that it borrowed as much from Beta (or perhaps E?) as from Smalltalk. Obviously the opinion of the people actually working on the language, such as yourself, is more relevant. -- Jecel |
In reply to this post by Eliot Miranda-2
> Indeed, but the two issues are independent. When I implemented tinySelf
> 1 on top of Self the two languages were almost identical and yet the > implementation technique was of a completely independent layer (like the > Lisp or Prolog on top of Squeak examples I gave). Just for the record, if the Lisp you're refering to is LispKit (http://www.zogotounga.net/comp/squeak/lispkit.htm), then it is an extension of Squeak, not an extra layer. Stef |
In reply to this post by Frank Shearar-3
On Thu, Feb 13, 2014 at 5:39 AM, Frank Shearar <[hidden email]> wrote:
--
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.
"Yes, Common Lisp has a bit of a mess here." ;-) I find it odd that Common Lisp 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.
Yes, again I accept it because of its minimality.
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 best, Eliot
|
In reply to this post by Stéphane Rollandin
Stéphane Rollandin wrote:
> Just for the record, if the Lisp you're refering to is LispKit > (http://www.zogotounga.net/comp/squeak/lispkit.htm), then it is an > extension of Squeak, not an extra layer. Thanks for the information! I was thinking of an older project, available at: http://www.zephyr.dti.ne.jp/~nishis/smalltalk/Squeak/goodies/ I would say that the fact that LispKit was implemented as an extension shows that the two languages are related. -- Jecel |
In reply to this post by Stéphane Rollandin
> I would say that the fact that LispKit was implemented as an extension
> shows that the two languages are related. Definitely. Stef |
Free forum by Nabble | Edit this page |