Self-interest August 2005

self-interest@lists.selflanguage.org

5 participants
9 discussions

Re: [self-interest] Re: Self for Squeak
by David P Harris 31 Aug '05

31 Aug '05

Jecel Assumpcao Jr wrote: >David P Harris wrote on Wed, 31 Aug 2005 09:50:26 -0700 > > >>Hey, nice! I am confused re the use of [].... as in: >> >>( | >>parent* = [( | >>b = [4]. >>sum = (^ a+b). >>ifTrue: b1 ifFalse: b2 = ( ^ b1 value ) | )]. >>a = [3]. >>| ) >> >>Are they just syntactical? >> >> > >It took me a little while to figure them out too even though one of the >presentations explains them. The idea is that whatever is inside the >[...] gets compiled, evaluated and then the result is what is used in >the main compiled code. The reason we don't need this in Self is because >there is a magical rule saying "slot initialization expressions are >evaluated in the context of the lobby instead of the object being >compiled". This has no effect on the syntax but changes the semantics >significantly, though in a way that is intuitive enough that we don't >even notice it. > > Umm, thanks for mentioning this, as I had not know/had forgotten about the magical rule! >The advantage of an explicit mechanism instead of a magical rule is that >you get more flexibility. In Agora you use ' in front of a message name >to have it evaluated at compile time. Normal Forth also uses [...] to >switch to "interpret mode" and back while ColorForth uses different >colors (green compiles, yellow interprets). > > Yes, I am familiar with the Forth use, nice. Seems that this plus Tweak and/or reformed Morphic will make a very nice system. David

1 0

Re: [self-interest] Re: Self for Squeak
by David P Harris 31 Aug '05

31 Aug '05

Hi JEcel and Pavel-- Hey, nice! I am confused re the use of [].... as in: ( | parent* = [( | b = [4]. sum = (^ a+b). ifTrue: b1 ifFalse: b2 = ( ^ b1 value ) | )]. a = [3]. | ) Are they just syntactical? David Jecel Assumpcao Jr wrote: >Pavel, > > > >>you may be interested in my experimental project named Marvin. >> >>http://www.comtalk.net/Squeak/95 >> >> > >Yes, I did find it very interesting indeed. I hope you don't mind me >sending a copy of this to the Self list so that other people who might >be interested can learn about your project. Perhaps it would be a good >idea to announce it in the Squeak list too. > > > >>It's an attempt to create a Self dialect in Squeak which is compiled >>directly to the native bytecodes of Squeak and uses some little >>extensions of virtual machine like delegation support etc. >> >> > >There were other projects that added a bytecode or two to support this >kind of thing. It would be nice if this could be done in a fully >compatible way so that all future VMs could support it even for people >not interested in using it. The original "blue book" instruction set had >a few spare opcodes but I would have to check to see if Squeak didn't >use them all. > > > >>You are experienced Self programmer (unlike me) and you may see some >>problematic aspects of my concept of Squeak and Self integration which I >>haven't perceived. Your comments are welcome. >> >> > >It looks great. I only didn't understand why you had to use a non local >return in the ifTrue:ifFalse: definition in your examples. > >The use of [...] to explicitly control compile-time evaluation is a very >good idea and something I had borrowed from Forth for a language I >desiged a while ago. Agora has something similar. > >Earlier versions of Self were more similar to Marvin in some aspects. >They had characters as different objects from strings, for example. And >the slot lookup was closer to your depth first strategy. There were no >annotations either. > >I am not sure why you feel you need to add primitives in future versions >since you seem to have full access to Squeak. While I find the Self >syntax for primitives much nicer than the old Smalltalk one it seems a >little odd that while they look exactly like message sends they are >really subroutine calls since they ignore the receiver type. Something a >little less global would be nicer. > >-- Jecel > > > >Yahoo! Groups Links > > > > > > > > > >

2 1

Re: Self for Squeak
by Jecel Assumpcao Jr 31 Aug '05

31 Aug '05

