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