Self-interest July 1994

self-interest@lists.selflanguage.org

19 participants
22 discussions

Mango - A Parser Generator for Self
by Ole.Agesen＠Eng.Sun.COM 19 Jul '94

19 Jul '94

I'm happy to announce availability of Mango, a LR(1) parser generator for release 3.0 of Self system. If you download Mango, be sure to check the README file for last minute announcements. Mango is available via mosaic: http://self.stanford.edu/papers/mango.html and ftp: self.stanford.edu:/pub/Self-3.0/contrib/ Mango is documented in a 43 page Sun Microsystems Laboratories Technical Report, TR-94-27. The postscript for this report can be found at the above mentioned places. You may also request a hardcopy by writing to: Editor, Technical Reports, 2550 Garcia Ave, M/S UMTV29-01, Mountain View, CA 94043-1100, U.S.A. Abstract -------- Mango is a parser generator that is included in Release 3.0 of the Self system. Mango goes beyond LEX/YACC in several respects. First, Mango grammars are structured, thus easier to read and map onto parse trees. Second, Mango parsers automatically build parse trees rather than merely provide hooks for calling low-level reduce actions during parsing. Third, Mango automatically maintains invariance of the structure of parse trees, even while grammars are transformed to enable LR parsing. Fourth, Mango and the parsers it generates are completely integrated in the Self object world. In particular, a parser is an object. Unike YACC, several independent parsers can co-exist in a single program. We show how to generate a Mango parser and how to use it by means of an example: a simple expression language. Furthermore, we show how to add semantic properties to the parse trees that the Mango parser produces. Mango is a realistic tool. A parser for full ANSI C was built with Mango. Sincerely, Ole Agesen, agesen(a)cs.stanford.edu

1 0

large objects on self.stanford.edu
by urs＠cs.stanford.edu 19 Jul '94

19 Jul '94

