Self-interest April 1991

self-interest@lists.selflanguage.org

14 participants
30 discussions

Re: incremental compilation
by Urs Hoelzle 24 Apr '91

24 Apr '91

> What if the first time a method was called it was compiled by a quick > and dirty compiler and placed in the compiled method cache ? Then, if > it turned out not to be used very often it would be kicked out of the > cache to make room for others. If, on the other hand, it was called a > lot another, better, compiler would generate an optimized code for the > method and place it in the cache. This could be exetended to any number > of levels of optimization, but I doubt that more than two would be useful. Guess what our ECOOP '91 paper talks about... ;-) The paper describes a prototype of a recompiling system (the emphasis being on code quality, not compile speed) and outlines an extension of these ideas (called "adaptive compilation") which is pretty close to what you propose. Right now I'm working on a real implementation. We believe that >2 stages do make sense for various reasons, one of them being that you can generate better code with additional recompilations. Our current thinking is to put the first two stages (a very fast "dumb" compiler and a "fast but reasonable" compiler) into the VM for bootstrapping. As a third stage, there would be a really cool optimizing compiler written in Self. Besides having the advantage of using Self for the complicated part, this also gives you background compilation for free since the compiler is a normal Self process. But none of this is running yet, so I won't speculate any further... I better spend my time implementing it. The paper will be available through ftp in July. -Urs

1 0

incremental compilation
by vme131!lsiserv1!jecel＠uunet.UU.NET 22 Apr '91

22 Apr '91

I don't know if this idea has already been mentioned. If so, here it is again : What if the first time a method was called it was compiled by a quick and dirty compiler and placed in the compiled method cache ? Then, if it turned out not to be used very often it would be kicked out of the cache to make room for others. If, on the other hand, it was called a lot another, better, compiler would generate an optimized code for the method and place it in the cache. This could be exetended to any number of levels of optimization, but I doubt that more than two would be useful. The idea here is to make the compiler work harder on the methods which really make a difference, not to waste too much time with initialization code or stuff like that. Since compilation happens at run time in SELF this might make interactive applications seem more responsive without degrading benchmarks and other compute-intensive programs too much. - Jecel

1 0

the vm _is_ the database
by David_Stutz＠NeXT.COM 18 Apr '91

18 Apr '91

Well, alright -- I usually don't express myself well... >>So, you should at least separate "interesting" objects from >>"temporary" objects. The problem is, it may not be easy to >>distinguish them automatically. So, you probably end up telling >>the compiler what objects should be considered "interesting". But >>if you do so, theproposal resembles persistency, and is not so new >>anymore. The point is not that the techniques are so new, the point is that self fits into them so incredibly well... I am not suggesting that a pig of a database be grafted onto self -- instead, I'm suggesting that the existing vm machinery (which already resembles many efficient database engines) be examined in the possibly enriching light of another closely related, and extensively studied, discipline. You would most definitely want to have a means of expressing which objects were of "interest" if such an expensive shadowing scheme were used -- once having done this, you would sometimes want to keep the very short-lived invocation clones for tracability and reversability, if relevant (debugging, for instance, or within a "transaction"). At other times, you might elect to not keep anything at all... As I said: >**Object persistance** is clipped into the vm -- it is important to >realize that it is NOT integral to the language -- it is a separate, >invokable, service. You might not even use it, if you're doing >something lightweight. I am less interested in talking about specifics of persistence, and more interested in the language implications of a factoring such as I suggested. Where do you go to get your prototypes when you are on a large network of 100 mips workstations, all running self and sharing some set of prototypes? This may finally be a tractable problem, within the self runtime! David Stutz

1 0

Re: rantings and ravings
by px%fct.unl.pt＠Forsythe.stanford.edu 17 Apr '91

17 Apr '91

The shadowing technique that you refer may make sense in a database world, because: 1) Safety requirements mean that organizations like banks MUST keep every "version" of an account, for instance. 2) Objects don't change that much (my account doesn't, for instance). In a dynamic language such as Self or Smalltalk, measurements indicate a LARGE number of VERY SHORT LIVED objects, such as activation records. Do you really want to keep a copy of all the invocations of the method "Integer +"? So, you should at least separate "interesting" objects from "temporary" objects. The problem is, it may not be easy to distinguish them automatically. So, you probably end up telling the compiler what objects should be considered "interesting". But if you do so, the proposal resembles persistency, and is not so new anymore. Comments? - Joaquim

