Self-interest March 1991

self-interest@lists.selflanguage.org

15 participants
31 discussions

Self and Scheme
by mcr＠Sandelman.OCUnix.On.Ca 28 Mar '91

28 Mar '91

On Mar 27, 2:18pm, Patrick Logan wrote: } >From uiucuxc!eng.sun.com!ungar Wed Mar 27 14:04:42 1991 } I love the idea of putting lookup within the language. } Perhaps the VM shouldnt implement any kind of inheritance at all? } } Can you say Scheme? This is not an entirely facetious suggestion. It I can. } sounds like this discussion is leading to a small, regular easily } optimized language that can be used to build higher-level language } features like inheritance and polymorphic procedures. 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. If it weren't for the fact that the core of Self was implemented in C I probably would have tried to make Self do breadth-first searches rather than depth first searches weeks ago (I keep meaning to post regarding this. I will do that in a seperate message). My friend countered that there is always the Parser object in Smalltalk from which one could build another Compiler. This is sort of like saying that 'there is always getchar() for C' [okay. maybe that isn't fair. There is always 'yacc'] I personally can't see any good ways to integrate a lot of the concepts of classless-OOP and meta-circular Lisp that would provide the strengths of both. Also, even in Alpaca Lisp (a very slow lisp derivative [more like T and LeLisp than anything else I've read about]), I would up building a VM. Mind you, the VM was simulated by a Vicuna Lisp program. (Vicuna Lisp was a simple and not very intelligent Lisp written in C). The VM 'assembly' code that implemented the Alpaca Lisp interpreter was hand crafted and could not have been described in Lisp. It handled tail-recursion, and crossed-tail recursion in the interpreter. My point being that to really get into the guts of a language and make it do precisely the stuff you want, one often has to resort to a lower level. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr(a)sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!

1 0

Re: Multiple polymorphism / multi-methods
by ungar＠Eng.Sun.COM 28 Mar '91

28 Mar '91

From mntgfx!dad.MENTOR.COM!plogan(a)uunet.UU.NET Wed Mar 27 16:43:48 1991 Return-Path: <mntgfx!dad.MENTOR.COM!plogan(a)uunet.UU.NET> Message-Id: <9103272218.AA01106(a)dad.MENTOR.COM> To: self-interest(a)self.stanford.edu In-Reply-To: Dave Ungar's message of Tue, 26 Mar 91 18:56:45 PST <9103270256.AA12884(a)self.Eng.Sun.COM> Subject: Multiple polymorphism / multi-methods Status: R >From uiucuxc!eng.sun.com!ungar Wed Mar 27 14:04:42 1991 I love the idea of putting lookup within the language. Perhaps the VM shouldnt implement any kind of inheritance at all? Can you say Scheme? This is not an entirely facetious suggestion. It sounds like this discussion is leading to a small, regular easily optimized language that can be used to build higher-level language features like inheritance and polymorphic procedures. Excuse me for leading this perhaps too far astray. I don't want to start discussing Scheme (or compiling for continuations, etc.) but it is a reference point when discussing core languages vs. extensions that can be built with a core. Nice point. Scheme is ALMOST right, but wrong enough to be very. THe problem is: Scheme puts variable binding at the bottom, separate from function invokation. We want something as elegant, but with message-passing (method invokation) at the bottom. This may be too cryptic or inflamatory--sorry if it's the former. Dave

1 0

Re: Multiple polymorphism / multi-methods
by ungar＠Eng.Sun.COM 27 Mar '91

27 Mar '91

I love the idea of putting lookup within the language. Perhaps the VM shouldnt implement any kind of inheritance at all? Dave

2 1

Re: Multiple polymorphism / multi-methods
by burdicwr＠mentor.cc.purdue.edu 27 Mar '91

27 Mar '91

Taking inheritance out of the VM sounds cool to me, but do you think it's possible to get the same performance out of it without it being in the VM? -- Bill

1 0

Self, programming and TCP
by R James Noble 25 Mar '91

25 Mar '91

Urs writes - > Our current system has "programming" and debugging, i.e. you can look > at the activations on the stack and single-step a process. However, > the UI part of this isn't there yet, and the docs haven't been updated > either. I live without the UI (partly through choice, partly through necessity). I am resigned about the docs, although (so far) you have allways been very helpful over mail ... Laurent writes - > The only primitive concerning such a beast is > TCPConnectToHost:Port:, which is relatively poor. Well, it does work. I have a prototype which works over X using just this. It was instructive to write. james

1 0

Re: Multimethods
by ungar＠Eng.Sun.COM 25 Mar '91

25 Mar '91

From @udel.edu:carroll@cis.udel.edu Fri Mar 22 17:17:41 1991 GMT To: self-interest(a)self.stanford.edu Subject: Multimethods From: "Mark C. Carroll" <carroll(a)udel.edu> Date: Fri, 22 Mar 91 20:09:55 -0500 I find the idea of multimethods extremely interesting, and I've found multiple polymorphism to be extremely useful in languages like C++. But before something like that gets added to Self, I think some consideration should be given to what it does to the model of the language. Self currently has an extremely elegant model. It provides an extraordinarily simple, uniform way of doing things. The basic operation is the message pass, and if you understand the conceptual mechanics of message passing, you understand Self. (Well, it's a bit of an exageration, but, for the sake of argument, let it stand.) What happens to that model when we add multimethods? Great question! I think it's something like: "Ask a bunch of objects to do their thing" instead of asking just one. But, it may be more profound than that. We won't know till we try. Dave

1 0

Re: Multiple polymorphism / multi-methods
by ungar＠Eng.Sun.COM 25 Mar '91