Pavel, > you may be interested in my experimental project named Marvin. > > http://www.comtalk.net/Squeak/95 Yes, I did find it very interesting indeed. I hope you don't mind me sending a copy of this to the Self list so that other people who might be interested can learn about your project. Perhaps it would be a good idea to announce it in the Squeak list too. > It's an attempt to create a Self dialect in Squeak which is compiled > directly to the native bytecodes of Squeak and uses some little > extensions of virtual machine like delegation support etc. There were other projects that added a bytecode or two to support this kind of thing. It would be nice if this could be done in a fully compatible way so that all future VMs could support it even for people not interested in using it. The original "blue book" instruction set had a few spare opcodes but I would have to check to see if Squeak didn't use them all. > You are experienced Self programmer (unlike me) and you may see some > problematic aspects of my concept of Squeak and Self integration which I > haven't perceived. Your comments are welcome. It looks great. I only didn't understand why you had to use a non local return in the ifTrue:ifFalse: definition in your examples. The use of [...] to explicitly control compile-time evaluation is a very good idea and something I had borrowed from Forth for a language I desiged a while ago. Agora has something similar. Earlier versions of Self were more similar to Marvin in some aspects. They had characters as different objects from strings, for example. And the slot lookup was closer to your depth first strategy. There were no annotations either. I am not sure why you feel you need to add primitives in future versions since you seem to have full access to Squeak. While I find the Self syntax for primitives much nicer than the old Smalltalk one it seems a little odd that while they look exactly like message sends they are really subroutine calls since they ignore the receiver type. Something a little less global would be nicer. -- Jecel

1 0

attack of the clones
by jeceljr 25 Aug '05

25 Aug '05

