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 ("opOctoAt","#@",BINARY,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; //a = b.opOctoAt(a);
a <-> b;  //a.opSwap(b);

with >>>= we are already ok with looking for operators of up to 4 characters. In addition to the symbols already overloadable we can add "@#$:?" to the mix. (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

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

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

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.

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?

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

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?
> 
> 

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
> 

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.

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.
>