25 Mar '91

I have always considered multiple polymorphism (a.k.a. multi-methods) a good idea. I would like to try to convince you of this, as well as see whether any of you in self-interest land have any thoughts on the matter. Congrats, you have convinced us! (Actually, we were already) Multiple polymorphism is a generalization of message passing, so you can still using message passing most of the time, keeping the corresponding mental model that goes with it. maybe yes, maybe no. Certainly yes for no-argument sends It eliminates the need to do explicit type checking in most cases. I hope so, but. . Double (and triple and higher) dispatching eliminates the speed problems associated with explicit type checking by turning around and sending a message to the argument including the type of the receiver in its name. For example, integer's '+' method is implemented as 'arg addFromInteger: self', where 'addFromInteger:' is implemented in both integer and float. The problem with double dispatching is that it is messy, particularly when you have to dispatch on three or more arguments. Exactly! The most common use of multiple polymorphism would be for arithmetic operators such as '+'. There would be separate methods for 'integer + integer' and 'integer + float', so no explicit type checking or double dispatching would be needed. Another example of where multiple polymorphism would be useful is for the displayOn: method. Let's say there are four types of forms, regular ones (1 bit plane), opaque ones (2 bit planes: one is a mask), color ones (many bit planes), and opaque color ones (many bit planes: one is a mask). We would like to be able to display any kind of form on any other kind of form using any of several rules/modes (copy, reverse, etc). This could be implemented nicely as a multi-method: form displayOn: form At: point Rule: copy opaqueForm opaqueForm reverse colorForm colorForm drawBlack opaqueColorForm opaqueColorForm eraseWhite There are 4 x 4 x 4 = 64 combinations, most of which would be valid methods. Can you imagine implementing this using triple dispatching? Ugh! Yes, we had thought of the very same examples. But I think it will used differently than we can guess. Now that I've tried to convince you that multiple polymorphism is useful, I'll discuss how it could be implemented in SELF. Adding multiple polymorphism to a class-based language can be done in the following way. The method dispatch is done by searching in a directed acyclic graph (DAG) of methods for a particular message with the following property: A method X is a descendant (non-strict) of another method Y in the DAG if the classes of X's arguments are (non-strict) subclasses of the corresponding classes of Y's arguments. The search is done by logically inserting a node for the classes of the actual arguments and then searching up from there. If there are several parents, then there is an ambiguity, much like the ambiguities that occur in multiple inheritance. In a prototype-based language such as SELF, we would replace the 'subclass' relation with the 'inherit' relation: A method X is a descendant (non-strict) of another method Y in the DAG if X's arguments inherit from (non-strict) Y's arguments. I basically agree. Of course, I haven't dealt with the issue of efficiency: how this method lookup can be optimized. Also, how does multiple polymorphism interact with other language features such as multiple inheritance and privacy. I don't want to trivialize the problem - I know it is difficult. yes What are your thoughts and plans regarding multi-methods in SELF? _Restart (i.e. go to the top and read :-) - Danny Epstein dje(a)scs.carleton.ca Dave

1 0

Re: Undocumented Primitives
by Urs Hoelzle 25 Mar '91

25 Mar '91

> While reading the unix.self sources, i saw a _Fcntl: primitive in the > private setNonBlocking method. This primitive is not documented. Are > there other undocumented primitives in the current implementation of Self ? Not that we know of ;-) We try to document what's in there, but apparently _Fcntl slipped through the net. > I'm > particularly interested in communication primitives. What about a _Send: > or a _Recv: primitive subsuming the _WriteFrom:Offset:Count: and > ReadInto:Offset:Count: ones ? > In fact, i'm looking for a distributed Self implementation, that is many > Self interpreters running concurrently and communicationg through the > Internet network ! The only primitive concerning such a beast is > TCPConnectToHost:Port:, which is relatively poor. Will the next release > provide more functionnalities to deal with concurrency and/or > distribution ? We're not planning to get in the distributed systems business anytime soon... but Ole is working on making it possible to execute any Unix system call from within Self, if that helps. -Urs

1 0

Undocumented Primitives
by thomas＠loria.crin.fr 25 Mar '91

25 Mar '91

While reading the unix.self sources, i saw a _Fcntl: primitive in the private setNonBlocking method. This primitive is not documented. Are there other undocumented primitives in the current implementation of Self ? I'm particularly interested in communication primitives. What about a _Send: or a _Recv: primitive subsuming the _WriteFrom:Offset:Count: and ReadInto:Offset:Count: ones ? In fact, i'm looking for a distributed Self implementation, that is many Self interpreters running concurrently and communicationg through the Internet network ! The only primitive concerning such a beast is TCPConnectToHost:Port:, which is relatively poor. Will the next release provide more functionnalities to deal with concurrency and/or distribution ? --laurent

1 0

Re: Selfish pragmatics
by Urs Hoelzle 25 Mar '91

25 Mar '91

> Just out of interest (actually so I can satisfy a supervisor) when is > the next Self source release (and the VM source release) expected ? > (Assuming you're all not going to work on SWIM, Self With Integral > Multimethods :-). What new things are likely to be in the next release - > in particular, programming primitives callable from Self programs, > and possibly an exteneded _Perform primitive Craig mentioned to me in > email discussions before Christmas last year? Our current system has "programming" and debugging, i.e. you can look at the activations on the stack and single-step a process. However, the UI part of this isn't there yet, and the docs haven't been updated either. So it will probably take a while until the next formal release. The VM source should be part of that (assuming that Stanford's OTL lawyers agree with our plans), but be warned that it will be without much documentation. -Urs

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