Self-interest November 1991

self-interest@lists.selflanguage.org

8 participants
13 discussions

Re: saying arrays
by chambers＠cs.washington.edu 28 Nov '91

28 Nov '91

Actually, it's trivial to implement evaluating-in-context initializers. The reason we never did this is because some in the group felt that literals should be literals; the source code would contain a pointer to an object (the literal) that was constructed at parse-time. Others in the group felt that dynamic initialization of slots would be convenient. The purists won. -- Craig Chambers

1 0

Re: saying arrays
by David.Ungar＠Eng.Sun.COM 28 Nov '91

28 Nov '91

Yes, array constants might be worth adding--any feelings about it out there? Expressions in object literals--I seem to recall that it would have been a pain to implement evaluation in the current context. Craig do you remember more about this? Dave

1 0

saying arrays
by William R Burdick 26 Nov '91

26 Nov '91

One of the advantages of Lisp is that you can 'say' data. This saves programming time but more importantly, it makes code easier to read ('(a b c) is a bit easier to read than (cons a (cons b (cons c nil)))). An even more useful construct is the 'list' function, because it is more powerful than literal lists, because you can compute the values of the list at runtime and it's only slightly harder to read. Perhaps better than 'list' is the backquote macro, because it looks more like a literal list. You can do this in Self with objects that have named slots, but you can't 'say' an array. I think it would be a good idea to add a construct like this. The construct I propose is syntactically simple: say-array: '{' opt-stmt-list '}' This would make a computed array. Implementation is simple too -- it's just like the '[' and ']' words in PostScript: the array is (for the most part) just a copy of the top elements of the stack. One really useful application of this construct to use computed arrays as initializers, like this: window cloneWith: { curTitle. 0@0 extent: 100@100 }, where curTitle has been computed at runtime. This could not be done with a literal object, because curTitle needs to be computed at run time. Also, I'm not really clear on why expressions in object literals can't be evaluated in the currently active context in a similar manner; the data slots of the new object would also just be a stack copy. -- Bill

1 0

Re: dynamic inheritance -- icons
by jackson＠parcplace.com 25 Nov '91

25 Nov '91

The problem of class-explosion posed by computational domains that inherently require a large or unbounded number of classes has been addressed in Smalltalk without resorting to multiple inheritance. The work that I'm thinking of is described in a paper entitled "A Smalltalk System for Algebraic Manipulation" by S. Kamal Abdali, Guy W. Cherry, and Neil Soiffer. Using classes to model abstract algebra in the obvious way poses the class-explosion problem since, for example, there are potentially an infinite number of algebraic structures to be modeled (i.e., there are an infinite number of groups, rings, etc). I don't know whether this approach is applicable to the problem that you describe, but you might find the paper interesting reading. To give you an idea of their approach, I've reproduced the abstract below: Abstract: "This paper describes the design of an algebra system Views implemented in Smalltalk. Views contains facilities for dynamic creation and manipulation of computational domains, for viewing these domains as various categories such groups rings, or fields, and for expressing algorithms generically at the level of categories. The design of Views has resulted in the addition of some new abstractions to Smalltalk that are quite useful in their own right. Parameterized classes provide a means for run-time creation of new classes that exihibit generally very similar behavior, differing only in minor ways that can be described by different instantiations of certain parameters. Categories allow the abstraction of the common behavior of classes that derives from the class objects and operations satisfying certain laws independently of the implementation of those objects and operations. Views allow the run-time association of classes with categories (and of categories with other categories), facilitating the use of code written for categories with quite different interpretations of operations. Together, categories and views provide an additional mechanism for code sharing that is richer than both single and multiple ineritance. The paper gives algebraic as well as non-algebraic examples of the above-mentioned features." Frank

1 0

Re: dynamic inheritance -- icons
by David.Ungar＠Eng.Sun.COM 24 Nov '91

24 Nov '91

Cute! Dave

1 0

dynamic inheritance -- icons
by William R Burdick 24 Nov '91

24 Nov '91

I was giving a small talk (heh) on Self and I came up with a neat dynamic inheritance tool. The example I gave was modelling a factory where things broke. Say you have 15 possible ways that things can break, and things could break in all 15 ways at once. Each type of break represents new behavior, so in Smalltalk you'd have to make 15! classes to represent all the combinations of behavior, if you were using classes to model the behavior. An alternative would be to use variables to represent the aquired breaks and make some kind of delegation scheme or something. Since breakage can affect arbitrary other behaviors of an object, it makes sense to use inheritance to model it. The construct I came up with to handle this is called an icons. Here is its definition (I haven't tested this, btw): prototypes _AddSlotsIfAbsent: (| icons = (). weakIcons = () |). prototypes icons _Define: (| iCAR* <- lobby. "or whatever -- an 'empty' object" iCDR* <- lobby. "or whatever -- an 'empty' object" |). prototypes weakIcons _Define: (| iCAR** <- lobby. "or whatever -- an 'empty' object" iCDR* <- lobby. "or whatever -- an 'empty' object" |). Now just represent your objects in the factory with weakIcons objects having the iCAR set to the object. The inheritance level of iCAR lets the iCDR override the behaviors in the iCAR. To add behavior to the factory object, just add icons (not weakIcons) objects to the 'chain' and they will override the normal behavior of the object. -- Bill

