Self-interest September 2011

self-interest@lists.selflanguage.org

17 participants
32 discussions

Re: [self-interest] Changing prototype chain as state machine
by David Goehrig 30 Sep '11

30 Sep '11

Jecel, Do you still have the multi-map implementation? I would love to see what you did. Map management by defining a graph that can be traversed between multiple maps would be a great tool for not only code analysis but also designing software. A graphical editor would allow one to edit state diagrams directly. -=-=- dave(a)nexttolast.com -=-=- On Sep 30, 2011, at 1:50 PM, "Jecel Assumpcao Jr." <jecel(a)merlintec.com> wrote: > David Ungar wrote: > > > Thanks, guys. I'll read the Ego paper. > > I only skimmed through it, but it seems to be another case of "Self as I > imagine it from reading the papers" instead of "Self as it really is > from using it". The idea of dynamic inheritance using data parent slots > is not mentioned at all, but the focus is on using _AddSlots: and > friends to change objects during an application's execution. It > certainly would work, but it would also defeat all the optimizations > built into the VM. > > This style of programming is used a bit in Javascript and the people, > like Lars, who have recently done high performance implementations of > that language have had to deal with this problem. So there is not reason > why a new implementation of Self couldn't handle lots of _AddSlots:, but > it hasn't been the focus so far. > > In fact, that is also true for dynamic inheritance. If you use > assignable parent slots then you will take a huge hit in terms of > performance. When Urs Hölzle was asking for application in Self to test > the compilers he had created for 3.0 (and which we still use today) I > sent him my CMOS simulator but it was useless for him exactly because I > had used dynamic inheritance. In my case it was just a nasty hack to > make the Self REPL work as a nice command line for my simulator. The one > example I know of that does use assignable parents as intended is the > tree objects in collections. > > Given how dynamic inheritance is actually used (to switch among a small > number of constant objects rather than point to arbitrary ones) I came > up with an implementation were an object with a dynamic parent would > have several maps, one for each parent (up to five, for example). When > you assign to the parent slot, you switch maps as a side effect. > > > A while back I gave a keynote at OOPSLA on the role of paradox in language > > design.In general, I believe that better type systems are worse--depending > > on the context. One loses the power of ambiguity. However, if you are > > sending code to Mars, it's a good tradeoff. Anyway, I'll have to read the paper. > > I watched that talk - you had some static typing people grinding their > teeth :-) Back in 2003 Java was at its zenith and stuff like Ruby and > Javascript were still being ignored. By a coincidence, I had started > using "sending code to Mars" in the mid 1990s as an example were > traditional software engineering practices would be a good idea in > contrast to other applications with GUIs where you might get better > results through exploratory programming (we didn't have the term "agile > programming" yet, though we already had some of the methods like Scrum). > > -- Jecel > >

2 1

Re: [self-interest] Changing prototype chain as state machine
by David Goehrig 30 Sep '11

30 Sep '11

On Sep 30, 2011, at 1:50 PM, "Jecel Assumpcao Jr." <jecel(a)merlintec.com> wrote: > hich we still use today) I > Given how dynamic inheritance is actually used (to switch among a small > number of constant objects rather than point to arbitrary ones) I came > up with an implementation were an object with a dynamic parent would > have several maps, one for each parent (up to five, for example). When > you assign to the parent slot, you switch maps as a side effect. > > > A while back I gave a keynote at OOPSLA on the role of paradox in language > > design.In general, I believe that better type systems are worse--depending > > on the context. One loses the power of ambiguity. However, if you are > > sending code to Mars, it's a good tradeoff. Anyway, I'll have to read the paper. > > I watched that talk - you had some static typing people grinding their > teeth :-) Back in 2003 Java was at its zenith and stuff like Ruby and > Javascript were still being ignored. By a coincidence, I had started > using "sending code to Mars" in the mid 1990s as an example were > traditional software engineering practices would be a good idea in > contrast to other applications with GUIs where you might get better > results through exploratory programming (we didn't have the term "agile > programming" yet, though we already had some of the methods like Scrum). > > -- Jecel > >

1 0

Re: [self-interest] Changing prototype chain as state machine
by David Goehrig 30 Sep '11

30 Sep '11

The Plaid paper lays out the same concept with stricter typing. I hadn't seen Ego before. Thanks! -=-=- dave(a)nexttolast.com -=-=- On Sep 29, 2011, at 3:47 PM, "Welch, Ronald P (US SSA)" <Ronald.P.Welch(a)BAESYSTEMS.com> wrote: > Dave, > > > This reminds me of a derivation of Self called "Ego" that makes > steps toward adding type checking to Self. If you haven't > already seen it, there is paper describing Ego here: > > http://www.cs.cmu.edu/~aldrich/papers/ > > Ron > ----------=-=-=-=-=-=-=-=-========oOo========-=-=-=-=-=-=-=-=---------- > mailto:Ronald.P.Welch@baesystems.com > ----------=-=-=-=-=-=-=-=-===================-=-=-=-=-=-=-=-=---------- > > > > > On Sep 27, 2011, at 8:28 PM, David Goehrig wrote: > >> >> In one of the Self papers it states that assignable parent slots can be useful. And then it is largely an ignored subject from then on. >> >> I've been ressurrecting this idea for a web framework which models core finite state machines by exploiting assignable parent slots to only expose methods sensible for that state. >> >> eg. A response object has no header:Value: after the headers have already been sent, and a closed socket has no read or write: or close methods, but does have an open: >> >> When I'm building these objects there is some default behavior that needs surpressing, specifically firing up the debugger when an unknown message send is encountered. This is heavily inspired by Randy's ARK unknown methods fall through. >> >> Where this has become critical is building large scale distributed applications with transparent proxies forwarding messages. Which may hit an object multiple times due to resend logic. >> >> Do any of the wise ones on the list know of any applications using these approaches? >> >> If not, why? >> >> -=-=- dave(a)nexttolast.com -=-=- >> > >

3 3

Re: [self-interest] Changing prototype chain as state machine
by ungar＠mac.com 30 Sep '11

30 Sep '11

Thanks, Jecel. I did look very quickly at the paper, and I completely agree with all of your comments. We'll just have to make sure that conferences provide soft foods for the static typing people;-) Thanks for watching that talk! - David On Sep 30, 2011, at 10:50 AM, Jecel Assumpcao Jr. wrote: > David Ungar wrote: > > > Thanks, guys. I'll read the Ego paper. > > I only skimmed through it, but it seems to be another case of "Self as I > imagine it from reading the papers" instead of "Self as it really is > from using it". The idea of dynamic inheritance using data parent slots > is not mentioned at all, but the focus is on using _AddSlots: and > friends to change objects during an application's execution. It > certainly would work, but it would also defeat all the optimizations > built into the VM. > > This style of programming is used a bit in Javascript and the people, > like Lars, who have recently done high performance implementations of > that language have had to deal with this problem. So there is not reason > why a new implementation of Self couldn't handle lots of _AddSlots:, but > it hasn't been the focus so far. > > In fact, that is also true for dynamic inheritance. If you use > assignable parent slots then you will take a huge hit in terms of > performance. When Urs Hölzle was asking for application in Self to test > the compilers he had created for 3.0 (and which we still use today) I > sent him my CMOS simulator but it was useless for him exactly because I > had used dynamic inheritance. In my case it was just a nasty hack to > make the Self REPL work as a nice command line for my simulator. The one > example I know of that does use assignable parents as intended is the > tree objects in collections. > > Given how dynamic inheritance is actually used (to switch among a small > number of constant objects rather than point to arbitrary ones) I came > up with an implementation were an object with a dynamic parent would > have several maps, one for each parent (up to five, for example). When > you assign to the parent slot, you switch maps as a side effect. > > > A while back I gave a keynote at OOPSLA on the role of paradox in language > > design.In general, I believe that better type systems are worse--depending > > on the context. One loses the power of ambiguity. However, if you are > > sending code to Mars, it's a good tradeoff. Anyway, I'll have to read the paper. > > I watched that talk - you had some static typing people grinding their > teeth :-) Back in 2003 Java was at its zenith and stuff like Ruby and > Javascript were still being ignored. By a coincidence, I had started > using "sending code to Mars" in the mid 1990s as an example were > traditional software engineering practices would be a good idea in > contrast to other applications with GUIs where you might get better > results through exploratory programming (we didn't have the term "agile > programming" yet, though we already had some of the methods like Scrum). > > -- Jecel > >