Two interesting papers were mentioned today in the Smalltalk blogs (as seen in http://planet.smalltalk.org/): "Attack of the Clones" by James Noble and Brian Foote http://crpit.com/confpapers/CRPITV13Noble.pdf KoalaPLoP 2002 This shows the implementation of a number of Design Patterns in Self and manages to use dynamic inheritance for most of them. It includes a quick introduction to Self at the end. It is pretty funny and goes into details about a subject that has been discussed a few times on this list. One little thing is that the textual notation for Self, while the best choice for a paper and how we used it the first few years, isn't what Self is like to me having used the Self 4 GUI for the past ten years. In fact, that was how I had always pictured Self given the illustrations in the original paper. But given that one of the authors went in a different direction (Tarraingim is mentioned) the text bias is very understandable. Another paper is: "Language Constructs for Context-oriented Programming: An Overview of ContextL" by Pascal Costanza and Robert Hirschfeld http://p-cos.net/documents/contextl-overview.pdf Mentions Self, Us, Slate, Squeak and others while showing how to use subjective programming to implement multiple graphical views for objects. The footnote in the first page saying that Morphic has a problem with this is a little odd since that was one of the explicit goals of Morphic's design (no object should appear twice on the screen). -- Jecel

1 0

Compiling Self for Windows
by Gordon Cichon 20 Aug '05

20 Aug '05

Hi all, has anyone recently compiled Self for Windows? gcc 2.x seems to be no longer available at Cygwin. What about gcc 3? Apple is using gcc 3 for their code, isn't it? Would it be possible to compile Self with gcc 3? Has anyone tried yet? Best Regards Gordon ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

2 1

Re: mirrors (was: [self-interest] Adding method slots dynamically)
by jbgarcia＠uvigo.es 18 Aug '05

18 Aug '05

Hi, Jecel ! > > I've browsed the article and I've also read your answer. Though there > isn't > > anything wrong in Mirrors for me, I am not totally convinced about them. > > I have adopted a different solution for Neo Smalltalk, so I can > certainly understand that no everybody likes this solution. Could please explain your approach ? Or just paste some links ... > In Self you can have objects like > > (| count <- 1. inc = (count: count + 1) |) > > which does not inherit from some global "Object". In fact, it is a good > idea to use such objects whenever possible and only make them inherit > from "traits oddball" or "traits clonable" when they really need it to > do their job. This is the "principal of least authority" from the > security guys applied to object design. Well, yes, that's an interesting point. Salud ! Baltasar --oOo-----------------------------------------------------------------oOo-- Servicio de acceso ó correo electrónico vía web da Universidade de Vigo Servicio de acceso al correo electrónico vía web de la Universidad de Vigo Servicios Informáticos [ http://si.uvigo.es ] Universidade de Vigo [ http://www.uvigo.es ] URL: https://correoweb.uvigo.es

2 1

Re: mirrors (was: [self-interest] Adding method slots dynamically)
by Toby Ovod-Everett 18 Aug '05

18 Aug '05

On Wed, Aug 17, 2005 at 12:43:59PM -0300, Jecel Assumpcao Jr wrote: > Two advantages of the "copying is domain behavior" design used in Self > are that this is a very frequent operation so making it more lightweight > will improve performance and that having each object control this allows > the separation of "oddball" objects from "clonable" ones. In addition, by putting copying in the domain, one makes it easier to override the copying behavior. It is rare that an object designer would want to override the behavior of addSlots, for instance. It is not that rare that a designer would want to override the behavior of clone, on the other hand. Yes, if one puts clone in the mirror, one can still override the behavior of clone by overriding the behavior of reflect so that it returns an modified mirror that overrides clone on it's behalf, but that is a convoluted approach to implementing a common design pattern. The most common reason to override clone is a need to retain a count or a list of every object of a given "class". --Toby Ovod-Everett

2 1

Re: [self-interest] Re: Adding method slots dynamically
by jbgarcia＠uvigo.es 18 Aug '05

18 Aug '05

Hi, Jecel ! Thank you for your answer. > > What's the role of the mirror, here ? Is it related to preformance ? > > It isn't a performance issue at all, but rather a matter of good object > oriented design. The paper I mentioned last month goes into details > about why mirrors are a good idea (http://bracha.org/mirrors.pdf) but > here is a short answer: I've browsed the article and I've also read your answer. Though there isn't anything wrong in Mirrors for me, I am not totally convinced about them. If you don't have mirrors, then the functionalty related to reflection (i.e. the set of methods which actually add methods or attributes, etc.) will be in the "Object" or however the root of inheritance is named. I suppose this the way Smalltalk does it, this is the way Java implements it, and anyway it is the way I am implementing it in Zero ( http://trevinca.ei.uvigo.es/~jgarcia/TO/zero/ ). The only "bad thing" is that it makes the "Object" object to be quite "big", in terms of number of methods. > Every object you create is "about" something. You might create an object > called "circle" that is about circles on the screen, for example. It > should know things like its diameter, its center and perhaps stuff about > its border and interior color. The more we can make ourselfves believe > that this actually is a circle, the better it will be to work with it. However, it will always have more functionality than the circle concept has. For example, you could create another circle sending the message "copy". In order to follow the path of pureness suggested by the concept of mirrors, perhaps the copy method should exist in another object of the library, the "factory" object or something. So, instead of doing: myCircle = Circle.copy() you could do: myCircle = Factory.copy( Circle ) Or something like that. > Another advantage of this organization is that just a few > kinds or mirrors are enough to deal with all objects in Self. A few kinds of mirrors ? Sorry, I don't understand. Why not a single Mirror object ? Salud ! Baltasar --oOo-----------------------------------------------------------------oOo-- Servicio de acceso ó correo electrónico vía web da Universidade de Vigo Servicio de acceso al correo electrónico vía web de la Universidad de Vigo Servicios Informáticos [ http://si.uvigo.es ] Universidade de Vigo [ http://www.uvigo.es ] URL: https://correoweb.uvigo.es

3 2

Adding method slots dynamically
by oscar_lopez_p 16 Aug '05

16 Aug '05

Hello, How can I add dynamically a method slot to a self object? . I have: the method selector, the argument names and the body (source code) of a method, and I need (at runtime) to create a method from them and add it to an existing object. Thanks for the help, Oscar Lopez

3 3

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 August 2005