www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - grammar

reply G.Vidal <G.Vidal_member pathlink.com> writes:
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.
Mar 03 2005
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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
Mar 03 2005
parent reply G.Vidal <G.Vidal_member pathlink.com> writes:
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 !
Mar 03 2005
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
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 !
Mar 03 2005
prev sibling parent reply Paul Bonser <misterpib gmail.com> writes:
 
 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
Mar 03 2005
parent reply G.Vidal <G.Vidal_member pathlink.com> writes:
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
Mar 04 2005
next sibling parent "Nick Sabalausky" <z a.a> writes:
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
Mar 04 2005
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
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
Mar 04 2005
prev sibling parent reply Paul Bonser <misterpib gmail.com> writes:
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
Mar 04 2005
parent reply "Craig Black" <cblack ara.com> writes:
 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
Mar 04 2005
parent Paul Bonser <misterpib gmail.com> writes:
Craig Black wrote:
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
Sounds reasonable. -- -PIB -- "C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch
Mar 04 2005
prev sibling parent Jeff <gyvidal wanadoo.fr> writes:
As the subject changed, (yacc -> plugin) I suggest everybody now to post
in the new thread called: "plugin(name) {}"
(don't make any difference for the ones using the web interface though)

Thank you very much.

GV
Mar 05 2005