For those of you interested in (very) large one-of-a-kind objects, pictures of Shoemaker-Levy 9 and its interactions with Jupiter can now be found on our Mosaic server (http://self.stanford.edu). (Pictures courtesy of NASA JPL.) -Urs

1 0

Re: some suggestions
by david.ungar＠Sun.COM 16 Jul '94

16 Jul '94

I like all the suggestions, except that I believe it is inappropriate to define = for the lobby. Each object must have its own definition of what = should mean. However, there are places below the lobby (e.g. traits oddball) that do provide a default for =. Of course, when you define =, you must also define hash in order to add the object to a set. However, I do agree with the other suggestions; it's hard to know what to give up, though to reduce the overloading in general.

1 0

Re: Notation for delegation in OMT or BOOCH
by mulet＠info.emn.fr 16 Jul '94

16 Jul '94

I am working on meta-object protocols for controlling and extending the semantics of message passing. As such, Pierre Cointe and I, defined a prototype-based language, close from Self at first, without any delegation, but supporting a full reflective model. Then, we extend this model only by involving its reflective facilities, so as to provide single delegation, multiple delegation, caches, ... in an incremental way. If you are interested, I can give you more information, Philippe. ----------------------------------------------------------------- Philippe Mulet Phone: +33-40-44-83-87 Ecole des Mines de Nantes Fax: +33-40-71-97-40 3, rue Marcel Sembat 44049 Nantes Cedex 04 ----------------------------------------------------------------- e-mail: mulet(a)info.emn.fr -----------------------------------------------------------------

2 1

my previous email
by Ivan Moore 15 Jul '94

15 Jul '94

Hello, I made a typo in my previous email. Re: >'.' is used for different things - how about using something else >for the end of a statement - eg ';' and/or something different for delegation, >eg. '~' What I meant to say was: '.' is used for different things - how about using something else for the end of a statement - eg ';' and/or something different for resends, eg. '~' (I'm sure you all knew what I meant :-) Ivan. PS. I hope it doesnt sound like I'm moaning too much - really I think Self is excellent.

1 0

some suggestions
by Ivan Moore 15 Jul '94

15 Jul '94

Hello, I have a few comments/suggestions - the result of struggling to write a grammar for Self. It seems a shame to introduce inconsistencies because of some seemingly arbitrary decisions about syntax. '=' : You cant define '=' for the lobby (or anything that the lobby inherits from - eg default behavior). If you try - Self crashes - stack overflow or something like that. This makes it somewhat tricky to define the necessary methods in defaultBehavior so that everything that inherits from the lobby can be added to a set (for example), which is somewhat annoying. I realise that the lobby having '=' defined for it would lead to some strange looking expressions being quite legal. For example: 'm = ( | f = = 10. t = = self | something )' would result in the local slots f and t having the values true and false respectively. Or 't = = self' would result in a read only slot t = true. How about using something different to '=' for the things that __arent_the_same__ as a message send '='? '.' : '.' is used for different things - how about using something else for the end of a statement - eg ';' and/or something different for delegation, eg. '~' '^' and '|' '^' and '|' have special meanings so they cant be used as operator names, but '^^' and '||' can (but try to define a method '^^ x = ( x )' and you get an error - whereas '^ ^^ x = ( x )' is OK. Ivan. PS - really this isnt just to make it easier for me to write a grammar - its a matter of consistency in all things.

1 0

Re: Notation for delegation in OMT or BOOCH
by Guenter Kniesel 15 Jul '94

15 Jul '94

Reto Kramer <100073.1040(a)compuserve.com> wrote: > Delegation is very important for us because: > a) we only have single inheritance due to Smalltalk and thus ... Why are classes and instances so important to you? If you don't use Smalltalk just because you were requested to or because SELF isn't yet a fully supported commercial product then I'd like to hear more about the reasons (modeling problems of your application domain as well as specific technical problems) for needing both, classes/instances AND delegation. The motivation for needing both and the workaround / simulation invented in order to make it possible are interesting to me, because I am working on an integrated model of OO that allows e.g. joint use of instantiation and delegation (without the need for any simulation). e.g. A = Point new. B = Point new. A x: ... . B x: ... . A y: ... . B delegate_to: A. makes two Point objects that cannot mutate to sth. else, but that can use delegation to express that they allways have to be vertically aligned. Everyone who has an oppinion on the pros and cons of an integrated model is invited to respond too. Günter Kniesel Institut fur Informatik III e-mail: gk(a)cs.uni-bonn.de Universität Bonn Römerstr. 164 Phone: (+49-228) 550-276 D-53117 Bonn Germany Fax: (+49-228) 550-382 ---------------------------------------------------------------------

1 0

Notation for delegation in OMT or BOOCH
by Reto Kramer 14 Jul '94

14 Jul '94

I am looking for a notation for delegation in OO-Methods. I known OMT quite well but could not find any notation for delegation (there is one for propagation but this does not have the semantics, delegation provides). In BOOCH, I could not find any notation either though he speeks about delegation. In OBA, I could not find anything either. Delegation is very important for us because: a) we only have single inheritance due to Smalltalk and thus we rely on it to replace multiple inheritance b) delegation is just as important as inheritance (multiple or not) and we often use it's semantic per se I thought about extending the Smalltalk metaprotocol (I use ParcPlace) to include support for delegation as well as aggregation (with propagation). Did anybody do this already (maybe in SELF or CLOS) ? I would appreciate any comments on this. PS: since I only have the published OMT books (original hardcover 1991 and the later red paperback), I miss the extensions that have been published in JOOP (by Rumbaugh himself I heared). If anybody could help me on how to get a copy of those extensions I'd send him a postcard from by next holiday ! Reto --- Reto Kramer ESEC SA Dept. Autoline Hinterbergstr. 32 CH-6330 Cham Switzerland EMAIL: kramer(a)acm.org

1 0

unification
by trb＠cs.mu.OZ.AU 12 Jul '94

12 Jul '94

In my previous posting I missed some important points. If there are no side-effects in methods, and the order of statements is not important, then it is only necessary to add a trail for each local variable in order to support backtracking. In an expressive OO language like self, a trail can be implemented easily using standard data-structure classes. When this is done, the result is a real logic language for writing methods. Self can then be called an OO-LP language! The semantics might even turn out to be declarative. PARLOG++ is an OO-LP language that maintains mutable state by modelling objects as predicates that call themselves recursively, continually passing their own state back to themselves (thus the state can only be modified at the end of an inference). Because the state arises from the recursive calls it has proper logical semantics (the semantic base of PARLOG is a bit dubious, but this is the fault of PARLOG alone - not the OO part). The state that is modeled in this way is only simulated state, although it behaves just like real state! Perhaps this scheme could be run in reverse for Self+LP. In this case the state is real, but we might be able to arrange for it to behave just like the simulated state in PARLOG++. Then we could pretend that the state is just simulated, and reason about the language as if it had full logical semantics. If the illusion is perfect then the language really will have logical semantics!

1 0

Re: mailing list
by Randall.Smith＠eng.sun.com 12 Jul '94

12 Jul '94

Tim -- Interesting ideas on unifying unification into Self! Don't quite know how to unify two Self objects ... the slot by slot thing is a reasonable idea, but could you just send "=" to the objects and see if they think they are equal? Thanks for your thoughts, --Randy

2 1

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 1994