1 0

Changing prototype chain as state machine
by David Goehrig 29 Sep '11

29 Sep '11

In one of the Self papers it states that assignable parent slots can be useful. And then it is largely an ignored subject from then on. I've been ressurrecting this idea for a web framework which models core finite state machines by exploiting assignable parent slots to only expose methods sensible for that state. eg. A response object has no header:Value: after the headers have already been sent, and a closed socket has no read or write: or close methods, but does have an open: When I'm building these objects there is some default behavior that needs surpressing, specifically firing up the debugger when an unknown message send is encountered. This is heavily inspired by Randy's ARK unknown methods fall through. Where this has become critical is building large scale distributed applications with transparent proxies forwarding messages. Which may hit an object multiple times due to resend logic. Do any of the wise ones on the list know of any applications using these approaches? If not, why? -=-=- dave(a)nexttolast.com -=-=-

2 1

Re: A paper on Images.
by Mario Wolczko 28 Sep '11

28 Sep '11

Thanks! I was inspired by the implementors' accounts in the Green Book. Also, I spent that summer mostly in a windowless, frigid machine room. Aside from listening to music on a walkman, there wasn't much else to keep me amused during hacking lulls. No surfing the web, back then!

2 1

Re: A paper on Images.
by Mario Wolczko 28 Sep '11

