Self-interest July 1999

self-interest@lists.selflanguage.org

8 participants
13 discussions

STORE OBJECTS IN SELF
by mpato 06 Jul '99

06 Jul '99

Hello everybody, My name is Maryah and I´m a estudent at Vigo University ( Spain). Now I´m working in an application on SELF and I have a very big problem: -I did my new objects and I moved it to " Own window" now I want to store this window because I want to work with this window later...How can I do that?... How can I restore the information later? Thanks for your help Maryah ( I´m sorry for my English ) ------------------------------------------------------------------------ eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications

2 1

Sends, calls, stacks, scopes
by Douglas Atique 05 Jul '99

05 Jul '99

In my interpreter, I am trying to associate each instance of the interpreter with one object, named the "evaluatee". As an oop, the evaluatee can be: - a data object, without any code inside: -> the evaluation returns the evaluatee. - a method object, with code inside: -> the evaluation clones the evaluatee, creating the activation, binds the arguments on the stack to the arg slots* on the activation and finally gets the bytecodes and the literals from the activation and follows the instructions. In the case of the code object, the bytecodes tell the interpreter what to do, namely: - to push the evaluatee onto the stack; - to push a literal, given by its index into the literals vector, onto the stack; - to return an object; - to load a delegatee, given by its index into the literals vector, into the delegatee register; - to load an extended index into the index register; - to evaluate a send; -> if the selector is a primitive*** (in particular check for _Restart, which has to be supported by the interpreter directly, by resetting the bytecode counter) get its pointer (with getPrimDesc and PrimDesc::fn()) and execute it -> if the selector isn't a primitive: --> lookup the slot matching the selector, checking that one and only one slot is found --> if the selector is an assignment, perform the assignment with oopClass::find_assignee_slot(stringOop) and oopClass::define_prim(oop) --> if the selector isn't an assignment: ---> create a new instance of the interpreter passing the object referred to by the matching slot and the stack (possibly with other arguments already pushed) ---> evaluate the object and push the result on the stack - to evaluate an implicit (self) send; -> do the same as the send, only that the receiver is the activation. - to evaluate a super (re)send; -> do the same as the send, only that the receiver is the activation** but also the lookup of the selector will start not at the activation proper, but at either 1) a parent slot of the receiver whose name matches the delegatee (in case the delegatee is non-NULL) or 2) any of the parent slots of activation (undirected resend). I tried to describe the algorithm I am developing with details, but I may have missed something. Would anyone like to make comments on the algorithm? I was thinking of the stack I am supposed to use. I would like best to use the new Standard C++ Library's stack container, but I am afraid it won't work well with the resource and heap allocation schemes, as well as with the garbage collector. Would anyone say anything about this? I appreciate comments, suggestions, doubts, any feedback. Douglas _______ * I still don't know how to assign the arguments to the argument slots on the activation, but I understand that they should be on the stack, ready for popping. ** It is not very clear yet to me if the receiver can be the parent whose slots match the selector. *** I still don't know how to call the primitives from the interpreter. ------------------------------------------------------------------------ eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications

1 0

Nil
by Douglas Atique 05 Jul '99

05 Jul '99

Remember that discussion on the usefulness of nil and the default initialization of slots? I was reading the Self 4.0 Programmer´s Reference Manual this weekend and thought a little bit more about the purpose of nil. If I got the idea, nil should not be used as a default initializer, instead a specific object should be created to mean "no object here" in the particular context. Well, perhaps (I don't remember if anyone said this) nil could be used as a prototype of this kind of object, or a traits, so that the common behavior of all "null" objects would be concentrated on it. Is it already so? I understand that nil is one object, and as such it has one type. So if one uses it to represent "no object" in places where different types are being represented, then one is losing type information. If we create other objects to play this role, so that nil is their parent, or so that they are cloned from nil, perhaps we can keep the commonality of the nil "family" and also keep different nil's for different "types". Did I get the idea, folks? Do I make a point? Douglas ------------------------------------------------------------------------ eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications

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 July 1999