What would be really great is to include a grammar generator (such as YACC) but inside the D compiler. So we can write the grammar description inside the source code and let the compiler do the rest, so the actual parser code would be totally invisible.

This would be absolutely great, and make D an ideal tool for writing other languages.

and it's actually very easy to implement.

In article <d07c0b$31do$1@digitaldaemon.com>, G.Vidal says...
>
>What would be really great is to include a grammar generator (such as YACC) but inside the D compiler. So we can write the grammar description inside the source code and let the compiler do the rest, so the actual parser code would be totally invisible.
>
>This would be absolutely great, and make D an ideal tool for writing other languages.
>
>and it's actually very easy to implement.

Since it's so easy to do, perhaps you'd like to volunteer to do it. The DMD front end is already open source. Have at it. ;)

By the way, check out http://www.prowiki.org/wiki4d/wiki.cgi?GrammarParsers for D grammar goodies.

jcc7

In article <d07k7b$af6$1@digitaldaemon.com>, J C Calvarese says...
>
>In article <d07c0b$31do$1@digitaldaemon.com>, G.Vidal says...
>>
>>What would be really great is to include a grammar generator (such as YACC) but inside the D compiler. So we can write the grammar description inside the source code and let the compiler do the rest, so the actual parser code would be totally invisible.
>>
>>This would be absolutely great, and make D an ideal tool for writing other languages.
>>
>>and it's actually very easy to implement.
>
>Since it's so easy to do, perhaps you'd like to volunteer to do it. The DMD front end is already open source. Have at it. ;)
>
>By the way, check out http://www.prowiki.org/wiki4d/wiki.cgi?GrammarParsers for D grammar goodies.
>
>jcc7

---

Idea: create some kind of plug-ins for DMD with the folowing syntax:

plugin (name) {
Anything directly sent to the plugin and not parsed by dmd.
Like grammars, regexp, anything.
}


When DMD find this "plugin" statement, it send the code to the plugin witch parse it and send back some D code.

This way, the compiler will be fully extensible, and can embed any extra code !


Then if we had a YACC-kindda plugin:

plugin (grammar) {
body: statement statement_list "END";
statement_list: statement statement_list;

statement: VAR(a) "=" THING(b) {
some D code
}

// etc...
}


I had this idea when I read the thread concerning "stable functions" or something.

Man, this would rock !

You might want to evaluate something like this:
http://opencxx.sourceforge.net/

-eye

G.Vidal wrote:
> Idea: create some kind of plug-ins for DMD with the folowing syntax:
> 
> plugin (name) {
> Anything directly sent to the plugin and not parsed by dmd.
> Like grammars, regexp, anything.
> }
> 
> 
> When DMD find this "plugin" statement, it send the code to the plugin witch
> parse it and send back some D code.
> 
> This way, the compiler will be fully extensible, and can embed any extra code !
> 
> 
> Then if we had a YACC-kindda plugin:
> 
> plugin (grammar) {
> body: statement statement_list "END";
> statement_list: statement statement_list;
> 
> statement: VAR(a) "=" THING(b) {
> some D code
> }
> 
> // etc...
> }
> 
> 
> I had this idea when I read the thread concerning "stable functions" or
> something.
> 
> Man, this would rock !

> 
> Idea: create some kind of plug-ins for DMD with the folowing syntax:
> 
> plugin (name) {
> Anything directly sent to the plugin and not parsed by dmd.
> Like grammars, regexp, anything.
> }
> 
> 
> When DMD find this "plugin" statement, it send the code to the plugin witch
> parse it and send back some D code.
> 
> This way, the compiler will be fully extensible, and can embed any extra code !
> 
> 
> Then if we had a YACC-kindda plugin:
> 
> plugin (grammar) {
> body: statement statement_list "END";
> statement_list: statement statement_list;
> 
> statement: VAR(a) "=" THING(b) {
> some D code
> }
> 
> // etc...
> }
> 
> 
> I had this idea when I read the thread concerning "stable functions" or
> something.
> 
> Man, this would rock !
> 