1 0

Re: Mail-Address-Move + 3 Questions
by Yves Arrouye 15 Nov '91

15 Nov '91

Please remove me from the mailing list. -- ---------- Yves Arrouye arrouye(a)imag.imag.fr Ensimag

1 0

Re: Mail-Address-Move + 3 Questions
by David.Ungar＠Eng.Sun.COM 14 Nov '91

14 Nov '91

> From owner-self(a)self.stanford.edu Thu Nov 14 10:36:40 1991 > Date: Thu, 14 Nov 91 19:36:34 +0100 > To: self-interest(a)self.stanford.edu > Subject: Mail-Address-Move + 3 Questions > > > My mail-address will soon be moving from > > erwin(a)suncvt12.verfahrenstechnik.uni-stuttgart.de > > to > > erwin(a)cvt12.verfahrenstechnik.uni-stuttgart.de > > > I don't have any influence on when this will be exactly, > but please include my new address into your list as well. > > > By the way: I have the understanding that the people who > worked on Self are now hired by Sun (Luckily I'm sitting > at a Sun-Workstation...). What does this mean for me: > > 1) Self will soon be not available free of charge > (like it is now) ? > 2) Self will be distributed by Sun ? > 3) Self will be ported to other platforms ? > > Please give us some insight. Thanks. > > - erwin > 1) The next release of Self will be free and will include source code and the right to redistribute it (Stanford willing). 2) We plan to keep on doing new releases from Sun. Sun really does understand that this thing needs to be widely available. 3) We hope to either help others port, or do a port ourselves. Things are pretty hazy here. Hope this helps Dave

1 0

Mail-Address-Move + 3 Questions
by erwin＠suncvt12.verfahrenstechnik.uni-stuttgart.de 14 Nov '91

14 Nov '91

My mail-address will soon be moving from erwin(a)suncvt12.verfahrenstechnik.uni-stuttgart.de to erwin(a)cvt12.verfahrenstechnik.uni-stuttgart.de I don't have any influence on when this will be exactly, but please include my new address into your list as well. By the way: I have the understanding that the people who worked on Self are now hired by Sun (Luckily I'm sitting at a Sun-Workstation...). What does this mean for me: 1) Self will soon be not available free of charge (like it is now) ? 2) Self will be distributed by Sun ? 3) Self will be ported to other platforms ? Please give us some insight. Thanks. - erwin

1 0

Upcoming Self release
by Randall.Smith＠Eng.Sun.COM 08 Nov '91

08 Nov '91

As many of you know, the Self group (now housed at Sun Microsystems Labs) is planning a new release of the system. This is to let you know that we are working on the release, and hope it will be ready in a couple of months. Available with the release will be a humongous pile (50k lines +) of poorly documented C++ source code, implementing the Self virtual machine. San Francisco Bay Area residents: we will hold a half-day Self tutorial at Sun soon after the release. It will be essentially the same as the (top rated!) tutorial given at ECOOP last July.

2 1

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 November 1991