www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Arbitrary operators for overloading?

reply Traveler hauptman <Traveler_member pathlink.com> writes:
I just got done reading the flam.. er.. discussion on value assignment with :=.

Whether I want value assignment as a language feature is secondary. Far more
important is overloading operators for readable code. 
---
//a,b,c = allocated objects

c := a + b; //readable  
c.copy(add(a,b)); //not so readable
---

I propose the only reason to allow overloading is to let programmers get their
greasy fingers on infix syntax for functions.

So why not make it a real feature?

Allow arbitrary operators to be defined for infix, prefix and postfix functions
in expressions!
A declaration could be placed either at the module level or the class level.
I don't write compilers so be gentle the syntax that follows. A new arbitrary
operator overload might look like:

operator (char[] opName,char[]
opstring,UNARY|BINARY,COMMUNATIVE|NOT_COMMUNATIVE);



operator ("opSwap","<->",BINARY,NOT_COMMUNATIVE); //suggested by someone
sometime
class Foo{
Foo opOctoAt(Foo a){};
Foo opSwap(Foo a){};
Foo opOctoAt_r(Foo a){};
}
..
Foo a = new Foo;
Foo b = new Foo;


a <-> b;  //a.opSwap(b);

with >>>= we are already ok with looking for operators of up to 4 characters.

(I see $ is in the token list, I should look around for what it's used for) 

I'm guessing that all this requires is adding some entries during compile time
to a token<->opFuncName table that already exists somewhere.

Did I write down enough to get the idea across? Does it make sense?

PS. I don't think saving programmers from creating hideous looking expressions
is an issue here. Poor code writers will always create bad comments, variable
names, overloads, and control structures.



-Traveler Hauptman
Sep 20 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <dgplns$1ltv$1 digitaldaemon.com>, Traveler hauptman says...

I just got done reading the flam.. er.. discussion on value assignment with :=.

Whether I want value assignment as a language feature is secondary. Far more
important is overloading operators for readable code. 
---
//a,b,c = allocated objects

c := a + b; //readable  
c.copy(add(a,b)); //not so readable
---

I propose the only reason to allow overloading is to let programmers get their
greasy fingers on infix syntax for functions.

So why not make it a real feature?

Allow arbitrary operators to be defined for infix, prefix and postfix functions
in expressions!


I can think of a few potential issues offhand.  The lexer would have to be able
to recognize these new operators as valid symbols, and some character sequences
must be invalid.  Say I define a new operator as "?:" or "{" for example.  Also,
it would probably be necessary to allow some means to define operator precedence
for these new operators, and precedence is easy to get wrong.  That said, I
think such a feature has the potential to allow programmers to more easily deal
with complex problem sets and to totally obfuscate code :-)


Sean
Sep 20 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Sean Kelly wrote:

[...]

 That said, I think such a feature has the
 potential to allow programmers to more easily deal with complex
 problem sets and to totally obfuscate code :-) 


Why obfuscate? Traveler only wants to integrate into D a mechanism 
for changing the lexer and the parser on the fly and immediately use 
that changes. That can be used to make the code very simple instead 
of obfuscating it.

However I do not have any clue how to implement and use such great 
extension. Traveler must have an ingenious mind because he uses an 
expression to change the lexer and parser for expressions.

Let me present a vision: after Walter having spent a weekend for 
implementing this mechanism and some years of getting used to become 
ingenious minds also, in a glorious strike we will come up with a 
finite state machine capable of reading and writing on a virtual tape 
of infinite length. Will this machine be called hauptman-machine?

-manfred
Sep 21 2005
parent reply Traveler Hauptman <th barrett.com> writes:
Wow, I didn't expect people to be afraid of this idea... ;)

We brashly let people choose their own varaible names (within a subset of 
characters). And they choose good names and bad names. To rob from the NRA:
programming languages don't make bad code, programmers do.

And we already let people overload operators... so extend the functionality.

That said, I looked at D's lexer & parser for the first time. I haden't
realized 
the lexer was hard-coded. I conceed it would be a lot of work to change.

-traveler