Hmm, I do like the sound of that, for certain projects I could see if being of some value.

Somehow I don't see Walter going for it (I could be completely wrong, I've not been observing him for too long :P), but it wouldn't really destroy any of the goals of the language...I don't think. It would be a very simple grammar rule to add, I think: from the "plugin (something) {" to the closing "}", just pass it on, then parse what is passed back as if it was there originally, maybe with some sort of internal note that it is inserted, for debuggin's sake (I don't really know, just throwing out ideas).

However, as I think Walter has already got his fair share of stuff to do, I would propose that the first incarnation of this construct could be included with a program such a build, which already acts as a bit of a preprocessor (with the build and nobuild pragmas).

What kind of form were you thinking these "plugins" could be in? I think for the most flexibility, they should simply be any sort of program or script that could be called from the command-line, take the standard input and put to the standard output. That way it could be a shell script, a compiled program, an interpreted program, or any combination of the three.

I think this could be a powerful tool (in certain circumstances, a powerful hack for those who just *need* a preprocessor...I never liked all that preprocessor stuff myself), allowing you to do things best suited to *not* being written in D within D code, while still keeping things separate and not so mixed in as preprocessor stuff.

plugin (ascii_art) {
      .--.   |V|
     /    \ _| /
     q .. p \ /
      \--/  //
jgs  __||__//
    /.    _/
   // \  /
  //   ||
  \\  /  \
   )\|    |
  / || || |
  |/\| || |
     | || |
     \ || /
   __/ || \__
  \____/\____/
}

which calls a simple shell script which uses sed to add `writefln("` to the beginning of every line and `");` to the end.
Not a very useful example, but an example nonetheless, and one that exhibits the behavior of the proposed idea well, I think.
Having a single, simple front-end that just passes the text we're interested in processing to the script, makes it so we can write simple scripts (or programs) to do just what we want and not have to scan and parse through a whole D source file.
There are endless possibilities for meta-programming applications (IDL? Reflection? Direct insertion of functions written in other languages?) for this, so I'll shut up now and see what others have to say about it.

I have a Sociology paper I should be writing...


OT p.s. It just occurred to me that plug-ins, technically (or Englishically, as it were) should actually be plugs-in...a-la passers-by, etc...
Okay, I'm really going to finish this post now...
-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch

>Somehow I don't see Walter going for it

Then I ask: Walter, would you be going for it ?
Really this metaprogramming thing worth it, if it's not in the D compiler itself
then I ask the one who's creating BUILD if it could be possible.

I see it perfectly as you described it, a simple script or program that take code in its stdin and send back D code in its stdout.





