Georg Wrede wrote:
> xs0 wrote:
> 
>> But what would it look like? I really like the idea of a meta-language, I just can't come up with something that fits in D and at the same time makes it extensible..
> 
> 
> Well, at this point I think the best thing to do is to carefully think about what we _want_ it to be able to do. IMHO, if we try to come up with, say a syntax, or a way of "blending into D", then we unnecessarily create restraints. Both syntaxwise, but more important, we fence us into our newly made box, and that's the end of "out of the box" thinking. Right now is the time for the latter, and the longer we keep at it, the better we understand _what_ has to be done. Once that is clear, only then can we allow ourselves to think about _how_.

Well, the first thing I want is macros somewhat like C's, except not on textual level, so you can't define something like

#define BLAH(a,b) a + b +


I still want to be able to generate new identifiers:

#define SUM(T,U) sum_#{T}_#{U}(T a, U b) { return a+b; }

and SUM(int,double) becomes sum_int_double(int a, double b) {...}


Third, I wan't this:

func!(__myBasicTypes__).doit();

to get expanded to this:

func!(int).doit();
func!(double).doit();
func!(MyClass).doit();

for any "func" and "doit" i.e. whenever __myBasicTypes__ appears as a type, I want the expression to be expanded to three expressions with appropriate types. And not just in expressions, why not have template specializations for multiple types at the same time? Or function definitions:

func(__anyCharType[]) {
  // do something
}

becomes

func(char[])
func(wchar[])
func(dchar[])


Fourth, I want to be able to insert code from "outside" the method/func/class/whatever. Like:

#match C:class(*) {
    #prepend_or_create_method (C, static this()) {
        globals.all_classes~=#get(C.fullName);
    }
}

