Self-interest January 2004

self-interest@lists.selflanguage.org

10 participants
7 discussions

OOPSLA 2003
by Steve Dekorte 16 Mar '04

16 Mar '04

Just noticed that Dave is giving what looks like a really interesting talk at OOPSLA 2003: http://oopsla.acm.org/oopsla2003/files/key-4.html Any hope for a protos workshop this year? Everything seems to be about design patterns or Agile programming. Borrrrrring. :-) Cheers, Steve OSX freeware and shareware: http://www.dekorte.com/downloads.html

7 21

simpler block story
by Jecel Assumpcao Jr 21 Jan '04

21 Jan '04

Below is the first design for blocks that I am not totally unhappy with. Some of this could be used in Self but parts depend on the Neo Smalltalk syntax rules to keep it visually similar to the current system. Instead of a special syntax for blocks, context (activation) objects would understand the message [ ... ] with a method object as the argument (the thing between "[" and "]") which would be like a Self message "copyAsBlock: methObj". While it would be possible to write a [ b ] in practice the '.[.]' message would always be sent to the implicit self receiver (the currently executing context). Here is how this method would be implemented (in a mix of Neo Smalltalk, Self and Smalltalk-80 notations for convenience) .[.] = ( | :m. b | b: block copyArity: m arity. b context: thisContext sender. b method: m. b ) The Smalltalk-80 notation "thisContext sender" could be replaced in Self with just "self", except that might refer to the receiver of the original method instead of the current one. It isn't important. Supposing "m arity" is 2 (m takes two arguments), then "b" would be: ( | parent* = traits block. context <- prototypes context. method <- prototypes method. value = (error: "needs 2 arguments"). value: arg = (error: "needs 2 arguments"). value: arg1 with: arg2 = (method runFor: context With: arg1 With: arg2). ) Obviously 'runFor:With:With:' should actually be something properly reflective, but this should give the general idea. The point is that this is all done with regular messages and objects (blocks are not special in any way, though methods still are a little) and actually exposes the way things are done in many Smalltalks (using the "send blockCopy" bytecodes in Smalltalk-80, for example). Yet it looks almost exactly the same and works almost exactly the same (the only difference is that you can now send 'context' or 'method' to a block) as the current solutions. How the implementation actually does things, however, is an entirely different story... -- Jecel

1 0

The problem of dynamic inheritance
by cyberbaixing 19 Jan '04

19 Jan '04

Dear All, I am a newer of SELF. I try to run the a program of dynamic inheritance. which is defined as follows: globals _AddSlotsIfAbsent: (| a =(). b =(). c =(). |) a _Define: (| f = ('a' printLine. p:b. f). |) b _Define: (| f = ( 'b' printLine ). |) c _Define: (| p*<- a. b = b. f = ('c' printLine. resend.f). |) But if I send the message f to slot a, the result is always: "Self 14" a f. a No 'b' slot found in a slots object. If I rewrite the slot a without the dynamic inheritance but replace with directed resends or undirected resends like this: a _Define: (| p*<- b. f = ('a' printLine. b. f). |) The result is: "Self 14" a f. a b 'b' Why the resends works but the dynamic inheritance not? Did I make any semantic mistakes in slot a's definition? Furthermore, how to understand the meaning of "activation record"? In the above example, which one can be looked as the current activation record? I know the slot a is the receiver of the message, the method f has a clone. The code of f is running in the context of clone. 'a'printLine prints out the string a, the code p:b.f is to change the parent of slot a to slot b. But where is the activation record here? Is it same as the activation object? Thank you in advance. Regards, Xing

3 10

OOPs Training
by Perumalsamy 15 Jan '04

15 Jan '04

Dear Friends, To get information about Object oriented programming Training , Training Institute, Trainers pls join http://groups.yahoo.com/group/OOPs-Training Regards http://groups.yahoo.com/group/OOPs-Training

1 0

Re: StrongTalk combined with Self?
by Mario Wolczko 12 Jan '04

12 Jan '04

> If one can't sell prototyping directly in industry apps, > one could at least make use of it in development. ;-) > Any such projects out there perhaps? This may be of some interest: http://www.experimentalstuff.com/Technologies/JIntroTool/index.html

2 1

StrongTalk combined with Self?
by Jonas Bosson 09 Jan '04

09 Jan '04

Just a thought. Could optional typing be a way to trim Self performance? I spotted the Strong Talk project: http://www.cs.ucsb.edu/projects/strongtalk/pages/ I know that this is somewhat controversial, but it could, without altering what is, also bridge to other typed languages and deliver 'pass by value...' ;-) Am I Wrong? best, Jonas

3 3

Slate updates
by Brian T Rice 05 Jan '04

05 Jan '04

It's been so quiet lately; I had forgotten this list existed to some extent. Anyway, there are some updates on the Slate project that I thought worth sharing. The VM-and-image standalone setup are nearing completion; Slate currently has been running inside of a Lisp image. We've worked out many new interesting libraries and designs, particularly for the collections, streams, external i/o, and graphics. We also still have our optimizing to-native compiler being worked on as time allows, with many interesting techniques. The language has incorporated two major experimental updates: first, subjective programming is now supported by an extension to the method dispatch system. This is detailed in the manual: http://slate.tunes.org/progman/node8.html#SECTION00033500000000000000 although there are implications which are not entirely obvious from that. We have that as well as optional keyword argument-passing implemented, but not incorporated extensively, as we've been letting the design influence our thinking as we work on everything else, trying to find the best way to apply these mechanisms, or find out what problems may exist with the idea as implemented. I just released 0.2.1, which still requires Common Lisp to run, but also includes quite a bit of the basis of the new implementation. A separate standalone release should be just a month or two away. -- Brian T. Rice LOGOS Research and Development http://tunes.org/~water/

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 January 2004