Manfred Nowak wrote:

 
 Why obfuscate? Traveler only wants to integrate into D a mechanism 
 for changing the lexer and the parser on the fly and immediately use 
 that changes. That can be used to make the code very simple instead 
 of obfuscating it.
 
 However I do not have any clue how to implement and use such great 
 extension. Traveler must have an ingenious mind because he uses an 
 expression to change the lexer and parser for expressions.
 
 Let me present a vision: after Walter having spent a weekend for 
 implementing this mechanism and some years of getting used to become 
 ingenious minds also, in a glorious strike we will come up with a 
 finite state machine capable of reading and writing on a virtual tape 
 of infinite length. Will this machine be called hauptman-machine?
 
 -manfred


zwang wrote:

 You can take the idea one step further and make every token overloadable
 to encourage people to create their own little languages highly readable
 by themselves only.
Sep 22 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
Traveler Hauptman wrote:

 Wow, I didn't expect people to be afraid of this idea... ;)
 
 We brashly let people choose their own varaible names (within a subset 
 of characters). And they choose good names and bad names. To rob from 
 the NRA:
 programming languages don't make bad code, programmers do.
 
 And we already let people overload operators... so extend the 
 functionality.
 
 That said, I looked at D's lexer & parser for the first time. I haden't 
 realized the lexer was hard-coded. I conceed it would be a lot of work 
 to change.
 
 -traveler
 
 
 Manfred Nowak wrote:
 

 Why obfuscate? Traveler only wants to integrate into D a mechanism for 
 changing the lexer and the parser on the fly and immediately use that 
 changes. That can be used to make the code very simple instead of 
 obfuscating it.

 However I do not have any clue how to implement and use such great 
 extension. Traveler must have an ingenious mind because he uses an 
 expression to change the lexer and parser for expressions.

 Let me present a vision: after Walter having spent a weekend for 
 implementing this mechanism and some years of getting used to become 
 ingenious minds also, in a glorious strike we will come up with a 
 finite state machine capable of reading and writing on a virtual tape 
 of infinite length. Will this machine be called hauptman-machine?





 You can take the idea one step further and make every token overloadable
 to encourage people to create their own little languages highly readable
 by themselves only.


LOL!

This is exactly what I've been brewing. Remember, early this year I 
raved about a higher level of language on top of D, instead of C 
preprocessors and the C++ template mess. The examples I wrote were 
precisely thought of as possible if:

  - We can change the lexer and parser "on the fly"
  - Make these changes scoped, to control visibility
  - Come up with a language for this, which should be
  -  - lambda capable
  -  - yet easy for mortals to grasp and use
  -  - fit nicely with D source overall

For (reasons of pride, not rational reasons) we might develop a language 
of our own for this. The current D template mechanism, with its static 
ifs and things, is already on its way to become such a language. But 
that's approaching it from the wrong end, which will only end up (much 
later in time) like the C++ pp-monster.

The right end here is top-down. And there already exist several good 
candidates to use as a basis. Many recent languages are almost invented 
for what we want to use them for! And their licences do allow us to use 
them, even commercially. And then there are of course old languages 
(like Lisp) available too -- but we don't want to all become R. 
Stallmans. :-)

Anyway, we now have 2 1/2 levels of language here, in D.

  - in-line assembly
  - D core language
  - the template mechanism

What we need to do, is make it a proper 3.

(Heh, not to mention D+HTML all along, and now even the documentation 
syntax -- but they don't count here.)

With this high-level language we should be able to create our own 
one-shot languages for specific purposes. (So the end result would be 
more like 3+n languages. :-) See my postings Jan-Apr this year.)

Anybody opposed to this should read chapter 9, Notation, in Kernighan & 
Pike: The Practice of Programming. A quote:

"If you find yourself writing too much code to do a mundane job, or if 
you have trouble expressing the process comfortably, maybe you're using 
the wrong language. If the right language doesn't yet exist, that might 
be an opportunity to create it yourself. Inventing a language doesn't 
necessarily mean building the successor to Java; often a thorny problem 
can be cleared up by changing the notation."

I see a convergence happening ever since last winter. The Language 
Machine, the D template system, the D front-end starter kit, new small 
but immensely expressive scripting languages, and a growing consensus 
that we need something like this. We're almost there.

Just imagine all the mathematicians reading this, and D already 
supporting (http://www.digitalmars.com/d/entity.html) some funny 
characters. And the nuclear physicists, embedded firmware developers, 
logic programmers, and even ordinary programmers converting reams of 
header files from C/C++ with hundreds of almost-alike lines of code.

Of course, then we could have some code that's unreadable to most. 
Tough, ain't it? Then again, I've always seen some guys write code 
that's unreadable, no matter what the programming language was. (Had to 
fire one such the other year.) And most of Boost looks to me like XML 
anyway, so what's the difference?