In article <d094ge$eqf$1@digitaldaemon.com>, Paul Bonser says...
>
>
>> 
>> Idea: create some kind of plug-ins for DMD with the folowing syntax:
>> 
>> plugin (name) {
>> Anything directly sent to the plugin and not parsed by dmd.
>> Like grammars, regexp, anything.
>> }
>> 
>> 
>> When DMD find this "plugin" statement, it send the code to the plugin witch parse it and send back some D code.
>> 
>> This way, the compiler will be fully extensible, and can embed any extra code !
>> 
>> 
>> Then if we had a YACC-kindda plugin:
>> 
>> plugin (grammar) {
>> body: statement statement_list "END";
>> statement_list: statement statement_list;
>> 
>> statement: VAR(a) "=" THING(b) {
>> some D code
>> }
>> 
>> // etc...
>> }
>> 
>> 
>> I had this idea when I read the thread concerning "stable functions" or something.
>> 
>> Man, this would rock !
>> 
>
>Hmm, I do like the sound of that, for certain projects I could see if being of some value.
>
>Somehow I don't see Walter going for it (I could be completely wrong, I've not been observing him for too long :P), but it wouldn't really destroy any of the goals of the language...I don't think. It would be a very simple grammar rule to add, I think: from the "plugin (something) {" to the closing "}", just pass it on, then parse what is passed back as if it was there originally, maybe with some sort of internal note that it is inserted, for debuggin's sake (I don't really know, just throwing out ideas).
>
>However, as I think Walter has already got his fair share of stuff to do, I would propose that the first incarnation of this construct could be included with a program such a build, which already acts as a bit of a preprocessor (with the build and nobuild pragmas).
>
>What kind of form were you thinking these "plugins" could be in? I think for the most flexibility, they should simply be any sort of program or script that could be called from the command-line, take the standard input and put to the standard output. That way it could be a shell script, a compiled program, an interpreted program, or any combination of the three.
>
>I think this could be a powerful tool (in certain circumstances, a powerful hack for those who just *need* a preprocessor...I never liked all that preprocessor stuff myself), allowing you to do things best suited to *not* being written in D within D code, while still keeping things separate and not so mixed in as preprocessor stuff.
>
>plugin (ascii_art) {
>       .--.   |V|
>      /    \ _| /
>      q .. p \ /
>       \--/  //
>jgs  __||__//
>     /.    _/
>    // \  /
>   //   ||
>   \\  /  \
>    )\|    |
>   / || || |
>   |/\| || |
>      | || |
>      \ || /
>    __/ || \__
>   \____/\____/
>}
>
>which calls a simple shell script which uses sed to add `writefln("` to
>the beginning of every line and `");` to the end.
>Not a very useful example, but an example nonetheless, and one that
>exhibits the behavior of the proposed idea well, I think.
>Having a single, simple front-end that just passes the text we're
>interested in processing to the script, makes it so we can write simple
>scripts (or programs) to do just what we want and not have to scan and
>parse through a whole D source file.
>There are endless possibilities for meta-programming applications (IDL?
>Reflection? Direct insertion of functions written in other languages?)
>for this, so I'll shut up now and see what others have to say about it.
>
>I have a Sociology paper I should be writing...
>
>
>OT p.s. It just occurred to me that plug-ins, technically (or
>Englishically, as it were) should actually be plugs-in...a-la
>passers-by, etc...
>Okay, I'm really going to finish this post now...
>-- 
>-PIB
>
>--
>"C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch

This stuff does seem pretty nice. A similar concept to inline assembly, but more generalized.

