Perhaps this is a philosophical question, like what is time, though it
is also a novice programmer question as well. The question exactly
being:
"What is the difference between a (constant/immutable) value and the
result of calling a side-effect free function that returns the same?"
May I pleas
On Tuesday, July 20, 2010 06:36:57 Justin Johansson wrote:
> Perhaps this is a philosophical question, like what is time, though it
> is also a novice programmer question as well. The question exactly
> being:
>
> "What is the difference between a (constant/immutable) value and the
> result of ca
Jonathan M Davis wrote:
On Tuesday, July 20, 2010 06:36:57 Justin Johansson wrote:
Perhaps this is a philosophical question, like what is time, though it
is also a novice programmer question as well. The question exactly
being:
"What is the difference between a (constant/immutable) value and t
Jonathan M Davis wrote:
Also, the
function could be used in CTFE to produce the value at compile time and just use
that value instead of calling the function at runtime. Depending on how the
function is used and how much optimizing the compiler does, the function may
never get called at runtim
On Tuesday, July 20, 2010 14:28:16 Justin Johansson wrote:
> Jonathan M Davis wrote:
> > Also, the
> > function could be used in CTFE to produce the value at compile time and
> > just use that value instead of calling the function at runtime.
> > Depending on how the function is used and how much o
Jonathan M Davis:
> However, what can be used in CTFE is currently rather limited.
Currently its main limitation is the amount of memory it burns. I think Don
will eventually remove this problem too, even if this requires a half rewrite
of the whole thing :-)
> You also generally have to force
On Tuesday, July 20, 2010 15:49:56 bearophile wrote:
>
> As far as I know, currently optimization level doesn't influence CTFE.
Well, like I said. It depends on what exactly the compiler does, and as far as
I
know, it only does CTFE when it has to for initialization. But theoretically,
it
cou
Jonathan M Davis:
> But theoretically, it
> could be used for optimizations just like inlining (particularly with pure
> functions), and that being the case, it probably will at some point.
Pure functions go well with CTFE because they don't use global state, but you
can run code at compile tim
On Tuesday, July 20, 2010 17:24:33 bearophile wrote:
> Jonathan M Davis:
> > But theoretically, it
> > could be used for optimizations just like inlining (particularly with
> > pure functions), and that being the case, it probably will at some
> > point.
>
> Pure functions go well with CTFE becaus
Jonathan M Davis wrote:
On Tuesday, July 20, 2010 17:24:33 bearophile wrote:
Jonathan M Davis:
But theoretically, it
could be used for optimizations just like inlining (particularly with
pure functions), and that being the case, it probably will at some
point.
Pure functions go well with CTFE
On Wednesday 21 July 2010 00:09:05 Don wrote:
> While running the semantic on each function body, the compiler could
> fairly easily check to see if the function is CTFEable. (The main
> complication is that it has to guess about how many iterations are
> performed in loops). Then, when a CTFEable
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed in loops). Then, when a CTFEable function is called with
compile-time c
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed in loops). Then, when a CTFEable function is calle
On 21-lug-10, at 11:37, Don wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler
could fairly easily check to see if the function is CTFEable. (The
main complication is that it has to guess about how many
iterations are performed in loops)
Walter Bright:
> I'm not seeing CTFE as a credible optimization tool, either, as none of my
> programs would benefit at all from it. For example, what's a text editor going
> to precompute?
The manual partial compilation I have explained is useful for numerical code.
The example where I have seen
Fawzi Mohamed wrote:
On 21-lug-10, at 11:37, Don wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
Jonathan M Davis wrote:
On Wednesday 21 July 2010 00:09:05 Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed in loops). The
Hello Justin,
"What is the difference between a (constant/immutable) value and the
result of calling a side-effect free function that returns the same?"
A const value can't be changed from the current context but could be changed
via another alias or inside a non side effect free function or
Don wrote:
Jonathan M Davis wrote:
On Tuesday, July 20, 2010 17:24:33 bearophile wrote:
Jonathan M Davis:
But theoretically, it
could be used for optimizations just like inlining (particularly with
pure functions), and that being the case, it probably will at some
point.
Pure functions go well
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed in loops). Then, when a CTFEable function is calle
Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed in loops). Then, when
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler
could fairly easily check to see if the function is CTFEable. (The
main complication is that it has to guess about how man
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complication is that it has to guess about how many iterations are
performed
On 23/07/2010 21:54, Don wrote:
I completely agree that there will always be opportunities for CTFE
which will be missed unless you allow the compile time to become
arbitrarily long.
Which is why ultimately it should be up to the programmer to decide.
There should be a way to force the compile
On 07/23/2010 03:18 PM, Walter Bright wrote:
Let's set aside for a moment the problem that CTFE can take an
arbitrarily long time to run and that this cannot be predicted by any
sort of static analysis (isn't this what the halting problem is?).
The halting problem describes a program along with
On 07/23/2010 03:54 PM, Don wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler
could fairly easily check to see if the function is CTFEable. (The
main complication is that it has to guess about
"Walter Bright" wrote in message
news:i2cteh$uf...@digitalmars.com...
Andrei Alexandrescu wrote:
Walter Bright wrote:
Andrei Alexandrescu wrote:
Walter Bright wrote:
Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is
"div0" wrote in message
news:i2d2ek$179...@digitalmars.com...
On 23/07/2010 21:54, Don wrote:
I completely agree that there will always be opportunities for CTFE
which will be missed unless you allow the compile time to become
arbitrarily long.
Which is why ultimately it should be up to th
"Jonathan M Davis" wrote in message
news:mailman.435.1279700666.24349.digitalmar...@puremagic.com...
On Wednesday 21 July 2010 00:09:05 Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (The main
complicatio
On 24/07/2010 12:46, Jim Balter wrote:
"div0" wrote in message
news:i2d2ek$179...@digitalmars.com...
On 23/07/2010 21:54, Don wrote:
I completely agree that there will always be opportunities for CTFE
which will be missed unless you allow the compile time to become
arbitrarily long.
Which
On 24/07/10 12:43 PM, Jim Balter wrote:
I thought that this was exactly the halting problem.
A common misconception, but not so. The halting problem is to find an
algorithm that will, for every possible function and data as input,
correctly determine whether the function will terminate. Turing
div0:
> No they aren't.
> command line options apply to the entire module(s) not to specific
> invocations of a function.
In both GNU C and CLisp you can add annotations to change the optimization
level on a function by function basis:
http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#i
Jim Balter wrote:
"Jonathan M Davis" wrote in message
news:mailman.435.1279700666.24349.digitalmar...@puremagic.com...
On Wednesday 21 July 2010 00:09:05 Don wrote:
While running the semantic on each function body, the compiler could
fairly easily check to see if the function is CTFEable. (T
"Peter Alexander" wrote in message
news:i2er6d$1jk...@digitalmars.com...
On 24/07/10 12:43 PM, Jim Balter wrote:
I thought that this was exactly the halting problem.
A common misconception, but not so. The halting problem is to find an
algorithm that will, for every possible function and data
"Don" wrote in message
news:i2ffm7$2qf...@digitalmars.com...
Jim Balter wrote:
"Jonathan M Davis" wrote in message
news:mailman.435.1279700666.24349.digitalmar...@puremagic.com...
On Wednesday 21 July 2010 00:09:05 Don wrote:
While running the semantic on each function body, the compiler
Don wrote:
Being marked as 'pure' is no guarantee that the function will terminate.
Right, and the compiler makes no attempt to check this, either.
Andrei Alexandrescu wrote:
The analysis I discussed is a flow- and path-independent analysis. It
always terminates and produces conservative results (i.e. it associates
one Boolean with each function, not on each tuple of a function and
inputs. This is how the current compiler works - if you tr
"Jim Balter" wrote in message
news:i2fkp7$2i...@digitalmars.com...
"Peter Alexander" wrote in message
news:i2er6d$1jk...@digitalmars.com...
On 24/07/10 12:43 PM, Jim Balter wrote:
I thought that this was exactly the halting problem.
A common misconception, but not so. The halting problem is
Walter Bright wrote:
Andrei Alexandrescu wrote:
The analysis I discussed is a flow- and path-independent analysis. It
always terminates and produces conservative results (i.e. it
associates one Boolean with each function, not on each tuple of a
function and inputs. This is how the current comp
On 7/24/2010 15:34, Jim Balter wrote:
> The point about difficulty goes to why this is not a matter of the
> halting problem. Even if the halting problem were decidable, that would
> not help us in the slightest because we are trying to solve a
> *practical* problem. Even if you could prove, for ev
Rainer Deyke:
> (A function that performs I/O is
> obviously not a candidate for CTFE.)
I don't fully agree, see this enhancement request of mine:
http://d.puremagic.com/issues/show_bug.cgi?id=3952
Bye,
bearophile
"Rainer Deyke" wrote in message
news:i2g3oo$vo...@digitalmars.com...
On 7/24/2010 15:34, Jim Balter wrote:
The point about difficulty goes to why this is not a matter of the
halting problem. Even if the halting problem were decidable, that would
not help us in the slightest because we are try
"bearophile" wrote in message
news:i2g42t$10c...@digitalmars.com...
Rainer Deyke:
(A function that performs I/O is
obviously not a candidate for CTFE.)
I don't fully agree, see this enhancement request of mine:
http://d.puremagic.com/issues/show_bug.cgi?id=3952
Bye,
bearophile
"performs
"Walter Bright" wrote in message
news:i2flvi$4i...@digitalmars.com...
Don wrote:
Being marked as 'pure' is no guarantee that the function will terminate.
Right, and the compiler makes no attempt to check this, either.
Of course the compiler makes no attempt to check -- that *would* be the
Jim Balter wrote:
"Rainer Deyke" wrote in message
news:i2g3oo$vo...@digitalmars.com...
On 7/24/2010 15:34, Jim Balter wrote:
The point about difficulty goes to why this is not a matter of the
halting problem. Even if the halting problem were decidable, that would
not help us in the slightest
Jim Balter wrote:
"Walter Bright" wrote in message
news:i2flvi$4i...@digitalmars.com...
Don wrote:
Being marked as 'pure' is no guarantee that the function will terminate.
Right, and the compiler makes no attempt to check this, either.
Of course the compiler makes no attempt to check -- th
On 7/25/2010 13:41, Jim Balter wrote:
> But there are
> (at least) two problems: 1) you can't be certain that the code will be
> run at run time at all -- in generic code you could easily have function
> invocations with constant values that would fail in various ways but the
> function is never ru
"Don" wrote in message
news:i2ice7$2i7...@digitalmars.com...
Jim Balter wrote:
"Walter Bright" wrote in message
news:i2flvi$4i...@digitalmars.com...
Don wrote:
Being marked as 'pure' is no guarantee that the function will
terminate.
Right, and the compiler makes no attempt to check this,
"Rainer Deyke" wrote in message
news:i2jeja$1lh...@digitalmars.com...
On 7/25/2010 13:41, Jim Balter wrote:
But there are
(at least) two problems: 1) you can't be certain that the code will be
run at run time at all -- in generic code you could easily have function
invocations with constant v
On 7/26/2010 18:30, Jim Balter wrote:
> Consider some code that calls a pure function that uses a low-overhead
> exponential algorithm when the parameter is small, and otherwise calls a
> pure function that uses a high-overhead linear algorithm. The calling
> code happens not to be CTFEable and thu
Rainer Deyke wrote:
On 7/26/2010 18:30, Jim Balter wrote:
Consider some code that calls a pure function that uses a low-overhead
exponential algorithm when the parameter is small, and otherwise calls a
pure function that uses a high-overhead linear algorithm. The calling
code happens not to be C
52 matches
Mail list logo