----

I'm working on this, but some competition, and/or help would be good. I 
bet some of the younger guys here could cook this up in half the time it 
takes an old fart. ;-)

----

OH, and for the record: I do admire Walter's template system! No problem 
there! It works, is easy enough to use, as we all know. But why climb 
the hill when you can learn to fly?
Sep 23 2005
next sibling parent Sean Kelly <sean f4.ca> writes:
In article <43349CC4.7060109 nospam.org>, Georg Wrede says...

OH, and for the record: I do admire Walter's template system! No problem 
there! It works, is easy enough to use, as we all know. But why climb 
the hill when you can learn to fly?


Agreed.  Since templates can be used for code generation, why not simplify the
process?  D is better off than C++ in this respect, but still a bit lacking.  I
would love to see the template language evolve into something a bit more broadly
applicable (and succinct).  Built-in support for list operations (like Lisp)
would be a great start, along with some guarantees for recursion depth and such.


Sean
Sep 23 2005
prev sibling parent reply J Thomas <jtd514 ameritech.net> writes:
sounds like what you are talking about is a meta-language for 
metaprogramming. (no not C++ template metaprogramming) are you familiar 
with metaprogramming systems like openc++? this is a pretty 
straightforward concept and i think it could be done quite well in c, 
especially since its such a dream to parse. I am eventually going to 
implement my own meta-programming system on top of D, it could be done 
pretty easilly with the front end code. Im waiting to see where hes 
going to go with reflection

Georg Wrede wrote:

 Traveler Hauptman wrote:
 

 Wow, I didn't expect people to be afraid of this idea... ;)

 We brashly let people choose their own varaible names (within a subset 
 of characters). And they choose good names and bad names. To rob from 
 the NRA:
 programming languages don't make bad code, programmers do.

 And we already let people overload operators... so extend the 
 functionality.

 That said, I looked at D's lexer & parser for the first time. I 
 haden't realized the lexer was hard-coded. I conceed it would be a lot 
 of work to change.

 -traveler


 Manfred Nowak wrote:


 Why obfuscate? Traveler only wants to integrate into D a mechanism 
 for changing the lexer and the parser on the fly and immediately use 
 that changes. That can be used to make the code very simple instead 
 of obfuscating it.

 However I do not have any clue how to implement and use such great 
 extension. Traveler must have an ingenious mind because he uses an 
 expression to change the lexer and parser for expressions.

 Let me present a vision: after Walter having spent a weekend for 
 implementing this mechanism and some years of getting used to become 
 ingenious minds also, in a glorious strike we will come up with a 
 finite state machine capable of reading and writing on a virtual tape 
 of infinite length. Will this machine be called hauptman-machine?




 
 

 You can take the idea one step further and make every token overloadable
 to encourage people to create their own little languages highly readable
 by themselves only.


 
 
 LOL!
 
 This is exactly what I've been brewing. Remember, early this year I 
 raved about a higher level of language on top of D, instead of C 
 preprocessors and the C++ template mess. The examples I wrote were 
 precisely thought of as possible if:
 
  - We can change the lexer and parser "on the fly"
  - Make these changes scoped, to control visibility
  - Come up with a language for this, which should be
  -  - lambda capable
  -  - yet easy for mortals to grasp and use
  -  - fit nicely with D source overall
 
 For (reasons of pride, not rational reasons) we might develop a language 
 of our own for this. The current D template mechanism, with its static 
 ifs and things, is already on its way to become such a language. But 
 that's approaching it from the wrong end, which will only end up (much 
 later in time) like the C++ pp-monster.
 
 The right end here is top-down. And there already exist several good 
 candidates to use as a basis. Many recent languages are almost invented 
 for what we want to use them for! And their licences do allow us to use 
 them, even commercially. And then there are of course old languages 
 (like Lisp) available too -- but we don't want to all become R. 
 Stallmans. :-)
 
 Anyway, we now have 2 1/2 levels of language here, in D.
 
  - in-line assembly
  - D core language
  - the template mechanism
 
 What we need to do, is make it a proper 3.
 
 (Heh, not to mention D+HTML all along, and now even the documentation 
 syntax -- but they don't count here.)
 
 With this high-level language we should be able to create our own 
 one-shot languages for specific purposes. (So the end result would be 
 more like 3+n languages. :-) See my postings Jan-Apr this year.)
 
 Anybody opposed to this should read chapter 9, Notation, in Kernighan & 
 Pike: The Practice of Programming. A quote:
 
 "If you find yourself writing too much code to do a mundane job, or if 
 you have trouble expressing the process comfortably, maybe you're using 
 the wrong language. If the right language doesn't yet exist, that might 
 be an opportunity to create it yourself. Inventing a language doesn't 
 necessarily mean building the successor to Java; often a thorny problem 
 can be cleared up by changing the notation."
 
 I see a convergence happening ever since last winter. The Language 
 Machine, the D template system, the D front-end starter kit, new small 
 but immensely expressive scripting languages, and a growing consensus 
 that we need something like this. We're almost there.
 
 Just imagine all the mathematicians reading this, and D already 
 supporting (http://www.digitalmars.com/d/entity.html) some funny 
 characters. And the nuclear physicists, embedded firmware developers, 
 logic programmers, and even ordinary programmers converting reams of 
 header files from C/C++ with hundreds of almost-alike lines of code.
 
 Of course, then we could have some code that's unreadable to most. 
 Tough, ain't it? Then again, I've always seen some guys write code 
 that's unreadable, no matter what the programming language was. (Had to 
 fire one such the other year.) And most of Boost looks to me like XML 
 anyway, so what's the difference?
 
 ----
 
 I'm working on this, but some competition, and/or help would be good. I 
 bet some of the younger guys here could cook this up in half the time it 
 takes an old fart. ;-)
 
 ----
 
 OH, and for the record: I do admire Walter's template system! No problem 
 there! It works, is easy enough to use, as we all know. But why climb 
 the hill when you can learn to fly?
