Re: Excluding symbols
On Mon, 20 Apr 2015 21:00:34 +, extrawurst wrote:
> On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:
>> On Mon, 20 Apr 2015 20:31:36 +, extrawurst wrote:
>>
>>> static if(__ctfe){}
>>
>> small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error.
>> ;-)
>
> __ctfe is not readable at compile time ? thats unfortunate..
it will have no sense. DMD is able to eliminate dead code in this case,
so `if (__ctfe)` will generate plain function. and there is no sense in
do `static if` for functions, as functions is not instantiating, i.e.
that will be processed only once, and you will be unable to use function
both in CTFE and in run time.
signature.asc
Description: PGP signature
Re: Excluding symbols
On Mon, Apr 20, 2015 at 09:00:34PM +, extrawurst via Digitalmars-d wrote:
> On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:
> >On Mon, 20 Apr 2015 20:31:36 +, extrawurst wrote:
> >
> >>static if(__ctfe){}
> >
> >small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)
>
> __ctfe is not readable at compile time ? thats unfortunate..
"Compile time" is actually a broad term that is not precise enough to
describe the distinction between template expansion / static if and
CTFE.
Basically, static if and template expansion happens at an earlier stage
of the compilation process -- conceptually speaking, somewhere between
parsing and semantic analysis. Perhaps one could think of it as AST
transformation prior to the AST being interpreted by the compiler. At
this stage, no semantic values (e.g., the state of variables, etc.) are
available, because the AST is not being interpreted yet.
CTFE, on the other hand, conceptually sits between semantic analysis and
code generation, which is at a later stage than the AST transformation
of templates / static if. Basically, at this point the AST is fixed and
the compiler is ready to emit object code, but instead of doing so, runs
it through an interpreter instead. So at this stage the compiler has
enough information to keep track of the values of variables and stuff,
and can simulate the effect of executing code at runtime. However, in
order for this simulation to have well-defined semantics, AST
transformations are no longer possible, so you cannot evaluate static
ifs in the CTFE stage.
This is why the __ctfe magic variable cannot be read at compile-time,
or, to be more precise, at AST transformation time. It can only be read
at CTFE-time.
Of course, this is a greatly simplified picture of how things actually
work in the compiler. The compiler isn't confined to a single AST
tranformation stage followed by a single CTFE stage; the whole point of
CTFE is that the result of the CTFE is fed back into the compiler to
influence AST transformation in another part of the code. This can be
done by running semantic analysis on the code to be CTFE-'d first, so
that it's ready for interpretation when another part of the code that
needs the CTFE value is still in the AST transformation stage.
Everything is eventually resolvable, as long as there are no circular
dependencies.
Nevertheless, the distinction between AST transformation and CTFE is an
important one (at least conceptually). The function being CTFE'd must
be fully compiled before it can be CTFE'd (even if the rest of the code
isn't fully compiled yet), so static if must already be evaluated by the
time CTFE runs. Conversely, a static if / template expansion is by
definition not yet fully compiled, so it cannot evaluate references to
variables, even if said variables exist in CTFE (since CTFE hasn't
started yet at that point).
T
--
I'm still trying to find a pun for "punishment"...
Re: Excluding symbols
On Monday, 20 April 2015 at 20:04:04 UTC, Sönke Ludwig wrote: Am 20.04.2015 um 15:22 schrieb Etienne: I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins. Would there be a way to specify something in the lines of `extern (none):` or `intern:`? Any reason why "private" couldn't be used for this? If a private function is only used for CTFE, there is no need to generate code at all. Need much more powerful flow analysis than DMD frontend is currently capable of. Specifically, it needs to ensure that this function is also not taken address of and not aliased via any of public templates (transitively), as well as not aliased to something available as public.
Re: Excluding symbols
On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:
On Mon, 20 Apr 2015 20:31:36 +, extrawurst wrote:
static if(__ctfe){}
small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error.
;-)
__ctfe is not readable at compile time ? thats unfortunate..
Re: Excluding symbols
On Mon, 20 Apr 2015 20:31:36 +, extrawurst wrote:
> static if(__ctfe){}
small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)
signature.asc
Description: PGP signature
Re: Excluding symbols
On Monday, 20 April 2015 at 13:22:15 UTC, Etienne wrote:
I've been using a lot of CTFE in my libraries and this has had
the side effect of increasing my link time beyond 13 seconds.
There's a pretty big chunk of those symbols being exported that
are used only for evaluating mixins.
Would there be a way to specify something in the lines of
`extern (none):` or `intern:`?
what happens with totally empty functions ? can't they be removed
on compilation ? static if(__ctfe){} could be used to make those
empty for non-ctfe then..
Re: Excluding symbols
Am 20.04.2015 um 15:22 schrieb Etienne: I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins. Would there be a way to specify something in the lines of `extern (none):` or `intern:`? Any reason why "private" couldn't be used for this? If a private function is only used for CTFE, there is no need to generate code at all.
Re: Excluding symbols
On Mon, 20 Apr 2015 13:34:47 +, ketmar wrote: > On Mon, 20 Apr 2015 09:22:17 -0400, Etienne wrote: > >> I've been using a lot of CTFE in my libraries and this has had the side >> effect of increasing my link time beyond 13 seconds. There's a pretty >> big chunk of those symbols being exported that are used only for >> evaluating mixins. >> >> Would there be a way to specify something in the lines of `extern >> (none):` or `intern:`? > > i think you should make ER for this. it will be fine if there will be > the way to tell compiler to skip code generation for some functions > which used only in CTFE. by the way, maybe it will be good to add `extern(CTFE)` too, so hdrgen can emit source code for such functions to .di file. i.e. `extern(none)` -- don't generate code, don't emit to .di `extern(CTFE)` -- don't generate code, emit to .di signature.asc Description: PGP signature
Re: Excluding symbols
On Mon, 20 Apr 2015 09:22:17 -0400, Etienne wrote: > I've been using a lot of CTFE in my libraries and this has had the side > effect of increasing my link time beyond 13 seconds. There's a pretty > big chunk of those symbols being exported that are used only for > evaluating mixins. > > Would there be a way to specify something in the lines of `extern > (none):` or `intern:`? i think you should make ER for this. it will be fine if there will be the way to tell compiler to skip code generation for some functions which used only in CTFE. signature.asc Description: PGP signature
Excluding symbols
I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins. Would there be a way to specify something in the lines of `extern (none):` or `intern:`?