28 Sep '11

Just for reference, I recently scanned the documentation that accompanied the first Xerox public release of Smalltalk-80 V2 and put it online. It's available here: http://www.wolczko.com/st80/ (link at the end of the page). -Mario

2 1

Re: [self-interest] Paper on Traits.
by ungar＠mac.com 28 Sep '11

28 Sep '11

You are welcome, and quite so! On Sep 27, 2011, at 11:12 AM, Jecel Assumpcao Jr. wrote: > Thanks David, Randy and James (I knew about the Star but had forgotten > about this detail) for clearing up the history of the term. I don't know > why I wrote my comment in the form of explaining the origin of it since > I didn't know it and actually thought it unlikely that PARC people who > worked with Smalltalk-80 would be familiar with Adele's Smalltalk-72 era > efforts. And I had also talked with the Squeak Traits people at the same > conference David did and knew that they had borrowed the term from Self. > > What I had wanted to point out was that the Self, Star and Adele use of > "traits" are similar while the Squeak/Pharo and derived version of > traits are similar to Self and Strongtalk mixins. So reading the papers > about one version to better understand the other version might not be a > good idea. > > -- Jecel > >

1 0

Re: [self-interest] A paper on Images.
by ungar＠mac.com 27 Sep '11

27 Sep '11

Thank you for your scholarship, Jecel! - David On Sep 27, 2011, at 12:03 PM, Jecel Assumpcao Jr. wrote: > Jan, > > > Sorry, I'm currently doing a lot of learning ^^ > > That is always a good thing. > > > Does anybody know a paper on the basics of Smalltalk and Self > > like Images? (One for the Self image would of course be best :D) > > The problem is that they are essentially a memory dump with a header. > Being so simple, you couldn't get a paper about them published in any > conference. There are many interesting papers about going beyond the > image, however, and I will mention a few below. > > David suggested the "blue book": > > http://stephane.ducasse.free.fr/FreeBooks/BlueBook/ > > Chapters 26 to 30 are the ones that are interesting to implementors and > were available as html pages for many years before the whole book. While > that site is gone, you can still read it at > > > http://web.archive.org/web/20070927190722/http://users.ipa.net/~dwighth/sma… > > I thought I would see the code for reading or writting the image in the > part about primitives or about the object memory, but there doesn't seem > to be anything. > > In the "green book" > (http://stephane.ducasse.free.fr/FreeBooks/BitsOfHistory/) the HP > chapter (6) describes the format they adopted for their images and how > it is different from the standard format. > > Here are some details about the format of Squeak images: > > http://potatovm.blogspot.com/2008/08/image-loading-in-potato.html > > One of the papers about going beyond the image is chapter 14 of the > green book: "LOOM - Large Object Oriented Memory for Smalltalk-80 > Systems" by Ted Haehler and Gleen Krasner (pages 251 to 271). You can > also find an OOPSLA paper on LOOM. > > http://dl.acm.org/citation.cfm?id=94112 > > "Annotating Objects for Transport to Other Worlds" by David Ungar shows > the issues that are not solved by images (or "snapshots", in Self): > > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66.4102&rep=rep1&t… > > You might find the predecessor for LOOM, OOZE, still has some > interesting ideas. Here is the 1981 Byte magazine article: > > http://www-cs-students.stanford.edu/~eswierk/misc/kaehler81/ > > Releated to images, Squeak's ImageSegments are meant to save part of the > memory separately from the rest. > > http://wiki.squeak.org/squeak/2316 > > Note that there is a lot of research effort to replace these with more > general solutions like Fuel, SRP or Stomp. Here is a paper on Fuel: > > http://rmod.lille.inria.fr/archives/workshops/Dia11a-IWST11-Fuel.pdf > > -- Jecel > >