Sep 23 2005
next sibling parent J Thomas <jtd514 ameritech.net> writes:
oops i meant D not c

J Thomas wrote:

 sounds like what you are talking about is a meta-language for 
 metaprogramming. (no not C++ template metaprogramming) are you familiar 
 with metaprogramming systems like openc++? this is a pretty 
 straightforward concept and i think it could be done quite well in c, 
 especially since its such a dream to parse. I am eventually going to 
 implement my own meta-programming system on top of D, it could be done 
 pretty easilly with the front end code. Im waiting to see where hes 
 going to go with reflection
Sep 23 2005
prev sibling parent reply Georg Wrede <georg.wrede nospam.org> writes:
J Thomas wrote:

 sounds like what you are talking about is a meta-language for 
 metaprogramming. (no not C++ template metaprogramming) are you
 familiar with metaprogramming systems like openc++?


I looked at OpenC++ a couple of years ago. I did like the idea, and
wished for something like it for D. Now that we have the Language
Machine, starting a metaprogramming project should be trivial!


 this is a pretty straightforward concept and i think it could be done
 quite well in D, especially since its such a dream to parse. I am
 eventually going to implement my own meta-programming system on top
 of D, it could be done pretty easilly with the front end code. Im
 waiting to see where hes going to go with reflection


I definitely see a modified D front end as the goal. Before that, I 
presume it would be easy to do initial experiments with proposals to the 
metalanguage details with a D-to-D translator.

I'd love to see a way of attaching arbitrary properties to syntax tree 
nodes. These could be used to all kinds of things. For example, if the 
programmer is into functional programming, then the knowledge of side 
effects in a function would be crucial.

In any case, the meta-machine has to both have access to compile-time 
structures and objecs, and also has to be able to change the tree. I 
expect this to be less dangerous than what folks think. :-)

Another benefit is that new things in D could thus be easily tried out. 
This would free Walter to see whether any such actually get popular 
enough to warrant hard coding them. In other words, we could have an 
actual feature freeze between major versions, and end up Knowing what we 
add to the language.
Sep 25 2005
parent reply J Thomas <jtd514 ameritech.net> writes:
right on, yah i tried working with openc++ a couple years ago until i 
realized it was a total mess. and on further reflection i think its just 
not worth the hastle of parsing c++ for metaprogramming - so i thought 
about building a new c-type langauge for mettaprogramming when I found 
D. D is fantastic, plus its been designed to *parse* easilly which opens 
up a whole range of possibilities. im going to have to look at the 
language machine a little more but yah, the first thing i thought of 
when i heard about it was metaprogramming. it would be very cool to get 
a metaprogramming front end for D going, as you said i think it could 
greatly help language development, as people could more easilly "try 
out" their own extensions. at this point im finishing up little debugger 
in D, as all my other debuggers seem to be a hastle to use for D apps, 
and im still getting used to the language. but I plan on doing some sort 
of metaobject protocol for D before I do anything real serious. I think 
D with metaobjects could be one of the most powerfull tools ive ever 
seen. for me anyway...