"G.Vidal" <G.Vidal_member@pathlink.com> wrote in message news:d0a0ol$1evt$1@digitaldaemon.com...
>
>
>>Somehow I don't see Walter going for it
>
> Then I ask: Walter, would you be going for it ?
> Really this metaprogramming thing worth it, if it's not in the D compiler
> itself
> then I ask the one who's creating BUILD if it could be possible.
>
> I see it perfectly as you described it, a simple script or program that
> take
> code in its stdin and send back D code in its stdout.
>
>
>
>
>
> In article <d094ge$eqf$1@digitaldaemon.com>, Paul Bonser says...
>>
>>
>>>
>>> Idea: create some kind of plug-ins for DMD with the folowing syntax:
>>>
>>> plugin (name) {
>>> Anything directly sent to the plugin and not parsed by dmd.
>>> Like grammars, regexp, anything.
>>> }
>>>
>>>
>>> When DMD find this "plugin" statement, it send the code to the plugin
>>> witch
>>> parse it and send back some D code.
>>>
>>> This way, the compiler will be fully extensible, and can embed any extra code !
>>>
>>>
>>> Then if we had a YACC-kindda plugin:
>>>
>>> plugin (grammar) {
>>> body: statement statement_list "END";
>>> statement_list: statement statement_list;
>>>
>>> statement: VAR(a) "=" THING(b) {
>>> some D code
>>> }
>>>
>>> // etc...
>>> }
>>>
>>>
>>> I had this idea when I read the thread concerning "stable functions" or something.
>>>
>>> Man, this would rock !
>>>
>>
>>Hmm, I do like the sound of that, for certain projects I could see if being of some value.
>>
>>Somehow I don't see Walter going for it (I could be completely wrong, I've not been observing him for too long :P), but it wouldn't really destroy any of the goals of the language...I don't think. It would be a very simple grammar rule to add, I think: from the "plugin (something) {" to the closing "}", just pass it on, then parse what is passed back as if it was there originally, maybe with some sort of internal note that it is inserted, for debuggin's sake (I don't really know, just throwing out ideas).
>>
>>However, as I think Walter has already got his fair share of stuff to do, I would propose that the first incarnation of this construct could be included with a program such a build, which already acts as a bit of a preprocessor (with the build and nobuild pragmas).
>>
>>What kind of form were you thinking these "plugins" could be in? I think for the most flexibility, they should simply be any sort of program or script that could be called from the command-line, take the standard input and put to the standard output. That way it could be a shell script, a compiled program, an interpreted program, or any combination of the three.
>>
>>I think this could be a powerful tool (in certain circumstances, a powerful hack for those who just *need* a preprocessor...I never liked all that preprocessor stuff myself), allowing you to do things best suited to *not* being written in D within D code, while still keeping things separate and not so mixed in as preprocessor stuff.
>>
>>plugin (ascii_art) {
>>       .--.   |V|
>>      /    \ _| /
>>      q .. p \ /
>>       \--/  //
>>jgs  __||__//
>>     /.    _/
>>    // \  /
>>   //   ||
>>   \\  /  \
>>    )\|    |
>>   / || || |
>>   |/\| || |
>>      | || |
>>      \ || /
>>    __/ || \__
>>   \____/\____/
>>}
>>
>>which calls a simple shell script which uses sed to add `writefln("` to
>>the beginning of every line and `");` to the end.
>>Not a very useful example, but an example nonetheless, and one that
>>exhibits the behavior of the proposed idea well, I think.
>>Having a single, simple front-end that just passes the text we're
>>interested in processing to the script, makes it so we can write simple
>>scripts (or programs) to do just what we want and not have to scan and
>>parse through a whole D source file.
>>There are endless possibilities for meta-programming applications (IDL?
>>Reflection? Direct insertion of functions written in other languages?)
>>for this, so I'll shut up now and see what others have to say about it.
>>
>>I have a Sociology paper I should be writing...
>>
>>
>>OT p.s. It just occurred to me that plug-ins, technically (or
>>Englishically, as it were) should actually be plugs-in...a-la
>>passers-by, etc...
>>Okay, I'm really going to finish this post now...
>>-- 
>>-PIB
>>
>>--
>>"C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch
>
> 

On Fri, 4 Mar 2005 16:01:25 +0000 (UTC), G.Vidal wrote:

