Good stuff, Brook--!
Rainer, I'll try to explain my viewpoint one last time:
I believe that whether or not you like macros depends a lot on your background and expectations.
If you are mathematically grounded and inclined, you may see computer programs as rewriting systems sort of like proofs. There is a whole tradition in CS, starting with (pure) Lisp that springs from this well, and it has contributed a lot. Macros fit in fine here, just another way to do rewriting. It's fine with me for suitably inclined, educated, and abled folks to take this viewpoint, but I (and in my opinion many others) are unable to.
If you come from physics, or your early exposure was to interpreted languages like APL, or ST, you are likely to feel that working with a computer is about the direct & immediate manipulation of stuff--objects, matrices, etc-- and macros seem silly. After all, the base language already lets me extend the behavior of the computer, adding a second step, another execution model, just complicates things. In this school, you hope that the syntax is bearable enough not to need extension-- after all English speakers manage pretty well with those 26 letters-- and you try to build extensible semantics in the language. (Blocks are a great example here.) You also try to build an implementation that supports this. With our implementation the sort of "if: bool Then: b1 Else: b2" method runs as fast as a macro--in fact we beat Lisps in benchmarks. So, you trade off simplicity of language and execution model against some amount of low-level extensisibilty and complexity in the implementation. That's why Self is as it is (IMHO)--Randy will have a different view.
As far as assignment is concerned--I am more interested in building things with objects than inside of them. But my favorite treatment of this area may well be Glyphic's, by Mark Leczner (sp?). Again, my values are simplicity and explainability. I don't give a fig for expressive power beyond what Self already has. I have even toyed with reducing Self a bit--but all these types of arguments generally bottom out on assumptions about how frequently certain kinds of programs will be written, and that is very, very subjective. Personally, I listen to (in no particular order) Randy, Peter, Mario, and of course, Ole Madsen (and others-- please don't feel bad if I forgot to include you) I feel that I share their values and trust their clarity of vision. Ole in particular has had many many years of experience (himself and through working with his colleagues) in OO stuff, and the Beta (and I guess Simula) folks seem to have more experience in the statically-typed OO area than anybody.
Rainer, I will leave you with one last thought-- my worst mistakes have always resulted from being too clever.
- Dave
-- Dave
Dave, you wrote:
[...] working with a computer is about the direct & immediate manipulation of stuff
Right. Right. Right.
and macros seem silly.
Not always. The way I use them in Lisp, they make for better readability of code. I admit that learning to write macros is difficult. So silly or not not depends on the base language. As you say:
After all, the base language already lets me extend the behavior of the computer, adding a second step, another execution model, just complicates things. In this school, you hope that the syntax is bearable enough not to need extension [...]
And that's the point, the difference between Self and Lisp, exactly. The symbol `lambda' alone renders Scheme code with blocks alias closures hard to read and discourages their widespread use. That's why Lisp just _needs_ special forms. You solved this by substituting a different brand of parentheses for the symbol.
As far as assignment is concerned-- [...] But my favorite treatment of this area may well be Glyphic's, by Mark Leczner (sp?).
Any _net_ pointers?
Rainer, I will leave you with one last thought-- my worst mistakes have always resulted from being too clever.
That's a good one, thank you for it.
Rainer
self-interest@lists.selflanguage.org