1 0

Re: Multiple polymorphism / multi-methods
by px%fct.unl.pt＠Forsythe.stanford.edu 17 Apr '91

17 Apr '91

jecel%lsiserv1%vme131(a)uunet.UU.NET (Jecel Mattos Assumpcao Jr) writes: >I like your mental model of multiple polymorphism: sending a message >to all the arguments. Also, multi-methods being "in" all their >arguments rather than just their receiver is a nice use of sharing. Does "self" still have any meaning in this case? I guess the name would be changed to "selves"? :-)

1 0

Re: Multiple polymorphism / multi-methods
by px%fct.unl.pt＠Forsythe.stanford.edu 16 Apr '91

16 Apr '91

On Apr 13, 6:38pm, Jecel Mattos Assumpcao Jr wrote: } > This is one thing I was discussing with a Smalltalk hacker a couple } >of days ago. One of the really beautifull things about Lisp and } >Lisp-like things (assembly language is the only non-Lisp derived } >language that also has this property) is that program is data and data } >is program. } } Actually machine language ( and not in all OSs or machines ), not assembly } has this property. Back in 1984 I designed ( but never tested ) a Michael Richardson <mcr(a)Sandelman.OCUnix.On.Ca> writes: } The thing that lets you get away with data<->code in Lisp is that } there is basically only your one datatype. The pair. There is } essentially no syntax compared to smalltalk, and things like } 'operators' and 'keyword messages' just don't exist. } In order to build a parser that could parse code (which was in this } case, simply data) the right way would be if it assumed some model of } the operators, etc... You couldn't implement your own language that had } different semantics. Languages that can be expressed in themselves (like Lisp) are usually called "self-embedding". Another language that has this property is Prolog. In Prolog, everything is a term, but I find Prolog's terms richer than Lisp's lists. Prolog includes an extensible parser that lets you declare new operators. It is very easy to make up a new "language" by declaring suitable operators and using them as keywords. Of course Prolog doesn't really offer you a free lunch, and some pathological cases can arise where the operators allow ambiguous parsing. These cases, however, do not arise in practice. I can provide more info on this matter if there is interest. -- Joaquim

1 0

Re: Implementation of Self
by craig 15 Apr '91

15 Apr '91

Papers on the Self implementation technology have been published in SIGPLAN PLDI'89 and '90, OOPSLA'89, and ECOOP'91 (forthcoming). The OOPSLA'89 and PLDI'90 papers are in the collection of papers entitled "The Self Papers" available via anonymous ftp from otis.stanford.edu. Of course, new implementation papers are always in the works, so stay tuned.... -- Craig Chambers

1 0

Re: Does self allow recursion?
by Urs Hoelzle 15 Apr '91

15 Apr '91

> Anyway, from what I gathered about the language, a method is in fact > an object. The slots of a "method object" act as local variables. I > may have missed it, but I don't recall any discussion about "method > activations" or such. If they don't exist, then I guess Self will > suffer the same problems as Fortran did, and disallow recursion. When a method is invoked, it is *cloned*, and the clone's slots are filled in with the actual arguments. Thus, an activation is a clone of the method object, and recursion works just fine (see section 2.4.2 of the reference manual). -Urs

1 0

Re: Multiple polymorphism / multi-methods
by craig 15 Apr '91

15 Apr '91

We've thought a little bit about computational reflection in Self. One approach would be to give every object a meta object. This object handles msg not understood (or perhaps even recv msg) messages for the met-ee. The meta object in turn has its own meta, up until a built-in object whose meta is the Virtual Machine. Meta objects are not classes, but are sufficiently non-concrete to cause us to worry about them (some of us more so than others). -- Craig Chambers

1 0

rantings and ravings (long and almost certainly boring)
by David_Stutz＠NeXT.COM 15 Apr '91

15 Apr '91

