On 2/06/2015 10:15 p.m., ketmar wrote:
On Tue, 02 Jun 2015 21:51:54 +1200, Rikki Cattermole wrote:
Essentially its compiler plugins that can add news types +
free-functions as if it was D code provided by source code only also
able to modify e.g. AST directly.
So while in of itself would not provide new language features, it could
add some very nice behavior to existing ones.
So what you want with commands ext. would be done in a shared library.
It have e.g. a struct added into object.d(i).
__CEIFileSystem.delete("./tmp/something");
Of course adding these plugins should be pretty explicit. Package
maintainers for example shouldn't auto install any. There should be no
way to auto install them.
Basically dmd-plugin-dub-bin would be an example package. That would add
dub support directly into dmd.
----------
@__CEIDub.Dependency("vibe-d", ">=0.7.22")
void main() {
// what have you
}
----------
Or:
----------
static assert(__CEIDub.dependency("vibe.d", ">=0.7.22"), "Requires
vibe-d 0.7.22 or newer.");
void main() {
// what have you
}
----------
That way it can be used for e.g. static-if and template if.
Of course I'm sure Walter would go nuts at such an idea, if it was
seriously proposed.
So perhaps dmd doesn't support it. Instead a new version of dmd is also
shipped (dmdext) with this enabled ;)
With the community agreeing that we should try to keep as close to dmd
as possible and only reverting to dmdext + plugins to help newbies and
where it just wouldn't be possible to not have an external tool. Which
most likely uses multiple compilation or something else not so nice.
actually, that should be doable with DDMD on non-windows systems*, i
believe. DDMD -- to avoid writing plugins in other languages. ;-) and
with DDMD plugins will have full access to frontend internals, including
AST manipulation.
* non-windows, as dll support on windows is still not here, i believe.
I've been able to do it a little bit already with my Web server. Haven't
hit its limit so far. In other words as long as exceptions aren't used
and its never unloaded, should be ok. Anyway, do you really think we
would get that sort of support for a couple of releases?
the downside of this approach is that it's highly compiler-specific. i.e.
one will force to have different plugins for GDC/LDC/SDC/etc. ;-) and
with pure CTFE API without plugins, only with external executables, it
will be compiler-agnostic, any compiler using DMDFE will get it for free.
only SDC will be forced to rewrite the CTFE part, but other than that all
CTFE D code will work the same.
Yeah it is, but it would also mean better customization of the build
process!
i mean, 'cmon, we have such great built-in scripting engine, let's use it!
Indeed lets. But can we also not go modifying the language? I'm just
suggesting injecting of symbols that execute compiler side actions. Your
suggesting language changes. Even if it is a new pragma.
your samples can be built ontop of my "subcommand" proposal, for example.
let's say that compiler will try to automatically do static import
"DMD.subcommands.dub" when programmer writing something like
`DMD.dub.Dependency("vibe-d", ">=0.7.22");`, falling back to "DMD.failure
(name, args)" if there is no "dub" subcommand package.
and then subcommand can execute dub, parse it's output and do what it
wants. or one can make a local override for subcommand -- without even
compiling separate plugin.
that's how i see it.
We really need to toy with these ideas properly and implement each. Then
its just a matter of time to convince the higher ups that it should be
merged.