1 0

Re: [self-interest] A paper on Images.
by Jan-Paul Bultmann 27 Sep '11

27 Sep '11

wow thats a lot of material, thanks a lot ! :D I'll look into them ^^ Cheers Jan On Sep 27, 2011, at 21:03 PM, Jecel Assumpcao Jr. wrote: > Jan, > > > Sorry, I'm currently doing a lot of learning ^^ > > That is always a good thing. > > > Does anybody know a paper on the basics of Smalltalk and Self > > like Images? (One for the Self image would of course be best :D) > > The problem is that they are essentially a memory dump with a header. > Being so simple, you couldn't get a paper about them published in any > conference. There are many interesting papers about going beyond the > image, however, and I will mention a few below. > > David suggested the "blue book": > > http://stephane.ducasse.free.fr/FreeBooks/BlueBook/ > > Chapters 26 to 30 are the ones that are interesting to implementors and > were available as html pages for many years before the whole book. While > that site is gone, you can still read it at > > > http://web.archive.org/web/20070927190722/http://users.ipa.net/~dwighth/sma… > > I thought I would see the code for reading or writting the image in the > part about primitives or about the object memory, but there doesn't seem > to be anything. > > In the "green book" > (http://stephane.ducasse.free.fr/FreeBooks/BitsOfHistory/) the HP > chapter (6) describes the format they adopted for their images and how > it is different from the standard format. > > Here are some details about the format of Squeak images: > > http://potatovm.blogspot.com/2008/08/image-loading-in-potato.html > > One of the papers about going beyond the image is chapter 14 of the > green book: "LOOM - Large Object Oriented Memory for Smalltalk-80 > Systems" by Ted Haehler and Gleen Krasner (pages 251 to 271). You can > also find an OOPSLA paper on LOOM. > > http://dl.acm.org/citation.cfm?id=94112 > > "Annotating Objects for Transport to Other Worlds" by David Ungar shows > the issues that are not solved by images (or "snapshots", in Self): > > > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66.4102&rep=rep1&t… > > You might find the predecessor for LOOM, OOZE, still has some > interesting ideas. Here is the 1981 Byte magazine article: > > http://www-cs-students.stanford.edu/~eswierk/misc/kaehler81/ > > Releated to images, Squeak's ImageSegments are meant to save part of the > memory separately from the rest. > > http://wiki.squeak.org/squeak/2316 > > Note that there is a lot of research effort to replace these with more > general solutions like Fuel, SRP or Stomp. Here is a paper on Fuel: > > http://rmod.lille.inria.fr/archives/workshops/Dia11a-IWST11-Fuel.pdf > > -- Jecel > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest September 2011