On a less practical note...a question I've had for a while: The first time that I saw a description of self, I was very excited by the possiblities of the language. (I still am.) Here is a language which has succeeded in factoring the problems facing programmers in a way that satisfys both their desire for an interactive world containing concrete things (prototypes), as well as their desire to control how things work and relate to each other (methods). [The recurring lisp-is-beauty arguments on this mailing list point out this dichotomy -- data is code, code is data...what a beautiful life...] Self also has tremendous potential for allowing the legal hoarding of prototypes. Any object that I polish off today might come in useful in the future; objects in self are dynamically typed, so if they turn out to be useful in some future world, they should be able to conform to unanticipated constraints automagically (through the magic of type analysis). OK, so here's my question, one which has been bubbled up recently by threads on this mailing list: why not exploit this factoring by leveraging the simplicity of its model and already existing database mechanisms? Here's what I mean by this... Suspend for the moment, if you will, your total programmer's distrust of the word "database" and assume that their are flexible, fast, and mathematically rigorous techniques that will allow people (someday) to use databases of some flavor to usefully store things. Things like prototypes. In fact, such a database might look a lot like the vm system of self... But it would also support the notion of query more explicitly, and might do more to protect the integrity of prototypes. Such a "database" must be an explicit service, not merely a language feature, for the same reasons that vm needs to be an explicit assumption in the self world. In fact, let's plug in this "database" and make it function as vm. There is an extensional piece which looks like the object space, and there is an intensional piece, which looks like methods. Maps are represented by immutable tables...you get the idea. And of course, since vm is transparent, anyone writing self code just knows about a few more options at their disposal -- there is no necessary impact at the language level (although some features might be useful to pass through). Now, with this database vm in place (or, for argument, let's say that vm has expanded to include the notions of query and tranaction), the explicit "type analysis phase" in the compiler might be embellished at will; new techniques could be installed and removed interactively, since they could be expressed as optimization techniques within the query engine (I'm assuming that a pluggable optimizer would be a very useful object to have in your lobby if you were a self developer, let's say...) Because its supports transactions, many active worlds could co-exist in which parts are shared; those parts might take on radically different looks in alternative worlds, since the objects which define a world implictly define a data model: the query context of this database is the context of object slots in a given world. Really useful tranformation techniques such as "magic sets" could be easily exploited within a given context by self's dispatching and compiling facilities. And the world would be a better place... Here are the most recent threads on this mailing list in this light: The **multi-methods vs. single receiver methods** question becomes whether to use a generalized "select on these attributes" vs. a basic "lookup-on-this-key". A very interesting possibility that emerges would be that not only could a multi-method be a "call to action" for a certain cooperating group of objects, but that that group of objects might be partially defined...for instance, send a prototype a message that dispatches on an entire set of prototypes, without having to physically construct the set before sending the message. If you think about this one in the self context (a world where a finite number of objects are sitting around doing things for you), this could be both simple and incredibly powerful. Of course, you still have to come up with the good language syntax... **Object persistance** is clipped into the vm -- it is important to realize that it is NOT integral to the language -- it is a separate, invokable, service. You might not even use it, if you're doing something lightweight. Different vms might use different instantiation techniques, which could help to solve the: **prototype corruption problem** -- prototypes are "selected" into a current world, which means that if they become trashed, the world can be "rolled back" to a consistent state. When the desired changes have been made, the new image of the object can be comitted to the database...using a time-based transaction mechanism. In other words, old objects never disappear, they just become "shadowed". This kind of technique is becoming very common, and is very manageable in this context, since the commit granularity is usually on a per-session basis (maybe once every few hours...) So, I could reference "the object that I used last week that I redefined black in.." if I wanted to break my system, for instance. The debugging possibilities are really great, as well as the large-project, object-sharing aspects of the system. The key point here is that the way self is structured seems to allow for an entirely different, and more sensible, treatment of persistance and evolution. Prototypes are concrete, so identity is not a big problem. The query model is simple, because it lives below user space. (Programmers never even see it.) Many, many good type inference algorithms already exist and could be utilized to make the compiler blazingly fast. And this would all be pretty simple (in a relative sense), again, because it is not intended to be general purpose. The performance and consistency techniques that have been developed in the database world would complement self's expressive computational model beautifully. If I'm not mistaken, object identity -- the big problem facing most people trying to do this kind of thing in Smalltalk, let's say -- doesn't rear its head at all, since there is simply no way that data *can't* have an identity in self. The data *is* the object...the only real difference that would be reflected by this type of scheme would be the notion of an explicit "query". Data (that is, objects) comes from some point in time, which can be reasonably defaulted to "the past", but might also include such interesting generic possibilities as "the future". Any thoughts, anyone? (If you made it this far...) David Stutz

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