Georg Wrede wrote:

 J Thomas wrote:
 

 sounds like what you are talking about is a meta-language for 
 metaprogramming. (no not C++ template metaprogramming) are you
 familiar with metaprogramming systems like openc++?


 
 
 I looked at OpenC++ a couple of years ago. I did like the idea, and
 wished for something like it for D. Now that we have the Language
 Machine, starting a metaprogramming project should be trivial!
 

 this is a pretty straightforward concept and i think it could be done
 quite well in D, especially since its such a dream to parse. I am
 eventually going to implement my own meta-programming system on top
 of D, it could be done pretty easilly with the front end code. Im
 waiting to see where hes going to go with reflection


 
 
 I definitely see a modified D front end as the goal. Before that, I 
 presume it would be easy to do initial experiments with proposals to the 
 metalanguage details with a D-to-D translator.
 
 I'd love to see a way of attaching arbitrary properties to syntax tree 
 nodes. These could be used to all kinds of things. For example, if the 
 programmer is into functional programming, then the knowledge of side 
 effects in a function would be crucial.
 
 In any case, the meta-machine has to both have access to compile-time 
 structures and objecs, and also has to be able to change the tree. I 
 expect this to be less dangerous than what folks think. :-)
 
 Another benefit is that new things in D could thus be easily tried out. 
 This would free Walter to see whether any such actually get popular 
 enough to warrant hard coding them. In other words, we could have an 
 actual feature freeze between major versions, and end up Knowing what we 
 add to the language.
Sep 25 2005
parent reply Georg Wrede <georg.wrede nospam.org> writes:
J Thomas wrote:

 right on, yah i tried working with openc++ a couple years ago until i
 realized it was a total mess. and on further reflection i think its
 just not worth the hastle of parsing c++ for metaprogramming 


I have never, ever, even heard rumours of a language _less_ suited to 
intelligent parsing, _or_ productive metaprogramming, than C++. So the 
_mess_ may not be the OpenC++ crowd's fault. (At the most, one can blame 
them for choosing _the_ worst language in existence, for the excrecise.)


 so i
 thought about building a new c-type langauge for mettaprogramming
 when I found D. D is fantastic, plus its been designed to *parse*
 easilly which opens up a whole range of possibilities. 


I'd like to attribute this to Walter's unfathomable experience with the 
issues at hand. Few people are actually in the position he's right now. 
Most of the "more [than him] accomplished" (according to _their_ own 
standards), have (for ages ago) bought a villa in Florida, and have 
started (what I call) the Final Descent. (Which means having young girls 
at the poolside and drinking with them 7 days a week, never even 
touching a computer.) ((Been there, seen it all.TM)) So, Walter is 
unmarinated, still at it, and ready-to-kill! Precicely what is needed, 
if a C/C++/Java contender ever is to stand a chance.


 im going to
 have to look at the language machine a little more but yah, the first
 thing i thought of when i heard about it was metaprogramming. it
 would be very cool to get a metaprogramming front end for D going, as
 you said i think it could greatly help language development, as
 people could more easilly "try out" their own extensions. 


The more _separate_ enterprises we have at this, the better. A little 
like the GUI toolkits for D, being all different -- but unlike them, 
we'd not stay on our separate islands forever.

The _difference_ to them being, we could agree from the start, that 
we'll compete (and cooperate), with the ultimate aim being, to one day, 
together be able to present to Walter (and the community) something so 
compelling that nobody even thinks of opposing.


 at this
 point im finishing up little debugger in D, as all my other debuggers
 seem to be a hastle to use for D apps, 


Windows or Linux?


 and im still getting used to
 the language. but I plan on doing some sort of metaobject protocol
 for D before I do anything real serious. I think D with metaobjects
 could be one of the most powerfull tools ive ever seen. for me
 anyway...