>>Somehow I don't see Walter going for it
> 
> Then I ask: Walter, would you be going for it ?
> Really this metaprogramming thing worth it, if it's not in the D compiler itself
> then I ask the one who's creating BUILD if it could be possible.
> 
> I see it perfectly as you described it, a simple script or program that take code in its stdin and send back D code in its stdout.
> 
> 
> 
> 
> 
> In article <d094ge$eqf$1@digitaldaemon.com>, Paul Bonser says...
>>
>>
>>> 
>>> Idea: create some kind of plug-ins for DMD with the folowing syntax:
>>> 
>>> plugin (name) {
>>> Anything directly sent to the plugin and not parsed by dmd.
>>> Like grammars, regexp, anything.
>>> }
>>> 
>>> 
>>> When DMD find this "plugin" statement, it send the code to the plugin witch parse it and send back some D code.
>>> 
>>> This way, the compiler will be fully extensible, and can embed any extra code !
>>> 
>>> 
>>> Then if we had a YACC-kindda plugin:
>>> 
>>> plugin (grammar) {
>>> body: statement statement_list "END";
>>> statement_list: statement statement_list;
>>> 
>>> statement: VAR(a) "=" THING(b) {
>>> some D code
>>> }
>>> 
>>> // etc...
>>> }
>>> 
>>> 
>>> I had this idea when I read the thread concerning "stable functions" or something.
>>> 
>>> Man, this would rock !
>>> 
>>
>>Hmm, I do like the sound of that, for certain projects I could see if being of some value.
>>
>>Somehow I don't see Walter going for it (I could be completely wrong, I've not been observing him for too long :P), but it wouldn't really destroy any of the goals of the language...I don't think. It would be a very simple grammar rule to add, I think: from the "plugin (something) {" to the closing "}", just pass it on, then parse what is passed back as if it was there originally, maybe with some sort of internal note that it is inserted, for debuggin's sake (I don't really know, just throwing out ideas).
>>
>>However, as I think Walter has already got his fair share of stuff to do, I would propose that the first incarnation of this construct could be included with a program such a build, which already acts as a bit of a preprocessor (with the build and nobuild pragmas).
>>
>>What kind of form were you thinking these "plugins" could be in? I think for the most flexibility, they should simply be any sort of program or script that could be called from the command-line, take the standard input and put to the standard output. That way it could be a shell script, a compiled program, an interpreted program, or any combination of the three.
>>
>>I think this could be a powerful tool (in certain circumstances, a powerful hack for those who just *need* a preprocessor...I never liked all that preprocessor stuff myself), allowing you to do things best suited to *not* being written in D within D code, while still keeping things separate and not so mixed in as preprocessor stuff.
>>
>>plugin (ascii_art) {
>>       .--.   |V|
>>      /    \ _| /
>>      q .. p \ /
>>       \--/  //
>>jgs  __||__//
>>     /.    _/
>>    // \  /
>>   //   ||
>>   \\  /  \
>>    )\|    |
>>   / || || |
>>   |/\| || |
>>      | || |
>>      \ || /
>>    __/ || \__
>>   \____/\____/
>>}
>>
>>which calls a simple shell script which uses sed to add `writefln("` to
>>the beginning of every line and `");` to the end.
>>Not a very useful example, but an example nonetheless, and one that
>>exhibits the behavior of the proposed idea well, I think.
>>Having a single, simple front-end that just passes the text we're
>>interested in processing to the script, makes it so we can write simple
>>scripts (or programs) to do just what we want and not have to scan and
>>parse through a whole D source file.
>>There are endless possibilities for meta-programming applications (IDL?
>>Reflection? Direct insertion of functions written in other languages?)
>>for this, so I'll shut up now and see what others have to say about it.
>>
>>I have a Sociology paper I should be writing...
>>
>>
>>OT p.s. It just occurred to me that plug-ins, technically (or
>>Englishically, as it were) should actually be plugs-in...a-la
>>passers-by, etc...
>>Okay, I'm really going to finish this post now...
>>-- 
>>-PIB
>>
>>--
>>"C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch

Sounds interesting. I'll add it to the ToDo list.
-- 
Derek Parnell
Melbourne, Australia
5/03/2005 8:03:59 AM

G.Vidal wrote:
>>Somehow I don't see Walter going for it
> 
> 
> Then I ask: Walter, would you be going for it ?
> Really this metaprogramming thing worth it, if it's not in the D compiler itself
> then I ask the one who's creating BUILD if it could be possible.
> 
> I see it perfectly as you described it, a simple script or program that take
> code in its stdin and send back D code in its stdout.
<cut>

I just realized one situation where there might be a little trouble with it, and that's if you want to put brackets inside the plugin area.

How about using {` and `} in that case? (those are the backwards single-quotes used in the WYSIWYG strings)
Is there a better way that someone can think of?

-- 
-PIB

--
"C++ also supports the notion of *friends*: cooperative classes that
are permitted to see each other's private parts." - Grady Booch

> I just realized one situation where there might be a little trouble with it, and that's if you want to put brackets inside the plugin area.

Within the { ... } the code would have to follow some simple rules, for example following the C rules for {} [] () "" ''

Thus you could have brackets inside the plugin code are as long as you follow those rules.

-Craig