I must also say that even after programming in Smalltalk for years, I never missed not having cascades in Self. Maybe they just don't happen that often?
At any rate, though they are a (possibly rare) convenience, having cascades would further distance Self from the Java/C programmer. (I have become of the opinion that some sort of pretty obvious syntax is almost a necessity for a language's acceptance. Java passed this hurdle by essentially re-using C/C++ syntax.)
--Randy
From self-interest-return-287-Randall.Smith=Eng.Sun.COM@returns.egroups.com Mon Aug 30 12:47 PDT 1999 Mailing-List: contact self-interest-owner@egroups.com X-Mailing-List: self-interest@egroups.com X-URL: http://www.egroups.com/list/self-interest/ Delivered-To: listsaver-egroups-self-interest@egroups.com Date: Mon, 30 Aug 1999 16:45:17 -0300 From: Jecel Assumpcao Jr jecel@lsi.usp.br MIME-Version: 1.0 To: self-interest@egroups.com Subject: [self-interest] Re: Grammar changes - comments? Mime-Version: 1.0 Content-Transfer-Encoding: 7bit
Using the "." for resends was a very unfortunate decision, and your idea to replace it with "$" is a good one. I had suggested using "::" since several other languages already use that for similar purposes and Java (and Beta, in a negative way) showed how important it is to have familiar elements in the syntax.
About the cascades, you would need a "dup" bytecode (but since you already were going to add it anyway this is no big deal). I have never missed it when programming in Self, however.
-- Jecel
Get help getting gigs! Guru.com will make your freelance work more lucrative and more fun. Join us as we create the Internet's best resource for independent professionals. http://clickhere.egroups.com/click/804
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
Randall.Smith@Eng.Sun.COM (Randy Smith) wrote:
(I have become of the opinion that some sort of pretty obvious syntax is almost a necessity for a language's acceptance. Java passed this hurdle by essentially re-using C/C++ syntax.)
A number of other dynamic scripting languages have also taken up the C++ prefix message syntax.
Python: target.message() Lua: target.message() Perl: target::mesage() Java: target.message()
This isn't so bad either if you follow the convention that the colons from the infix message format are replaced by underscores. For example:
dog fetch:stick andBringTo:me
translates to:
dog.fetch_andBringTo_(stick, me)
Has anyone considered supporting this syntax in one of the new Self clones? It would also make automatic translation of Java(or Python, etc.) code to Self code a bit easier.
I don't know about the other Self fans out there, but my attraction to Self has to do with the power of it's namespace and object model, not it's syntax.
Steve
Steve Dekorte wrote:
A number of other dynamic scripting languages have also taken up the C++ prefix message syntax.
As far as I can tell, this syntax originated with Apple's Object Pascal (I don't know what Simula looked like). Since the idea was that objects were extended versions of records, it made sense to adapt the record field access sytanx for message sending.
Note that a number of easy to use languages don't have this style of syntax: Logo, HyperScript, Rebol...
In Smalltalk-72 and -74 you could define your own syntax for message sends and people tried a number of different styles. When they had to choose a fixed grammer for Smalltalk-76 (in order to be able to translate to bytecodes), Dan Ingalls looked at what everybody had been doing and mixed the best ideas into the grammar that is still with us in Self. This is a very powerful design method.
Has anyone considered supporting this syntax in one of the new Self clones?
I think NewtonScript did, though it is an old Self clone.
It would also make automatic translation of Java(or Python, etc.) code to Self code a bit easier.
Not really, unless you can avoid parsing the source language.
Please note that I think syntax doesn't matter - the future of Self is to be more and more graphical. Outliners, for example, have eliminated the need to bother with slot declaration syntax for the most part (though they could do a better job). The syntax for sending messages to object will probably go the same way eventually.
-- Jecel
At 06:30 AM 8/31/99 , Jecel Assumpcao Jr wrote:
Steve Dekorte wrote:
A number of other dynamic scripting languages have also taken up the C++ prefix message syntax.
As far as I can tell, this syntax originated with Apple's Object Pascal (I don't know what Simula looked like).
As I recall, Simula looked pretty much the same. And any language that combined the common record selection syntax, the common function/procedure call syntax and first class functions/procedures ends up with the same thing.
Please note that I think syntax doesn't matter - the future of Self is to be more and more graphical. Outliners, for example, have eliminated the need to bother with slot declaration syntax for the most part (though they could do a better job). The syntax for sending messages to object will probably go the same way eventually.
Concrete syntax shouldn't matter very much, but it does. Most programmers cannot distinguish between a language and its concrete syntax. Java was originally marketed as a C++ variant, even though it's dynamic semantics are closer to Smalltalk.
BTW, I am sure that textual syntax for expressions will be with us for a very long time.
While I'm on the topic: Smalltalk syntax has one minor property that is kind of nice - it is impossible to give the wrong number of arguments. On the other hand, it makes supporting optional arguments awkward.
Cheers, Gilad
********************************************* Gilad Bracha Computational Theologist Sun Java Software http://java.sun.com/people/gbracha/
[syntax variants]
Has anyone considered supporting this syntax in one of the new Self clones?
For mySelf, I'd like to define the VM layer and then unrelated to it (if that's possible) the mySelf language layer. There're probably a few connection points, but hopefully few enough to easily allow to change the compiler.
It would also make automatic translation of Java(or Python, etc.) code to Self code a bit easier.
Why would you like to do such a translation?
Instead, I'd like to interface at least Java code. At the moment, my plan is to do a mySelf prototype in Java. My goal (just a little goal, I know) is to be able to interface with Swing to allow a Swing GUI to call back mySelf objects for ActionListeners etc.
In theory, it should be possible to interface any existing Java class library. Unfortunately, this is just a plan right now as my time only permits a few hours of work every weekend.
Some along the lines
| f b | f: java awt JPanel new. b: java awt JButton new: ('click me'). b addActionListener: [| :ev | "..."] asActionListener. f add: b. f show
would be really cool IMHO. While I've already a rough idea how to implement the normal java class and java instance objects, I'm still unsure how to do the callback. The 'asActionListener' would do the ugly work to setup some Java adapter class which known how to forward an actionPerformed() to the Self block object.
bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.
Steve Dekorte wrote:
I don't know about the other Self fans out there, but my attraction to Self has to do with the power of it's namespace and object model, not it's syntax.
I think so, too. Self has a simple and general object model which makes it elegant. The object model is almost as expressive as the much hyped and never come out "object model" of Cyc. And it consists only of communicating objects - no classes, no variables.
What I also like about Self, and Smalltalk/V was the kind of "multi language paradigm". Some things can be expressed more easily with one grammar, some with another. IMHO most of the "grand unified languages" become some sort of clumsy at certain problems.
Well, when thinking about Self as an object model, I would like to propose the following extensions to the Self system:
1) Allow arbitrary objects as object annotations. There are several different aspects of "declarative knowledge" embedded into annotations other than pure comments. Putting them into regular objects would provide a clean interface for adding other interesting types of annotations to slots. Imagine, you could put some sort of assertions into the annotation, or you could descibe some high level mathematical properties of your objects with the annotation. (BTW, an optimizing compiler could use this information to generate good code out of this) This would open a "dual space" - some kind of declarative counterpart - to the otherwise purely behavioral "knowledge" of self programs. The question I ask myself is, should these annotations be just like Self objects used to be, or should they be a kind of special objects (say: functions, clauses) designed to represent declarative knowledge. (BTW, this is a complementary approach to mirrors which try to separate behavioral and declarative aspects, whereas annotations try to integrate these aspects possible)
2) Replace bytecodes by something else. When you have a look at the Self object system, there is objects and messages. No classes, no variables, nothing that's not absolutely necessary. And it is implemented efficiently with tagged pointers, maps, objects ond the heap and on the stack, and a lot of other things. When I have a look at the Self bytecodes, I feel that it is an efficient implementation of something else. Well, I think I owe you the answer what this might be. I have to admit that I do not have a clear answer to this right now. It seems to be something like an abstract syntax tree. It currently has only two kinds of nodes: a send (which is directed either to nobody special or to the result of another send, and takes some arguments which are sends in turn), and a sequence operator that performs several sends one after another. This is the basic functionality of sequential programs. Looks like the behavioral counterpart of the lambda calculus. What would happen if you added nodes like receive or a parallel operator, as they are found f.e. in Occam? What is a relationship between a channel, a receive, and an object?
What do you think about these ideas?
Gordon.
My 2 cents:
I "totally" like keyword messages. I got used to it using Objective-C and I now believe that it makes code very readable.
Dru Nelson San Mateo, California
Just a quick note: Self already allows arbitrary objects as object annotations. (& slot annotations, too). The environment uses this feature to implement the transporter, and it should extensible to other uses, as well.
- Dave
At 9:03 PM +0200 9/2/99, Gordon Cichon wrote:
Steve Dekorte wrote:
I don't know about the other Self fans out there, but my attraction to Self has to do with the power of it's namespace and object model, not it's syntax.
I think so, too. Self has a simple and general object model which makes it elegant. The object model is almost as expressive as the much hyped and never come out "object model" of Cyc. And it consists only of communicating objects - no classes, no variables.
What I also like about Self, and Smalltalk/V was the kind of "multi language paradigm". Some things can be expressed more easily with one grammar, some with another. IMHO most of the "grand unified languages" become some sort of clumsy at certain problems.
Well, when thinking about Self as an object model, I would like to propose the following extensions to the Self system:
- Allow arbitrary objects as object annotations.
There are several different aspects of "declarative knowledge" embedded into annotations other than pure comments. Putting them into regular objects would provide a clean interface for adding other interesting types of annotations to slots. Imagine, you could put some sort of assertions into the annotation, or you could descibe some high level mathematical properties of your objects with the annotation. (BTW, an optimizing compiler could use this information to generate good code out of this) This would open a "dual space" - some kind of declarative counterpart - to the otherwise purely behavioral "knowledge" of self programs. The question I ask myself is, should these annotations be just like Self objects used to be, or should they be a kind of special objects (say: functions, clauses) designed to represent declarative knowledge. (BTW, this is a complementary approach to mirrors which try to separate behavioral and declarative aspects, whereas annotations try to integrate these aspects possible)
- Replace bytecodes by something else.
When you have a look at the Self object system, there is objects and messages. No classes, no variables, nothing that's not absolutely necessary. And it is implemented efficiently with tagged pointers, maps, objects ond the heap and on the stack, and a lot of other things. When I have a look at the Self bytecodes, I feel that it is an efficient implementation of something else. Well, I think I owe you the answer what this might be. I have to admit that I do not have a clear answer to this right now. It seems to be something like an abstract syntax tree. It currently has only two kinds of nodes: a send (which is directed either to nobody special or to the result of another send, and takes some arguments which are sends in turn), and a sequence operator that performs several sends one after another. This is the basic functionality of sequential programs. Looks like the behavioral counterpart of the lambda calculus. What would happen if you added nodes like receive or a parallel operator, as they are found f.e. in Occam? What is a relationship between a channel, a receive, and an object?
What do you think about these ideas?
Gordon.
FREE 30 DAY TRIAL FOR EGROUPS MEMBERS: Portera Tracker - all you need for bug & issue tracking. Access over the web & customize in minutes! TRY IT FREE NOW! http://clickhere.egroups.com/click/847
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
David Ungar Sun Microsystems Laboratories (650) 336-2618
David Ungar wrote:
Just a quick note: Self already allows arbitrary objects as object annotations. (& slot annotations, too). The environment uses this feature to implement the transporter, and it should extensible to other uses, as well.
Please correct me, if I'm wrong: The object system itself would allow arbitrary objects as annotations, the parser does not, and the transporter relies on the convention that the annotation string contains a list of 'playload' strings which are separated with character '\177'. The parser contains explicit checks for annotation objects being strings.
F.e., look at files 'vm/parser/expr.c' and 'vm/parser/parser.c': There is a member called 'extend_annotation' (expr.c:270) that builds this list of strings inside a single annotation string, and there are things like:
if (t->type != STRING) { expecting(t, "a string containing an annotation"); return 0; }
(parser.c:295), and (parser.c:600).
Gordon.
Great to see such familiarity with the system! You are quite right. Of course, there are ways to get arbitrary objects in there without extending the parser, though with your VM expertise, you could also extend the parser. And the transporter only relies on that convention for unparsed annotations. After the module is filled, there are objects in there, that could be extended. Anyway, that's all malleable Self code. I'm sure you could get it to do whatever you needed.
- Dave
At 11:23 AM +0200 9/4/99, Gordon Cichon wrote:
David Ungar wrote:
Just a quick note: Self already allows arbitrary objects as object annotations. (& slot annotations, too). The environment uses this feature to implement the transporter, and it should extensible to other uses, as well.
Please correct me, if I'm wrong: The object system itself would allow arbitrary objects as annotations, the parser does not, and the transporter relies on the convention that the annotation string contains a list of 'playload' strings which are separated with character '\177'. The parser contains explicit checks for annotation objects being strings.
F.e., look at files 'vm/parser/expr.c' and 'vm/parser/parser.c': There is a member called 'extend_annotation' (expr.c:270) that builds this list of strings inside a single annotation string, and there are things like:
if (t->type != STRING) { expecting(t, "a string containing an annotation"); return 0; }
(parser.c:295), and (parser.c:600).
Gordon.
Don't know which one to buy? Productopia does. http://clickhere.egroups.com/click/554
eGroups.com home: http://www.egroups.com/group/self-interest http://www.egroups.com - Simplifying group communications
David Ungar Sun Microsystems Laboratories (650) 336-2618
Hi,
gordon cichon gordo-@cichon.de wrote: original article:http://www.egroups.com/group/self-interest/?start=323
Steve Dekorte wrote:
I don't know about the other Self fans out there, but my attraction
to
Self has to do with the power of it's namespace and object model,
not
it's syntax.
Well, I think I owe you the answer what this might be. I have to admit that I do not have a clear answer to this right now. It seems to be something like an abstract syntax tree.
I'm not sure if I get your point, but this company named micro.... (you will know what I mean;-) tried to do something like this but language independent. The name for this stuff is IP means Intentional Programming and you can get some infos at: http://www.research.microsof t.com/ip/
cu
Thorsten Dittmar
On Tue, 16 Nov 1999 thorsten.dittmar@daedalos.com wrote:
I'm not sure if I get your point, but this company named micro.... (you will know what I mean;-) tried to do something like this but language independent. The name for this stuff is IP means Intentional Programming and you can get some infos at: http://www.research.microsof t.com/ip/
Yes, this company you are talking about has always been very innovative at extracting other people's ideas and reimplementing it by themselves.
I by myself have serious concerns doing development on a platform whose IP (intellectual property) is owned by another company who has a rich tradition of copying other people's ideas as soon as it turns out that they are good. Going this way, your IP is only valuable in conjunction with the platform, and if your development was too good, you don't have a chance as soon as your platform chooses not to support you any more.
I personally believe that the way COM differentiates from CORBA is that Microsoft took into account the Self object model while OMG did not. So if you wanted to integrate you work in Self into an exteriour OO framework, you would get readily supported by COM, while with CORBA you would shoot yourself in the knee.
Some years ago I thought about implementing a Self system on top of COM. After a few experiments, I discontiuned this approach tough, for political as well as technical reasons. I heard that COM had been patented, and at this time it came to the public how Microsoft treats their "competition". On the other side, COM still has some serious problems with memory management which I concluded was too tedious to fix them without source code. (BTW, I can also release this code if anybody likes to have it although I assume that hardly anybody could read it besides me)
Gordon.
self-interest@lists.selflanguage.org
-
David Ungar -
Dru Nelson -
Gilad Bracha -
Gordon Cichon -
Jecel Assumpcao Jr -
Randall.Smith＠Eng.Sun.COM -
Stefan Matthias Aust -
Steve Dekorte -
thorsten.dittmar＠daedalos.com