Self-interest February 1991

self-interest@lists.selflanguage.org

10 participants
24 discussions

inheriting data slots
by burdick＠mentor.cc.purdue.edu 01 Feb '91

01 Feb '91

Write once slots would do it, but I don't see why adding the slots of data parents of prototypes would slow things down. Maybe my first letter wasn't clear... You don't need to add the slots of data-parents at 'run-time,' that is, you only need to do this in order to construct the prototypes, not to construct the clones. Once you have all the slots in the right places, you can just clone the prototype and everything is fine. For instance, if you have a 2-d point (with slots: parent*, x, and y) where parent holds traits point, and you want to make a 3-d point (with slots parent*, x, y, and z), where parent holds traits TDpoint, you can construct the prototype in these three ways (there are more, but here are 3): 1) make it by hand; just define it as (| parent* = traits TDpoint. x = 0. y = 0. z = 0 |). This will work, but it makes for unmaintainable code -- you'd probably end upwriting a script to propogate changes in data parents to the children prototypes. 2) use a data parent and redefine copy: (| parent* = traits TDpoint. dataParent** <- prototypes point. cloning*** = traits deepClonable. z = 0 |) where deepClonable contains rules for copying through data parent slots. The problem here is that dataParent is assignable and so it will slow down access to data in slots inherited from the dataparent. 3) use _AddSlots: and _RemoveSlots: like this (this is using the old conventions): prototypes _DefineSlots: (| TDpoint = (| parent* = traits TDpoint. z |) |) "inheriting is a global variable" inheriting: prototypes point copy inheriting _RemoveSlots: 'parent' prototypes TDpoint _AddSlots: inheriting Using method #3, you get a prototype with all the slots it 'inherits' from its data parent, and you can use it with good performance. This is possible right now, but it's a little clumsy -- it would be easier to maintain (and prettier) if we could use _AddSlots: and _RomoveSlots: from within methods so that the inheritance code could be one message instead of three (and you wouldn't need

1 0

a digital simulator in Self
by vme131!lsi3!jecel＠uunet.UU.NET 01 Feb '91

01 Feb '91

I have written a small ( 700 lines so far ) program in Self that allows you to simulate digital circuits. You can describe a circuit using Self code or using a netlist. I want to use it for top-down design of a complex integrated circuit and system. I am still adding to it, but hope to post it in one or two weeks. One thing that is lacking is some way to view tha waveforms since I haven't had the time, yet, to wade through the UI code. All I really need to to be able to draw simple line graphics. If someone has an easy solution for simple, non- interactive graphics for Self I really would like to see it. Jecel - University of Sao Paulo - Brazil

1 0

Re: primitives
by Urs Hoelzle 01 Feb '91

01 Feb '91

> Are primitives like _RemoveSlots: and _AddSlots: going to be useable > within methods in the next release?? This would be cool, because it > would help with data inheritance. > No (see the release message). They do work in our current system (i.e. you can change objects while the program is running), but we want thing to stabilize a bit before putting them into a release. > If you use the model for inheriting data which adds an assignable > dataParent slot to objects which inherit data, it slows down message > sending.. If we could use just add the slots from data parents > directly, it would speed things up a lot... No! This would actually slow down the system a lot. The reason is that programming primitives change things which normal Self programs cannot change, such as the format of objects or the value of constant slots. As a result, all compiled code which depended on the old value of a constant slot (or the old format of an object) must be flushed and later recompiled. There is no free lunch... Self programs can be made fast by constant-folding many lookups, but if you frequently change the underlying "constants" you lose. What you really want is "write-once" slots which you could initialize at cloning time. In this way, you could express the fact that a parent slot isn't really assignable, i.e. does not change once an object has been created. This would be a good documentation aid (helping others to understand your programs) while at the same time providing a hint to the compiler. -Urs

1 0

new release
by Urs Hoelzle 01 Feb '91

01 Feb '91

Release 1.1 of Self is now available. Below is a list of changes and enhancements that have been made since the last release (1.0). Only the major changes are included. In addition to the changes listed, many small changes have been made and all known bugs have been fixed. - The programming primitives have been cleaned up. _DefineSlots: has been removed and two new primitives introduced instead: _AddSlotsIfAbsent: and _Define: (see section I-5.6). - Two compilers are now distributed with the system (see section I-2.1). - The virtual machine now supports lightweight processes through a set of primitive methods (see Table 16 in Appendix F of the Self System Manual). - Byte and object vectors can now have user-defined slots. - The representation of strings has been changed. - Compiled code space has been divided into four areas whose sizes can be individually set with environment variables (see Appendix E of the Self System Manual). The first of these changes is probably the most visible since it affects almost every source file. The manual contains an expanded section on how to use the programming primitives. See below for an example of the differences in use between _DefineSlots: and _Define:. Documentation ============= The manual has been updated and expanded; the collection of papers has been reformatted, and some of the papers have been edited (but are essentially the same as in release 1.0). All manual sections and papers are now available as separate PostScript files (see the README file in /pub). Contributions ============= /pub now contains a contrib directory for contributions by Self users; feel free to put your goodies there, but please observe the guidelines in README-contrib. Availability ============ Release 1.1 is available free of charge under the same conditions as the previous release; you need not sign a new license if you have signed one for the original release. Source code =========== The virtual machine source code for release 1.1 will be available shortly for academic use. You will probably have to sign a slightly more legalese license agreement (we are currently sorting things out with Stanford's Office of Technology Licensing). We will announce details on this as soon as possible. Converting from _DefineSlots: to _Define: ========================================= _Define: and _AddSlotsIfAbsent: are a pair of programming primitives that replace the _DefineSlots: of the original release, and they are used a little differently. Section 5.6 of the Self System Manual describes the new programming primitives thoroughly. A short example will illustrate the idiomatic use of _Define: and _AddSlotsIfAbsent:. The example defines an object that holds shared behavior for points, point traits. In the original release, this would have been accomplished by: traits _DefineSlots: ( | point = ( | parent* = traits pair. printString = ( x printString, '@', y printString ). + pt = ( (copy x: x + pt x) y: y + pt y ). | ) | ) In the new release, the same object is defined by: traits _AddSlotsIfAbsent: ( | point = () | ) traits point _Define: ( | parent* = traits pair. printString = ( x printString, '@', y printString ). + pt = ( (copy x: x + pt x) y: y + pt y ). | )

1 0

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