If we manage that, we rock (and Walter doesn't have to implement reflection :)


>> As I see it, two issues are involved:
>> - being able to specify new syntax, both locally (as the X example below) and globally, where the main problem is - what is the syntax for syntax, and how do you make it self-extensible; if it's not self-extensible, it's just another layer of templates, I guess..
> 
> We shouldn't care! Just assume whatever we need to, we'll come up with in due time. First we need a good list of what we _want_. Suggestions and help, even (possibly hard) criticism is welcome too!

Well, I think that just wildly brainstorming isn't going to be very productive. We should instead start by thinking of a few examples of what specifically we'd want to do, and conjure some way of encoding that. After the initial "spec" is done, we can see what else we'd like to do, and check whether it's already possible. If it is, great, if not, we amend and revise the "spec" to include both the old and new functionality. We can repeat this as long as we want, and in the end we'll have a solid syntax+semantics for the meta-D, and all that is left is implementing it, which will hopefully be relatively straightforward. OTOH, if we just dream about something, we'll only have dreams in the end.


> The C crowd _started_ with a syntax. Then kept appending to it, and we all see where that leads. They've never had a clue of where they are ultimately aiming. Well, we'gre gonna do it the other way around.

I'd say C started just as you're proposing - they thought of what they wanted to do and did it. The problem was that they later wanted to do additional stuff, and had to append to what was there already.

I know you're trying to say that we should have something that is infinitely self-extensible, so that we'll never have to "append" something to it, but even if we manage to do that, we'll eventually run into the same problems. I mean, there's only so many ways you can overload, say, '(' and ')', before it becomes ambiguous what exactly you're trying to do. After that happens, you need new symbols/syntax for your new feature, but eventually you still run out of them. In other words, even if you have an infinitely extensible language, you can't infinitely extend it (at least realistically - noone will want to use 250 different operators, even if they're defined in Unicode).


>> - being able to modify existing code, because just defining syntax expansions (like X below) is not enough. 
> 
> Right!

Hmm, after thinking about it, I don't think that's possible at all. Say you did manage to define aspects. You can't use them in the aspect defining code, so that's limitation number one (because it can't process itself - if an aspect is needed for aspects to work, they can't work, because they don't work before they work, or something :). Second, if some other extension during processing sees an aspect, it will skip it because it doesn't know what to do with it. Later, when the aspect gets applied, the first extension won't see the code again, so won't work there. If you do run it again, it is possible that it will break what the aspect extension did, which is possibly even worse.


>> For example, if you wanted to add aspects, you'd need to define the syntax, have the compiler parse the source, then do something like "for each aspect that is defined, go through all the method and class declarations, find those that match, and insert the code from the aspect there and there if that and that". 
> 
> 
> The meta language idea should be able to accommodate that. But not like we specifically thought of aspects in particular, rather like if it is what we wanted it to be, and only after that somebody invents aspects, the meta language should handle that too. Or, more to the point, the programmer who wants to implement aspects. And what he has to write in meta to make it so should not be incomprehensible to others.

Well, we can't make a language for things we can't foresee (I don't mean stuff like aspects specifically, but more like "something that modifies other code by pattern matching on identifiers")


>> Now that's basically a program in itself, so it's a good question 
> 
> Exactly. And that is what I've meant each time I've mentioned Turing! I see no way around it. -- The C++ preprocessor language had reached Turing level without any of the C++ honchos ever even noticing. Several _years_ later somebody just happened to discover the fact.

Hmm, when you say C++ preprocessor, you do mean its template system, right?


>> whether it is not better to simply open the compiler to plugins, than to try to fit this in the language and have the compiler be practically a virtual machine..
> 
> I would like to know more of this plugin idea.

Well, if the compiler worked in some really well-defined way and had an open interface to extensions (as in .DLLs or similar), it could let the plugins work on its internal structures (like definitions for tokens and grammar before parsing and AST after parsing), which would basically mean "anything" is possible. But its not as simple as it sounds, especially the grammar part, grammars are very delicate...


>> Even after you're able to do that, there are issues of collisions (what if two meta-things want to modify the same, say, class?), infinite loops (code A produces B, code B produces Aa, which becomes Ba, which becomes Aaa, ...), optimization, etc.
> 
> We'll take care of them at the time. Had Walter got scared of circular imports too early -- but he didn't. Same with meta.

Well, it's not quite the same :) And those are issues that need to be considered straight from the start (esp. collisions), if you want something successful.


xs0

Lionello Lunesu wrote:
> Just for my understanding: would a metalanguage allow you to define new operators on the fly?

Yes.

Suppose you are into Graph Theory, and you need to create a lot of Directed Graphs. You could do the meta definition of the operator right where it is needed, or you could have it in a library for regular use.

Let's take the local case.

Class Vertex {
    Vertex[] toVertices, fromVertices;
    public addTo(Vertex v) { toVertices ~= v }
    public addFrom (Vertex v) { fromVertices ~= v }
}


void main () {
    Vertex a = new Vertex;
    ... and b,c,d,e....

Now, we need to create the connections. For this we need an operator, let's call it "-=>" and define it.

    metadefinition ( lkjdsallkjakjsf ); //Nobody knows the syntax

Then just go on with the graph:

    a -=> b;
    c -=> d;
    d -=> a;
    c -=> b;

} // end main.

Our connecting operator is in scope only in main itself, so we won't pollute all of the application source code.

The meta definitions should obey normal D scoping rules.

/////////////////////////////////

Now, let's take the module case.

module foo.bar;

meta myGraphOperator (lkjsdfljsadl);  // metadefinition, that
                        // defines the operator -=>
// still unknown syntax.  :-)


Production code would be:

import foo.bar;

Class Vertex {
    Vertex[] toVertices, fromVertices;
    public addTo(Vertex v) { toVertices ~= v }
    public addFrom (Vertex v) { fromVertices ~= v }
}

void main () {
    Vertex a = new Vertex;
    ... and b,c,d,e....

// Now, we need to create the connections.
// For this we need the operator.

    foo.bar.myGraphOperator; // get it into this scope

// Then just go on with the graph:

    a -=> b;
    c -=> d;
    d -=> a;
    c -=> b;

} // end main.

> This way, the current D language would in fact be an implementation using (its own) metalanguage for defining the existing operators and their precedence?

I think it could.

Of course, compiling would then be slower!

Anders F Björklund wrote:
> Georg Wrede wrote:
>> D meta language is an important thing. But now it is also urgent.

> What would the "D meta language" be ? 

The way I see it now, having this meta language in D would not even slow down DMD at all, as long as you don't use meta constructs!

All that would be needed is a few more reserved words in the language. Unless they are encountered, then DMD speed should stay exactly the same. (I.e. industry shattering!) Of this I'm sure of.

If a local meta definition is encountered, then compiling would be slower for the part of source code where the definition is in scope.

With a lot of global scope definitions, compiling would be noticeably slower. But still a lot faster than C++.

Speaking of which, there is no reason at all to have definitions with a global effect. Locality, code hiding, etc. should be obeyed here too.

xs0 wrote:
> Georg Wrede wrote:
>> xs0 wrote:
>> Well, at this point I think the best thing to do is to carefully think about what we _want_ it to be able to do. IMHO, if we try to come up with, say a syntax, or a way of "blending into D", then we unnecessarily create restraints. Both syntaxwise, but more important, we fence us into our newly made box, and that's the end of "out of the box" thinking. Right now is the time for the latter, and the longer we keep at it, the better we understand _what_ has to be done. Once that is clear, only then can we allow ourselves to think about _how_.

Good list below!

> Well, the first thing I want is macros somewhat like C's, except not on textual level, so you can't define something like
> 
> #define BLAH(a,b) a + b +

That ought to be easy.

Definitely local scope is what should be used. Both textual level, and global scope in general "are for the other guys"!

> I still want to be able to generate new identifiers:
> 
> #define SUM(T,U) sum_#{T}_#{U}(T a, U b) { return a+b; }
> 
> and SUM(int,double) becomes sum_int_double(int a, double b) {...}

Ha! This revealed to me that the meta system could have a library of its own. Some of the usual things (like the one above) could be there all along. Then folks wouldn't have to actually write them, just look them up in the manual, and then activate.

> Third, I wan't this:
> 
> func!(__myBasicTypes__).doit();
> 
> to get expanded to this:
> 
> func!(int).doit();
> func!(double).doit();
> func!(MyClass).doit();

So you are creating a method for a bunch of classes from a template?
Resembles multiple inheritance, and aspects?

This would definitely be doable in C++. But with D having method definitions inside the classes, I can't say off hand.

Probably it would still be doable, but you'd possibly need more work than with inheritance. (Here I'm deliberately overlooking the difference between int and double, vs classes.) You may want to be more specific on this one.

> for any "func" and "doit" i.e. whenever __myBasicTypes__ appears as a type, I want the expression to be expanded to three expressions with appropriate types. And not just in expressions, why not have template specializations for multiple types at the same time? Or function definitions:
> 
> func(__anyCharType[]) {
>   // do something
> }
> 
> becomes
> 
> func(char[])
> func(wchar[])
> func(dchar[])

That depends on the "// do something". That is, if it can handle all of the types. Then it should be doable.

> Fourth, I want to be able to insert code from "outside" the method/func/class/whatever. Like:
> 
> #match C:class(*) {
>     #prepend_or_create_method (C, static this()) {
>         globals.all_classes~=#get(C.fullName);
>     }
> }

Gee, a question I have no answer for! You'd have to ask Walter about this.

> If we manage that, we rock (and Walter doesn't have to implement reflection :)

I wouldn't be surprised if making this work would be the same amount of work for Walter.

>>> As I see it, two issues are involved:
>>> - being able to specify new syntax, both locally (as the X example below) and globally, where the main problem is - what is the syntax for syntax, and how do you make it self-extensible; if it's not self-extensible, it's just another layer of templates, I guess..

My answer here missed your main point. :-(

>> We shouldn't care! Just assume whatever we need to, we'll come up with in due time. First we need a good list of what we _want_. Suggestions and help, even (possibly hard) criticism is welcome too!
> 
> Well, I think that just wildly brainstorming isn't going to be very productive. We should instead start by thinking of a few examples of what specifically we'd want to do, and conjure some way of encoding that.

True. But just like with programming in general, the longer you abstain from the keyboard, the faster the overall app gets ready, and with better quality.

> After the initial "spec" is done, we can see what else we'd like to do, and check whether it's already possible. If it is, great, if not, we amend and revise the "spec" to include both the old and new functionality. We can repeat this as long as we want, and in the end we'll have a solid syntax+semantics for the meta-D, and all that is left is implementing it, which will hopefully be relatively straightforward.

Yes. And this is a deep issue, so we ought to get folks tinking hard, before we know what we want in the spec.

> OTOH, if we just dream about something, we'll only have dreams in the end.

:-)

>> The C crowd _started_ with a syntax. Then kept appending to it, and we all see where that leads. They've never had a clue of where they are ultimately aiming. Well, we'gre gonna do it the other way around.
> 
> I'd say C started just as you're proposing - they thought of what they wanted to do and did it. The problem was that they later wanted to do additional stuff, and had to append to what was there already.
> 
> I know you're trying to say that we should have something that is infinitely self-extensible, so that we'll never have to "append" something to it, 

Yes.

> but even if we manage to do that, we'll eventually run into the same problems. I mean, there's only so many ways you can overload, say, '(' and ')', before it becomes ambiguous what exactly you're trying to do. After that happens, you need new symbols/syntax for your new feature, but eventually you still run out of them. In other words, even if you have an infinitely extensible language, you can't infinitely extend it (at least realistically - noone will want to use 250 different operators, even if they're defined in Unicode).

That's where locality of scope comes to rescue. With this system statisticians, mathematicians, physicists, even astrologists, could reuse the same symbols -- just like in paper books today.

>>> - being able to modify existing code, because just defining syntax expansions (like X below) is not enough. 
>>
>> Right!
> 
> Hmm, after thinking about it, I don't think that's possible at all. Say you did manage to define aspects. You can't use them in the aspect defining code, so that's limitation number one (because it can't process itself - if an aspect is needed for aspects to work, they can't work, because they don't work before they work, or something :). Second, if some other extension during processing sees an aspect, it will skip it because it doesn't know what to do with it. Later, when the aspect gets applied, the first extension won't see the code again, so won't work there. If you do run it again, it is possible that it will break what the aspect extension did, which is possibly even worse.
> 
>>> For example, if you wanted to add aspects, you'd need to define the syntax, have the compiler parse the source, then do something like "for each aspect that is defined, go through all the method and class declarations, find those that match, and insert the code from the aspect there and there if that and that". 
>>
>> The meta language idea should be able to accommodate that. But not like we specifically thought of aspects in particular, rather like if it is what we wanted it to be, and only after that somebody invents aspects, the meta language should handle that too. Or, more to the point, the programmer who wants to implement aspects. And what he has to write in meta to make it so should not be incomprehensible to others.
> 
> Well, we can't make a language for things we can't foresee (I don't mean stuff like aspects specifically, but more like "something that modifies other code by pattern matching on identifiers")

About aspects, I really need more knowledge on them. So, on second thought I won't comment on them for the time being.

"Something that modifies other code by pattern matching on identifiers" is more or less what I'm thinking about in general with this meta thing.

>>> Now that's basically a program in itself, so it's a good question 
>>
>> Exactly. And that is what I've meant each time I've mentioned Turing! I see no way around it. -- The C++ preprocessor language had reached Turing level without any of the C++ honchos ever even noticing. Several _years_ later somebody just happened to discover the fact.
> 
> Hmm, when you say C++ preprocessor, you do mean its template system, right?

Yes. (Sorry for the ambiguous expression.)

>>> whether it is not better to simply open the compiler to plugins, than to try to fit this in the language and have the compiler be practically a virtual machine..
>>
>> I would like to know more of this plugin idea.
> 
> Well, if the compiler worked in some really well-defined way and had an open interface to extensions (as in .DLLs or similar), it could let the plugins work on its internal structures (like definitions for tokens and grammar before parsing and AST after parsing), which would basically mean "anything" is possible. But its not as simple as it sounds, especially the grammar part, grammars are very delicate...

Currently I imagine the meta thing and the compiler would work in cooperation. The meta would not change the compiler's structures, only ask it to add or change things. Hopefully not even that -- if I'm at all on the right track here.

>>> Even after you're able to do that, there are issues of collisions (what if two meta-things want to modify the same, say, class?), infinite loops (code A produces B, code B produces Aa, which becomes Ba, which becomes Aaa, ...), optimization, etc.
>>
>> We'll take care of them at the time. Had Walter got scared of circular imports too early -- but he didn't. Same with meta.
> 
> Well, it's not quite the same :) And those are issues that need to be considered straight from the start (esp. collisions), if you want something successful.

Yes. Circularities I just cavalierly assume Walter could handle. Or at least detect, and error on them. So it's more like a "syntax issue". I mean, how to aid the programmer in not unnecessarily creating them and stumbling over compiler errors because of them.

Collisions, well, to begin with, we'd need to have a defined order of things. That's something even the application writer needs to be clear on, right? Meta or no meta.

If there is a clear order to what is done, then collisions should become a very much smaller issue.

> Matthew wrote:
>> "Georg Wrede" <georg.wrede@nospam.org> wrote:
> .......
>>>The goal, after all, once they start thinking "outside the box" is to create a universal meta language. For such a language it is a piece of cake to handle all of the current crap.
>>>
>>>So, they'll get their Backward Compatibility, but this time as a _mere_ special case -- just one small thing among the tousands of grand things it'll handle.
> ........
>>>So, I'm worried as hell.
>>
>> I'd chill out. I have not the slightest doubt that Walter's smart enough to do this. And I'm confident it'll be out before any C++ implementations.
>
> Course he is smart enough! But isn't this newsgroup here to let ideas cook, folks find the early worm, ask the Right Questions, etc.? (Not forgetting helping newbies, too.)

It is. My point was that you seem to be over-reacting/stating.

I mean, let's be honest, D's not going to kick off C++ or Java/.NET in a single stroke, no matter how killer a feature it has. Any migration from them to it would take time, and be based on multipart user judgements. Even if D, right now, had the most amazing meta language ever seen, it wouldn't bring zillions of people over because (i) the language still has non-trivial flaws, (ii) the runtime library is still woefully inadequate, and (iii) MP is not all that important to most people (and I'd hazard a guess to say it never will be).

None of that is to say it's not desirable, and won't be a big component of the overall eventual picture of attractiveness. I just don't think it's anything to panic about.

>> But maybe I'm a starry-eyed optimist. :-)
>
> Somehow I get the feeling there _is_ a meta language project, already well rolling forward -- behind the scenes. For some reason it's been awful quiet around here about its specifics.

I think there might. Walter's a thinker as well as a language porker. (Nomenclature: v. pork. To mess with, to hack. Can imply a degree of recklessness. Usage "pork away [on that library]". Derivation: my friends Leigh and Scott Perry, who were unfailingly bemused at my desire to get in and fix libraries which were flawed but for which they had adequate workarounds. <g>)

> Or, he's talking with superhumans in the academia and other Einstein/MahreshYogi look-alike hermits, the only ones who've Received the Knowledge from Above.

Well, I wasn't aware that there were any superhumans in academia. Maybe you're referring to people who use terminology with which you're unfamiliar? But that doesn't make them superhuman. (In fact, the more I learn about the rarefied heights of the programming world, the less impressed I am with anyone's omnipotence. Most acute, naturally, being my own. <g>)

> If this is the case, then I'd better shut up. I could always try to cook something up, and if it tastes good, then maybe try to earn some money with it? The it'd of course be a pure preprocessor.

Please don't shut up. You've intrigued me enormously about possibilities. It's just that I am so inexperienced in such matters - at least from a generic (not C++ TMP) perspective - that I am not able to grasp your intent without suitably simple examples. <g>

Matthew wrote:
>>Matthew wrote:
>>>"Georg Wrede" <georg.wrede@nospam.org> wrote:
>>>>So, they'll get their Backward Compatibility, but this time as a _mere_ special case -- just one small thing among the tousands of grand things it'll handle.
>>>>So, I'm worried as hell.
>>>
>>>I'd chill out. I have not the slightest doubt that Walter's smart enough to do this.
>>Course he is smart enough! But isn't this newsgroup here to let ideas cook, folks find the early worm, ask the Right Questions, etc.? (Not forgetting helping newbies, too.)
> It is. My point was that you seem to be over-reacting/stating.

A (delusional) sense of urgency, importance, and paranoia.

That has advanced the mankind, on several (actually most) occasions. Got us to the Moon, gave us (non-americans anyway) serious encryption, nuclear technology, good computers, submarines, GPS, teflon, solar panels. And Ada.

Complacency, that's what kills a language! (Quote of the day(TM))

> I mean, let's be honest, D's not going to kick off C++ or Java/.NET in a single stroke, no matter how killer a feature it has.

I was thinkin more like the "extra" fame and hype D would get for doing something right, before the others. More press exposure won't hurt.

This "right" is, of course (so far) only my personal belief. Hopefully others will agree, in time. (Ha, and if I'm on a completely wrong track here, I wish to Bob somebody would kick down the stack of cartons I'm trying to lecture from. Before this becomes too public!! )

?Ha?s/on a completely wrong/not on precisely the right/    :-)

Right: Turing complete. Two-level. Infinitely extensible (honest!). Not only descriptive but procedural too.

In practice: No must-use. Comprehensible to the casual, or the newbie. Practical. Practical. Practical. Without self-promotional esotheric bells and whistles -- just get the job done. Any job.

I ADMIT THIS PLATE IS A BIT FULL. (No shit?!) But I have to admit, by now this is more than wishful thinking. I have (eh, like Walter "may be") some actual ideas on how to implement this. Why else would I sound so confident, even to a few specific questions by folks.

> Any migration from them to it would take time, and be based on multipart user judgements. Even if D, right now, had the most amazing meta language ever seen, it wouldn't bring zillions of people over 

Actually, we live in the 21st century now. Times change, my friend. Obstacles are only as hard as you think. (Took me almost 50 years :-( to figure out.) Today we have something there's never been: we can turn 400 million heads overnight. If 0.001% of these start actually thinking, we'll be well off.

Say there's a big article in PC-Magazine, that essentially says "we really think this is the language the industry will use in two years." Well, nothing will happen for a while. Six months from then, Walter's download server will crash.

Not enough, though. But have editorials saying essentially the same in DDJ and CUJ, hopefully one month after the PC-Magazine one, and we fly.

> because 
> (i) the language still has non-trivial flaws,
> (ii) the runtime library is still woefully inadequate, and (iii) MP is not all that important to most people (and I'd hazard a guess to say it never will be).

(i) We need to keep PC-Magazine ignorant of us till that's fixed. :-)

(ii) Now, that's something that will not proceed fast enough the way things currently are. We need to CHANGE THE SETUP around it. Do something DRASTIC. (Put it on dsource, or sourceforge, whatever! But something really has to be done to this, now! Projects on SourceForge have to have an "owner", so Walter wouldn't eve lose control!) Lots of talent just seeking a worthwhile, interesting project, with a long time future.

(iii) I fully and completely agree. MP is not for the average user. While easy things will be easy (like the X example in this thread), the regular (even professional) programmer will never use it.

MP (at least the way I see our concoction becoming used) is for corporate use, research, libraries, D development(!) -- and should be used invisibly to most things. It will find its use in a massive reduction of the size of app-field specific libraries, reducing complicity when doing "hairy stuff", and for programming language research.

(Issues like overloading on return type, unquoted regexps as anonymous functions, a serious string type or class -- or just regular D features investiagetd for inclusion or exlcusion.)

Most regular programmers will never know they've been using it! In time some things regularly done with MP will be incorporated directly in the D "core" (for speed of compilation, others just because the MP usage has shown them to be practical and useful (a new keyword, a new operator, new syntax for something)).

> None of that is to say it's not desirable, and won't be a big component of the overall eventual picture of attractiveness. I just don't think it's anything to panic about.

There's psychology here too. I used to sell SLR cameras at a major department store. We sold Canon, Nikon, Minolta, Olympus, and a half dozen now extinct brands. Customers dithering between two cameras ended up choosing the one with which "you could do this" that you couldn't do with the other. Most of them never noticed this themselves!!

Usually it was a feature (both they and I knew, but did't say) they'd never get around to using. But ultimately the choice was formulated as something "non-childish", like durability, long-term availability of accessories, quality, etc. And if the chosen one just happened to cost less than the other, then Economy was the Thing. (Wife'll be less angry!) (Oh, and if economy was the real reason, then the pretense was of course whatever else.)

I've participated in a few language shoot-outs. (University IT department curriculum planning meeting, customer board room, regular consulting with customers, mens' room, the local pub.) Any non-obvious choices end up like the SLR sales: ultimately the "cool thing" the other one doesn't have -- whether that is relevant to the choice at hand or not.

And believe it or not, the people who (by profession, or by position) definitely should not succumb to this, they're actually the worst.

We need to use this to our advantage. It's there for the taking!

Even the moron who'll _never_ be able to grasp even recursion, has to brag to his equal friend that he's Chosen the "infinitely extensible D" programming language.

Ditto the Pointy Haired boss over beer at the Country Club.

>>>But maybe I'm a starry-eyed optimist. :-)
>>
>>Somehow I get the feeling there _is_ a meta language project, already well rolling forward -- behind the scenes. For some reason it's been awful quiet around here about its specifics.
> 
> I think there might. Walter's a thinker as well as a language porker. 

Then I might be happy. And not alone in the world.

>>Or, he's talking with superhumans in the academia and other Einstein/MahreshYogi look-alike hermits, the only ones who've Received the Knowledge from Above.
> 
> Well, I wasn't aware that there were any superhumans in academia. 

Alfred Aho, Edsger Dijkstra, Donald Knuth, Linus Torvalds, Roger Penrose, Alan Turing.......

Not granting Superhuman Status to those who deserve it -- is arrogant. :-) :-P

OTOH, you might visit several hundred universities, and not find a single one. And that's a disgrace!

> Maybe you're referring to people who use terminology with which you're unfamiliar? 

LOL! I know what you mean! I had the good fortune to know my mother's cousin, who compulsively tried to pull that one off. At age 11 I noticed! The best thing was, mom had a lot of respect for him, and bought most of this crap -- so I couldn't shoot him down. I learned to "not notice".

Man, the lot of fun I've had through the years with these guys. And gals. Both in and out of academia. And none of them know!

> But that doesn't make them superhuman. (In fact, the more I learn about the rarefied heights of the programming world, the less impressed I am with anyone's omnipotence. Most acute, naturally, being my own. <g>)

I was thinking of a few names I expressly did not list above. There's a particular example, a guy who is undeniably accomplished, who's known to everyone in the non-profit programming world, with a huge reputation. We sat a few hours drinking beer after his lecture at an academic convention. I was shattered to discover that he actually is a superhuman-wannabe, a man of lust and avarice, envy, and a petty soul.

(Maybe I should have spelled it like "superhuman wannabe"!)


<humor_intent quality="lame">

Omnipotence... not for us, but for D !!

</humor_intent>

>>If this is the case, then I'd better shut up. I could always try to cook something up, and if it tastes good, then maybe try to earn some money with it? The it'd of course be a pure preprocessor.
> 
> Please don't shut up. You've intrigued me enormously about possibilities. It's just that I am so inexperienced in such matters - at least from a generic (not C++ TMP) perspective - that I am not able to grasp your intent without suitably simple examples. <g>

Humble! :-)

Thanks! I'm relieved to hear this intrigues. I wish, if other people read this thread, that they'd at least be entertained, stimulated, and possibly motivated.

------------

Corollary:

I had a career revelation. The day FADPL (the Foundation for the Advancement of the D Programming Language, a US non-profit with tax-exempt status, later backed by Lawrence Livermore, GM, DoE, and others, hopefully to be started by somebody, some day), is looking for paid D evangelists, I'll submit my resume.

They could do a lot worse than hiring me.  :-)

> But I have to admit, by now this is more than wishful thinking. I have (eh, like Walter "may be") some actual ideas on how to implement this. Why else would I sound so confident, even to a few specific questions by folks.

Well, for Bob's sake, what exactly do you want to implement and how do you propose it is done? :)

xs0

xs0 wrote:
>> But I have to admit, by now this is more than wishful thinking. I have (eh, like Walter "may be") some actual ideas on how to implement this. Why else would I sound so confident, even to a few specific questions by folks.
> 
> 
> Well, for Bob's sake, what exactly do you want to implement and how do you propose it is done? :)

Right now I'm trying to find a D grammar somewhere.

I'd like to add a couple of keywords to D. They'd be for defining meta things, and undoing the definitions. (At least in the beginning there'll be a define and an undefine. Later, with more experience and confidence, lexical scoping would work "automatically". Even more later global things could be defined. And after that, maybe local disabling of global things. Then I wonder about this-file-only defines, how this should work with importing files, and other, eh, more challenging obstacles.) (Oh, I forgot, there are no Obstacles, only Interesting Things Encountered on the way! :-O  )

I'm trying to find a language to use in this pre-prototyping (in reality I'll do 1-screenful short programs that get D source code, and output D source code (just like any preprocessor).

While I'm toying around (mostly to see what problems I've totally missed), with awk, sed, grep, possibly ed, maybe D, Euphoria, and whatever other seems to be nice for the particular mini thing, I am trying to figure out how to do it for real. (Heck, I may even end up searching around for my Perl book.)

Do what? Well, a pre-alpha version of a proof-of-concept kind of prototype. Or, if it looks like too much, then I'll try to make a couple different protorypes, each of which would demonstrate some part of the whole.

Something for #define X(a,b) foo(b,a);bar(a);blabla(a,b,a,b) kind of trivial C preprocessor things. Something else for having a snippet of self-made language inside a procedure instead of writing that too with D (see the sugar-cube robotics example in this thread).

And then maybe one or a couple of different try-outs for the hairy stuff. With that I dream you could do Lisp like stuff, that's really for "the superhuman". That's a bit hard, since I'm not.  :-(

-----

For these pathetic first attempts I'd either make small one-trick-preprocessors, or maybe later get a GDC version that I can compile, and then break the parser and lexer "trying to play Walter"! ;-)  -- With neither his skills, experience, nor abilities.

If any of these one-trick things does anything useful at all, then I'll post them for others to laugh at. Then at least folks will get a glimpse of some parts of the whole. With any luck there'll be discussion and feedback, to keep us going on!

If we haven't given up by this time, then we'll try to do the same with some self-made-language inserters. Probably the really first ones will have some arbitrary but fixed language as the "inserted language", later the testers (you gyus) get versions actually capable of doing minilanguages defined in some input file by each of you -- for using and abusing them.

If we're still at it at this point, then it's time for the hairy stuff. I don't know how we'll test that, without asking some heavyweight hairy-stuffers. I mean, even if a particular preprocessor happened to actually work, where do we find the kind of guys who are actually capable of trying any hairy stuff on them? Or giving meaningful comments??

Phew! If we're /still/ here, then it'd be time to make a proposal for Walter.

Thanks a lot for your example! I finally know what all the (totally justified) fuzz is about!

Thanks again..

Lionello.

After some thinking, I determined this has to be a pre/postprocessor, unless the compiler is completely redone to support dynamic grammar. Because, you obviously want to be able to define new tokens (like "aspect" or "-=>") and new syntax, but by the time the compiler is aware of that, parsing has already happened (and most probably failed). As for the scope, it would be nice to simply have two constructs, like #define for globals and #local ... #{    #}  for locals.. #define should perhaps be renamed to make an obvious distinction from C's..

Hmm, after some more thought, it may make sense to move new syntax definitions completely out of D source, where they'll have no constraints/conflicts with the existing syntax, and it can be used with something like

#extension(aspect)

in the source. Local stuff will be somewhat limited then, but I guess it would be mostly used for stuff like the X macro, which shouldn't be too hard, and perhaps for mini operators, like -=>. OTOH, maybe these could be skipped altogether? You can write the extension normally and use something like

#with(graphOperator) {{

#}}


xs0

Georg Wrede wrote:
> xs0 wrote:
> 
>>> But I have to admit, by now this is more than wishful thinking. I have (eh, like Walter "may be") some actual ideas on how to implement this. Why else would I sound so confident, even to a few specific questions by folks.
>>
>>
>>
>> Well, for Bob's sake, what exactly do you want to implement and how do you propose it is done? :)
> 
> 
> Right now I'm trying to find a D grammar somewhere.
> 
> I'd like to add a couple of keywords to D. They'd be for defining meta things, and undoing the definitions. (At least in the beginning there'll be a define and an undefine. Later, with more experience and confidence, lexical scoping would work "automatically". Even more later global things could be defined. And after that, maybe local disabling of global things. Then I wonder about this-file-only defines, how this should work with importing files, and other, eh, more challenging obstacles.) (Oh, I forgot, there are no Obstacles, only Interesting Things Encountered on the way! :-O  )
> 
> I'm trying to find a language to use in this pre-prototyping (in reality I'll do 1-screenful short programs that get D source code, and output D source code (just like any preprocessor).
> 
> While I'm toying around (mostly to see what problems I've totally missed), with awk, sed, grep, possibly ed, maybe D, Euphoria, and whatever other seems to be nice for the particular mini thing, I am trying to figure out how to do it for real. (Heck, I may even end up searching around for my Perl book.)
> 
> Do what? Well, a pre-alpha version of a proof-of-concept kind of prototype. Or, if it looks like too much, then I'll try to make a couple different protorypes, each of which would demonstrate some part of the whole.
> 
> Something for #define X(a,b) foo(b,a);bar(a);blabla(a,b,a,b) kind of trivial C preprocessor things. Something else for having a snippet of self-made language inside a procedure instead of writing that too with D (see the sugar-cube robotics example in this thread).
> 
> And then maybe one or a couple of different try-outs for the hairy stuff. With that I dream you could do Lisp like stuff, that's really for "the superhuman". That's a bit hard, since I'm not.  :-(
> 
> -----
> 
> For these pathetic first attempts I'd either make small one-trick-preprocessors, or maybe later get a GDC version that I can compile, and then break the parser and lexer "trying to play Walter"! ;-)  -- With neither his skills, experience, nor abilities.
> 
> If any of these one-trick things does anything useful at all, then I'll post them for others to laugh at. Then at least folks will get a glimpse of some parts of the whole. With any luck there'll be discussion and feedback, to keep us going on!
> 
> If we haven't given up by this time, then we'll try to do the same with some self-made-language inserters. Probably the really first ones will have some arbitrary but fixed language as the "inserted language", later the testers (you gyus) get versions actually capable of doing minilanguages defined in some input file by each of you -- for using and abusing them.
> 
> If we're still at it at this point, then it's time for the hairy stuff. I don't know how we'll test that, without asking some heavyweight hairy-stuffers. I mean, even if a particular preprocessor happened to actually work, where do we find the kind of guys who are actually capable of trying any hairy stuff on them? Or giving meaningful comments??
> 
> Phew! If we're /still/ here, then it'd be time to make a proposal for Walter.