www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - plugin (name) { }

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.

The proper syntax should be:
plugin (name, arg_list) { anything }
"name" is the name of the program to call, "arg_list" some parameters to pass.

The advantage is obvious, with this, the D language can be extended without
changing the specification, so the code will always be fully compatible.





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 reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 The proper syntax should be:
 plugin (name, arg_list) { anything }
 "name" is the name of the program to call, "arg_list" some parameters to 
 pass.


I personally think this might be better handled with a pragma(plugin, name, 
params..).  This plugin concept seems more like a complier-specific 
extension than anything.  Adding the plugin keyword as part of the base 
language only bloats the minimum spec.  And it's a lot more graceful for a 
third-party compiler to fail on something that's not guaranteed to work, 
like a pragma, than simply not implementing a keyword.
Mar 04 2005
parent "G.Vidal" <gyvidal wanadoo.fr> writes:
Le Fri, 04 Mar 2005 19:43:15 -0500, Jarrett Billingsley a écrit :


 The proper syntax should be:
 plugin (name, arg_list) { anything }
 "name" is the name of the program to call, "arg_list" some parameters to 
 pass.


 
 I personally think this might be better handled with a pragma(plugin, name, 
 params..).  This plugin concept seems more like a complier-specific 
 extension than anything.  Adding the plugin keyword as part of the base 
 language only bloats the minimum spec.  And it's a lot more graceful for a 
 third-party compiler to fail on something that's not guaranteed to work, 
 like a pragma, than simply not implementing a keyword.


I agree, even if I was the one to propose the plugin() construct I now
realize that the pragma is a better solution. Except if we decide to make
metaprogramming a D specification, but I'm not sure everyone would agree
with that, and I respect that.

It is really compiler-specific: maybe somebody would create a plugin as a
BASH script and publish it on the internet (say, we could create a web
page for D plugins) so this particular plugin wont work on a windows
environment.

So maybe plugins should be written in D, so we can publish on the
D-plugins page the D sources, so all the plugins will compile on any
system, so everybody's happy.

About the "}" issue, I suggest folowing the C syntax rules as it was said.
If people don't agree, maybe we could think of something like this:

pragma (plugin_start,name)
...
code
...
pragma (plugin_stop)


But this is really ugglier.

What do you guys think..

G.VIDAL
Mar 05 2005
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
Good idea.  But I like the simpler syntax:

plugin(name) { ... }

Any arguments can be passed into the code block.

-Craig
Mar 04 2005
prev sibling next sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
G.Vidal <G.Vidal_member pathlink.com> wrote:

[...]

 so the code will always be fully compatible. 


[...]

Please prove that.

-manfred
Mar 04 2005
prev sibling parent reply xs0 <xs0 xs0.com> writes:
Hmm, neat idea, but I think that using { and } is not very good - I 
guess that many things this would be used for use } themselves, so it 
might be better to have {{{ and }}}, or even any number of {'s and a 
matching number of }'s?

plugin(dyacc)
{{{{{{{{{{{{{{

A: B C { do_something(); }

}}}}}}}}}}}}}}
Mar 05 2005
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"xs0" <xs0 xs0.com> skrev i en meddelelse 
news:d0c19o$cs5$1 digitaldaemon.com...

 Hmm, neat idea, but I think that using { and } is not very good


I feel that such a feature is not a language issue, but rather belongs to 
some sort of integration platform. Anyhow, the same problem appears in shell 
scripts too. Here it is solved with here-documents by defining an identifier 
that ends the embedded sequence; ie.

    command <<EndOfFile
    <embedded file>
    EndOfFile
    more commands....

Regards,
Martin
Mar 05 2005
parent xs0 <xs0 xs0.com> writes:
Hmm, you could say it's an integration issue, but it'd still be a neat 
feature to have.

Consider, for a simple example, having a list of something in a 
database, and you want to compile it into the program. Now, you have to 
write a proggy to get it from the database and put it into a file, 
create a code file with the missing data somehow tagged (perhaps by 
#include "data.txt"), run both through some (pre)processor (producing 
another code file), and finally compile the new code. If you use CVS (or 
something similar), you need to tag the data file and the final file as 
ignorable; finally you need to set up your build environment so that the 
whole process happens automatically, which may or may not be trivial.

OTOH, if this was implemented, you could write a compiler plugin (this 
can just be as simple as something that reads from stdin and writes to 
stdout, as was suggested) that takes an SQL statement and produces any 
output you want (you'd have to do this in both cases, although in the 
current system, you'll probably need yet another file for the template), 
and that's it..

And even if D is made extensible in some way in the future, it will 
still not allow defining arbitrary constructs, as in having a completely 
different syntax for, say, grammar specifications (at least I can't see 
how that could be done), so this feature will still be useful.


xs0


Martin M. Pedersen wrote:

 "xs0" <xs0 xs0.com> skrev i en meddelelse 
 news:d0c19o$cs5$1 digitaldaemon.com...
 

Hmm, neat idea, but I think that using { and } is not very good


 
 
 I feel that such a feature is not a language issue, but rather belongs to 
 some sort of integration platform. Anyhow, the same problem appears in shell 
 scripts too. Here it is solved with here-documents by defining an identifier 
 that ends the embedded sequence; ie.
 
     command <<EndOfFile
     <embedded file>
     EndOfFile
     more commands....
 
 Regards,
 Martin
Mar 05 2005