Yes!

Consider this: let's assume [because I don't bother right now to check 
this out], that the First Programming Language was created  1940. At 
that day, 1 person knew the language.

In those days, [and well into the '60s] you only had a half-handful of 
languages to choose from. You had your thing to do, and all you could do 
is to choose (or your boss) the _least bad_ language for it.

Taking it from the other end: what's the number of programming languages 
in existence today? What's the number of people fluent in at least one 
programming language today?

Add to that the fact that, in the old days, Programming Language Theory 
was accessible to only a few [hundred] people. Only they knew enough to, 
first of all, consider creating a new language, [or why one would even 
need one] and secondly, had the theoretical background required to 
actually create a non-useless one at that.

Extrapolating this a bit beyond today, the time is nigh, when an ever 
expanding horde of programmers [and, increasingly non-programmers], 
possess the required minimun knowledge [and confidence], to actually 
consider conjuring up a new language for whatever needs they currently 
have at hand.

((For background reference, make a list of all programming languages, 
existing today or having ever existed. Sort them according to the 
Invention Date. Make a plot representing the time between each. You'll 
see that we already are past the time when !the time required to learn a 
new language! has become longer than the average time between two 
languages popping up.))

---

 From a distance, most of the times a new language is created, are _not_ 
because there is a genuine need for something _fundamentally_ new, or 
different. Mostly, it's to do with "needing a few details or properties" 
that the person couldn't find [from the language selection they were 
aware of, at the time].

I'm ready to wager that, if a person is used to a [generally 
satisfactory] language, he'd prefer to see _that_ language with the 
extensions he needs, instad of either creating one from scratch, or 
having to learn a "foreign" "base-language" upon which to build.

Since D is an unbelievably versatile, down-to-earth, Practical Language 
for Practical Programmers (TM by W.Bright), we are in a position to 
_really_ benefit from the ability to let ad-hoc needs be catered for, 
right in the "language".



 Georg Wrede wrote:
 

 J Thomas wrote:
 

 sounds like what you are talking about is a meta-language for 
 metaprogramming. (no not C++ template metaprogramming) are you 
 familiar with metaprogramming systems like openc++?


 
 
 
 I looked at OpenC++ a couple of years ago. I did like the idea, and
  wished for something like it for D. Now that we have the Language 
 Machine, starting a metaprogramming project should be trivial!
 

 this is a pretty straightforward concept and i think it could be
 done quite well in D, especially since its such a dream to parse.
 I am eventually going to implement my own meta-programming system
 on top of D, it could be done pretty easilly with the front end
 code. Im waiting to see where hes going to go with reflection


 
 
 
 I definitely see a modified D front end as the goal. Before that, I
  presume it would be easy to do initial experiments with proposals
 to the metalanguage details with a D-to-D translator.
 
 I'd love to see a way of attaching arbitrary properties to syntax
 tree nodes. These could be used to all kinds of things. For
 example, if the programmer is into functional programming, then the
 knowledge of side effects in a function would be crucial.
 
 In any case, the meta-machine has to both have access to
 compile-time structures and objecs, and also has to be able to
 change the tree. I expect this to be less dangerous than what folks
 think. :-)
 
 Another benefit is that new things in D could thus be easily tried
  out. This would free Walter to see whether any such actually get 
 popular enough to warrant hard coding them. In other words, we
 could have an actual feature freeze between major versions, and end
 up Knowing what we add to the language.
Sep 25 2005
next sibling parent J Thomas <jtd514 ameritech.net> writes:
windows

Georg Wrede wrote:

 J Thomas wrote:

 at this
 point im finishing up little debugger in D, as all my other debuggers
 seem to be a hastle to use for D apps, 


 
 
 Windows or Linux?
Sep 25 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <4337114C.7050800 nospam.org>, Georg Wrede says...

I'd like to attribute this to Walter's unfathomable experience with the 
issues at hand. Few people are actually in the position he's right now. 
Most of the "more [than him] accomplished" (according to _their_ own 
standards), have (for ages ago) bought a villa in Florida, and have 
started (what I call) the Final Descent.


Most of the others I know of are on the C and C++ committes, but it's a good
point.


(Which means having young girls 
at the poolside and drinking with them 7 days a week, never even 
touching a computer.)


Hey, Don Knuth is a special case!


Sean
Sep 26 2005