To: NG D
Subject: Re: To help LDC/GDC
This D code comes from a Haskell solution by tanakh of the
Lawnmower problem of the Google Code Jam 2013 Qualification Round:
import std.stdio, std.string, std.conv, std.range, std.algorithm;
void main() {
immutable n = stdin.readln.strip.to!int
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the function's parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an up-front declaration
which would make the compiler shout if those necessary conditions were not
On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright wrote:
On 4/10/2013 5:33 PM, deadalnix wrote:
call with const parameter can be considered strongly pure if
the argument is
immutable
The argument doesn't need to be immutable because nobody can
change it while the function is
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
function's parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an
up-front
On Thu, 11 Apr 2013 12:03:38 +0200, deadalnix deadal...@gmail.com wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling
wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the function's
parameters as
const or immutable.
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
function's parameters as
const or immutable.
Sure, I
2013/4/11 John Colvin john.loughran.col...@gmail.com
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
On Thursday, 11 April 2013 at 10:27:55 UTC, kenji hara wrote:
2013/4/11 John Colvin john.loughran.col...@gmail.com
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright
On 04/11/2013 12:03 PM, deadalnix wrote:
Both are strongly pure.
Perhaps the fact that I can have this misunderstanding is itself an argument for
an explicit strong pure keyword, so that a daft bugger like me can really be
sure he's getting what he thinks he's getting? :-)
Apart from that, I
On Thursday, 11 April 2013 at 10:16:39 UTC, John Colvin wrote:
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and
On 2013-04-11 12:09, Simen Kjærås wrote:
That's not the point. The point is, if he'd written this:
strong pure bar(int* n) { ... }
The compiler would have said 'Bad programmer! int* is not implicitly
castable to immutable!'
What's the point of that. Just have strong mean const/immutable
On 04/11/2013 03:29 PM, Jacob Carlborg wrote:
What's the point of that. Just have strong mean const/immutable parameters.
The point is to have a way for me, the programmer, to say to the compiler: I
mean for this function to be strongly pure, can you confirm whether my choice of
function inputs
On 11 April 2013 11:09, Simen Kjærås simen.kja...@gmail.com wrote:
On Thu, 11 Apr 2013 12:03:38 +0200, deadalnix deadal...@gmail.com wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the
On 11 April 2013 14:38, Joseph Rushton Wakeling
joseph.wakel...@webdrake.net wrote:
On 04/11/2013 03:29 PM, Jacob Carlborg wrote:
What's the point of that. Just have strong mean const/immutable
parameters.
The point is to have a way for me, the programmer, to say to the compiler:
I
mean
On 04/11/2013 03:49 PM, Iain Buclaw wrote:
Great, just what we need. A compiler that barrages the user about how bad his
code is, then dies...
Compiler says no ...
On 04/11/2013 03:53 PM, Iain Buclaw wrote:
I think that giving the user choice of purity is about as useful as given user
choice over what functions should be inlined, or what vars should go in
registers.
Well, I don't mean the compiler should guarantee that my code will be optimized
in a
On 4/11/2013 3:02 AM, deadalnix wrote:
On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright wrote:
On 4/10/2013 5:33 PM, deadalnix wrote:
call with const parameter can be considered strongly pure if the argument is
immutable
The argument doesn't need to be immutable because nobody can
On 2013-04-11 15:53, Iain Buclaw wrote:
I think that giving the user choice of purity is about as useful as
given user choice over what functions should be inlined, or what vars
should go in registers.
Such decisions are best left to the compiler devs judgement on doing the
right thing for
On 2013-04-11 15:38, Joseph Rushton Wakeling wrote:
The point is to have a way for me, the programmer, to say to the compiler: I
mean for this function to be strongly pure, can you confirm whether my choice of
function inputs supports this please?
Why should I have to explicitly specify
On 04/11/2013 07:48 AM, Walter Bright wrote:
On 4/10/2013 10:44 PM, Timon Gehr wrote:
On 04/10/2013 11:50 PM, Walter Bright wrote:
...
My point was that competing designs are very probably not necessary. We
just need to pull on the string on what must be.
Yes, IMO it is quite obvious how
On 04/11/2013 08:16 PM, Jacob Carlborg wrote:
Why should I have to explicitly specify immutable when that could be default
for strongly pure functions?
Oh, sorry, I misunderstood your meaning. I thought you were saying that a
strong pure keyword wasn't necessary because it was sufficient to
On Thursday, 11 April 2013 at 17:52:43 UTC, Walter Bright wrote:
On 4/11/2013 3:02 AM, deadalnix wrote:
On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright
wrote:
On 4/10/2013 5:33 PM, deadalnix wrote:
call with const parameter can be considered strongly pure if
the argument is
On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
Agree on it being great and innovative. But I fail to see
usefulness with current design. Can you provide examples how
current pure design allows for better code / optimizations?
Strongly pure functions can call weakly pure
On Wednesday, 10 April 2013 at 08:19:26 UTC, Dicebot wrote:
On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
Agree on it being great and innovative. But I fail to see
usefulness with current design. Can you provide examples how
current pure design allows for better code /
On Wednesday, 10 April 2013 at 11:22:41 UTC, deadalnix wrote:
On Wednesday, 10 April 2013 at 08:19:26 UTC, Dicebot wrote:
On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
Agree on it being great and innovative. But I fail to see
usefulness with current design. Can you provide
On 4/10/13 7:29 AM, Dicebot wrote:
On Wednesday, 10 April 2013 at 11:22:41 UTC, deadalnix wrote:
On Wednesday, 10 April 2013 at 08:19:26 UTC, Dicebot wrote:
On Wednesday, 10 April 2013 at 01:37:35 UTC, deadalnix wrote:
Agree on it being great and innovative. But I fail to see
usefulness with
On Wednesday, 10 April 2013 at 11:29:42 UTC, Dicebot wrote:
Except you can't be sure that your function is strongly pure
with current design. Add ref parameter into the mix by accident
and it will silently change to weak pure which is useless by
its own.
pure + immutable and value parameters
On 04/10/2013 05:43 PM, deadalnix wrote:
On Wednesday, 10 April 2013 at 11:29:42 UTC, Dicebot wrote:
Except you can't be sure that your function is strongly pure with
current design. Add ref parameter into the mix by accident and it will
silently change to weak pure which is useless by its own.
On Wednesday, 10 April 2013 at 15:48:43 UTC, Timon Gehr wrote:
On 04/10/2013 05:43 PM, deadalnix wrote:
On Wednesday, 10 April 2013 at 11:29:42 UTC, Dicebot wrote:
Except you can't be sure that your function is strongly pure
with
current design. Add ref parameter into the mix by accident
and
On Wednesday, 10 April 2013 at 15:52:23 UTC, deadalnix wrote:
...
And that is exactly what makes it useless. I need one keyword to
automatically verify for me that parameters fine, that context is
fine, return value is fine etc. This is the basic crucial concept
and everything else should
On 4/9/2013 1:33 AM, Manu wrote:
How can 'weak pure' reasonably be called any kind of 'pure'? It's not pure at
all. The function returns a completely different result when called twice.
That's the definition of not-pure.
I suggest that no D language newbie would ever reasonably expect that
On 4/9/2013 1:04 AM, Dicebot wrote:
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
}
}
That's not pure. Call it
On 4/9/2013 5:56 AM, Andrei Alexandrescu wrote:
s/body/signature/
s/Crap/Awesome/
I agree that the notions of strong/weak purity are awesome, I believe they are a
D innovation, and if I recall correctly this innovation is thanks to Don
Clugston, one of our most awesome contributors.
On 4/9/2013 6:49 AM, Dicebot wrote:
Not gonna argue latter but former is just wrong.
struct Test
{
int a;
pure int foo1() // strong pure
{
return 42;
}
pure int foo2() // weak pure
{
return a++;
}
}
Signature is the same for both functions.
On 4/9/2013 7:12 AM, Simen Kjærås wrote:
const is not sufficient, as someone else might have a mutable
reference. immutable is needed.
const is sufficient for strongly pure, because another reference is not
available to the function body, and so the function cannot mutate it.
On 4/9/2013 7:50 AM, Simen Kjærås wrote:
It's based purely on function signature
Correct.
(I should point out that there are cases where the compiler infers purity from
the function body:
1. lambdas
2. template functions
3. auto functions
)
On 4/9/2013 3:52 AM, Joseph Rushton Wakeling wrote:
I do agree that it's a great pity there is not a way to declare strong purity
for D functions.
Sure there is. Declare the function as pure, and the function's parameters as
const or immutable.
On 4/9/2013 12:52 AM, Manu wrote:
But that's meaningless though, because there's always the possibility that
something somewhere else may have a non-const reference to that thing.
Can you suggest a case where const could EVER be used in any sort of
optimisation?
Sure:
pure int bar(const
On 4/9/2013 1:00 AM, Manu wrote:
Locals or allocated memory are not thread-local, can be passed wherever they
want, including other threads.
Not unless they are marked as shared.
On 4/9/2013 3:48 AM, deadalnix wrote:
No, D have holes in its type system and so can't ensure anything. It has been
show many many many times, especially by Timon and myself, and I'm kind of fed
up to have to repeat that again and again, especiallt since fix proposal have
recieved no attention
On 4/10/13 2:54 PM, Walter Bright wrote:
On 4/9/2013 3:48 AM, deadalnix wrote:
No, D have holes in its type system and so can't ensure anything. It
has been
show many many many times, especially by Timon and myself, and I'm
kind of fed
up to have to repeat that again and again, especiallt since
On 04/10/2013 08:54 PM, Walter Bright wrote:
On 4/9/2013 3:48 AM, deadalnix wrote:
No, D have holes in its type system and so can't ensure anything. It
has been
show many many many times, especially by Timon and myself, and I'm
kind of fed
up to have to repeat that again and again, especiallt
On 4/10/2013 12:43 PM, Timon Gehr wrote:
Generally it does not, but is it actually not full of holes in this case? Can
you give a short wrap-up of what the original language design is for type
checking delegate context pointers? We can only guess, because it is not
specified and much of what DMD
On 4/10/13 5:25 PM, Walter Bright wrote:
On 4/10/2013 12:43 PM, Timon Gehr wrote:
Generally it does not, but is it actually not full of holes in this
case? Can
you give a short wrap-up of what the original language design is for type
checking delegate context pointers? We can only guess,
On 4/10/2013 2:28 PM, Andrei Alexandrescu wrote:
On 4/10/13 5:25 PM, Walter Bright wrote:
On 4/10/2013 12:43 PM, Timon Gehr wrote:
Generally it does not, but is it actually not full of holes in this
case? Can
you give a short wrap-up of what the original language design is for type
checking
On Wednesday, 10 April 2013 at 17:12:27 UTC, Dicebot wrote:
On Wednesday, 10 April 2013 at 15:52:23 UTC, deadalnix wrote:
...
And that is exactly what makes it useless. I need one keyword
to automatically verify for me that parameters fine, that
context is fine, return value is fine etc.
On Wednesday, 10 April 2013 at 18:33:26 UTC, Walter Bright wrote:
On 4/9/2013 7:12 AM, Simen Kjærås wrote:
const is not sufficient, as someone else might have a mutable
reference. immutable is needed.
const is sufficient for strongly pure, because another
reference is not available to the
On Wednesday, 10 April 2013 at 18:54:15 UTC, Walter Bright wrote:
On 4/9/2013 3:48 AM, deadalnix wrote:
No, D have holes in its type system and so can't ensure
anything. It has been
show many many many times, especially by Timon and myself, and
I'm kind of fed
up to have to repeat that again
On 4/10/2013 5:33 PM, deadalnix wrote:
call with const parameter can be considered strongly pure if the argument is
immutable
The argument doesn't need to be immutable because nobody can change it while the
function is running.
On Wednesday, 10 April 2013 at 18:24:22 UTC, Walter Bright wrote:
On 4/9/2013 1:33 AM, Manu wrote:
How can 'weak pure' reasonably be called any kind of 'pure'?
It's not pure at
all. The function returns a completely different result when
called twice.
That's the definition of not-pure.
I
On 04/11/2013 02:41 AM, Walter Bright wrote:
On 4/10/2013 5:33 PM, deadalnix wrote:
call with const parameter can be considered strongly pure if the
argument is
immutable
The argument doesn't need to be immutable because nobody can change it
while the function is running.
(He has written
On 04/10/2013 11:50 PM, Walter Bright wrote:
...
My point was that competing designs are very probably not necessary. We
just need to pull on the string on what must be.
Yes, IMO it is quite obvious how to do it. (transfer the meaning of the
modifiers from member functions to local
On 4/10/2013 10:44 PM, Timon Gehr wrote:
On 04/10/2013 11:50 PM, Walter Bright wrote:
...
My point was that competing designs are very probably not necessary. We
just need to pull on the string on what must be.
Yes, IMO it is quite obvious how to do it. (transfer the meaning of the
On 2013-04-09 05:30, Walter Bright wrote:
In C++, it is legal to cast away const and mutate it. That is undefined
behavior in D.
Didn't they change how const behaves in C++11, I'm thinking of this:
http://channel9.msdn.com/posts/C-and-Beyond-2012-Herb-Sutter-You-dont-know-blank-and-blank
--
On 9 April 2013 01:07, Jacob Carlborg d...@me.com wrote:
On 2013-04-08 14:52, Iain Buclaw wrote:
On 8 April 2013 13:25, Jacob Carlborg d...@me.com mailto:d...@me.com
wrote:
On 2013-04-08 10:29, Iain Buclaw wrote:
This information could possibly be helpful. Though given that
On 9 April 2013 01:40, Iain Buclaw ibuc...@ubuntu.com wrote:
On 8 April 2013 13:37, Manu turkey...@gmail.com wrote:
Oh my god... . this is the most upsetting thing I've heard all day! :(
No really, I have been S excited for so long about this optimisation
potential in D!
There's
On 9 April 2013 13:30, Walter Bright newshou...@digitalmars.com wrote:
On 4/8/2013 5:39 AM, Manu wrote:
But D makes no further guarantee. I don't see how const in D is any
different
than const in C++ in that sense? That's basically the concept of const,
it's not
a useful concept for
On Tuesday, 9 April 2013 at 07:11:02 UTC, Jacob Carlborg wrote:
On 2013-04-09 05:30, Walter Bright wrote:
In C++, it is legal to cast away const and mutate it. That is
undefined
behavior in D.
Didn't they change how const behaves in C++11, I'm thinking of
this:
On Tuesday, 9 April 2013 at 07:52:20 UTC, Manu wrote:
But that's meaningless though, because there's always the
possibility that
something somewhere else may have a non-const reference to that
thing.
Can you suggest a case where const could EVER be used in any
sort of
optimisation?
I don't
On 9 April 2013 14:39, Walter Bright newshou...@digitalmars.com wrote:
On 4/8/2013 5:37 AM, Manu wrote:
Only builtins are pure in the sense of 'C'. Even functions considered
PUREstrong by the frontend may update an internal state, so the rules
just
don't apply. Except for
On Tuesday, 9 April 2013 at 07:41:55 UTC, Manu wrote:
How does one specify that in their code? Is 'strong pure' a
keyword?
You can't and this is the most stupid thing about pure in D.
Compiler can detect which one it is, but you can't force it to
accept pure only as strong pure.
On 9 April 2013 17:54, Dicebot m.stras...@gmail.com wrote:
On Tuesday, 9 April 2013 at 07:52:20 UTC, Manu wrote:
But that's meaningless though, because there's always the possibility that
something somewhere else may have a non-const reference to that thing.
Can you suggest a case where
On Tuesday, 9 April 2013 at 08:00:38 UTC, Manu wrote:
Errrm, only globals are shared by default.
Locals or allocated memory are not thread-local, can be passed
wherever
they want, including other threads.
No, globals are also thread-local by default. Everything is. And
it was intended that
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
}
}
That's not pure. Call it twice with the same args, you'll
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
}
}
That's not pure. Call it twice with the same args, you'll
On 9 April 2013 18:03, Dicebot m.stras...@gmail.com wrote:
On Tuesday, 9 April 2013 at 08:00:38 UTC, Manu wrote:
Errrm, only globals are shared by default.
Locals or allocated memory are not thread-local, can be passed wherever
they want, including other threads.
No, globals are also
On 9 April 2013 18:04, Dicebot m.stras...@gmail.com wrote:
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
}
}
On Tue, 09 Apr 2013 09:41:43 +0200, Manu turkey...@gmail.com wrote:
How does one specify that in their code? Is 'strong pure' a keyword?
It's not a keyword. It's inferred by the compiler when a function is
marked pure
(or is a template function and is inferred pure), and all parameters are
On Tuesday, 9 April 2013 at 08:31:06 UTC, Manu wrote:
E, no?
Only globals are thread-local. Everything else is either stack
or heap
allocated.
Well, stack is also thread-local, isn't it? ;) Heap objection
accepted.
Yes but that's ultimately useless. If sharing is undefined, and
you
On Tue, 09 Apr 2013 10:33:45 +0200, Manu turkey...@gmail.com wrote:
On 9 April 2013 18:04, Dicebot m.stras...@gmail.com wrote:
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar(
On Tuesday, 9 April 2013 at 08:33:53 UTC, Manu wrote:
How can 'weak pure' reasonably be called any kind of 'pure'?
It's not pure
at all. The function returns a completely different result when
called
twice. That's the definition of not-pure.
I suggest that no D language newbie would ever
On 04/09/2013 09:56 AM, Dicebot wrote:
You can't and this is the most stupid thing about pure in D. Compiler can
detect
which one it is, but you can't force it to accept pure only as strong
pure.
This is surely not so terrible -- it leaves the door open for a new keyword
(strong pure
On 04/08/2013 08:14 PM, Simen Kjaeraas wrote:
Like others have stated, it's so you can do this:
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
}
}
pure int Baz( int n ) { // Strongly pure
Foo foo;
return foo.bar( n );
On 04/09/2013 05:30 AM, Walter Bright wrote:
On 4/8/2013 5:39 AM, Manu wrote:
But D makes no further guarantee. I don't see how const in D is any
different
than const in C++ in that sense? That's basically the concept of
const, it's not
a useful concept for optimisation, only immutable is.
In
On 04/09/13 02:44, deadalnix wrote:
On Monday, 8 April 2013 at 15:07:31 UTC, Jacob Carlborg wrote:
I though that wasn't possible. What's the point of pure if that's possible?
You have to think that this is an hidden parameter. The function touch that
parameter, no global state.
D's pure is
On 04/09/2013 10:33 AM, Manu wrote:
...
How can 'weak pure' reasonably be called any kind of 'pure'? It's not
pure at all. The function returns a completely different result when
called twice. That's the definition of not-pure.
(Actually this is not the definition of impure.)
In D, 'pure'
On 9 April 2013 19:43, Joseph Rushton Wakeling joseph.wakel...@webdrake.net
wrote:
On 04/08/2013 08:14 PM, Simen Kjaeraas wrote:
Like others have stated, it's so you can do this:
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
On 04/09/2013 12:13 PM, Artur Skawina wrote:
...
D's pure is horribly misnamed; nobody that's not already aware of the
D re-definition expects pure to mean what it currently does.
struct S {
int* p;
int f() pure @safe nothrow { return ++*p; }
}
int i = 1;
int
On Tuesday, 9 April 2013 at 10:28:16 UTC, Manu wrote:
There's nothing 'pure' about a function that has side effects.
It's a
totally different concept, and should be named appropriately.
It's not totally different – the possible side effects are still
very localized and controllable by the
On Tuesday, 9 April 2013 at 03:36:28 UTC, Walter Bright wrote:
On 4/8/2013 5:39 AM, Manu wrote:
But D makes no further guarantee. I don't see how const in D
is any different
than const in C++ in that sense? That's basically the concept
of const, it's not
a useful concept for optimisation,
2013/4/9 Timon Gehr timon.g...@gmx.ch
On 04/09/2013 12:13 PM, Artur Skawina wrote:
[snip]
That's not pure by any definition,
I'd counter that it is pure by the D definition.
I completely agree with Timon. It's the definition in D.
The meaning of 'pure' keyword in D *contains* widely
On 04/09/2013 12:28 PM, Manu wrote:
There's nothing 'pure' about a function that has side effects. It's a totally
different concept, and should be named appropriately.
But a natural way to define a pseudo-random number generator is a combination of
a state variable together with a pure function
On 04/09/2013 12:28 PM, Manu wrote:
...
There's nothing 'pure' about a function that has side effects.
If it has the same side effects every time it is called with the same
arguments, then there is something pure about it.
It's a totally different concept,
The concept of mutation can be
deadalnix deadal...@gmail.com wrote in message
news:yhvwbephdechjxvrk...@forum.dlang.org...
No, D have holes in its type system and so can't ensure anything. It has
been show many many many times, especially by Timon and myself, and I'm
kind of fed up to have to repeat that again and again,
On Tuesday, 9 April 2013 at 10:57:20 UTC, Daniel Murphy wrote:
deadalnix deadal...@gmail.com wrote in message
news:yhvwbephdechjxvrk...@forum.dlang.org...
No, D have holes in its type system and so can't ensure
anything. It has been show many many many times, especially by
Timon and myself,
On 04/09/13 12:51, kenji hara wrote:
2013/4/9 Timon Gehr timon.g...@gmx.ch mailto:timon.g...@gmx.ch
On 04/09/2013 12:13 PM, Artur Skawina wrote:
[snip]
That's not pure by any definition,
I'd counter that it is pure by the D definition.
I completely agree with
On 04/09/2013 12:57 PM, Daniel Murphy wrote:
deadalnix deadal...@gmail.com wrote in message
news:yhvwbephdechjxvrk...@forum.dlang.org...
No, D have holes in its type system and so can't ensure anything. It has
been show many many many times, especially by Timon and myself, and I'm
kind of fed
On 9 April 2013 20:50, Timon Gehr timon.g...@gmx.ch wrote:
On 04/09/2013 12:28 PM, Manu wrote:
...
There's nothing 'pure' about a function that has side effects.
If it has the same side effects every time it is called with the same
arguments, then there is something pure about it.
But
On 9 April 2013 20:57, Daniel Murphy yebbl...@nospamgmail.com wrote:
deadalnix deadal...@gmail.com wrote in message
news:yhvwbephdechjxvrk...@forum.dlang.org...
No, D have holes in its type system and so can't ensure anything. It has
been show many many many times, especially by Timon and
On Tuesday, 9 April 2013 at 08:33:53 UTC, Manu wrote:
On 9 April 2013 18:04, Dicebot m.stras...@gmail.com wrote:
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar( int n ) { //
On 2013-04-09 12:24, Timon Gehr wrote:
static - (no suggestion)
static has quite a lot of overloads as well.
--
/Jacob Carlborg
On 04/09/2013 01:27 PM, Manu wrote:
...
The only optimisation possibility is for strong pure functions that are
also nothrow, right? Was that the conditions for pure function refactoring?
No, strongly pure functions will always throw the same classes of
exceptions when called with the same
On 04/09/2013 01:39 PM, Timon Gehr wrote:
On 04/09/2013 01:27 PM, Manu wrote:
...
The only optimisation possibility is for strong pure functions that are
also nothrow, right? Was that the conditions for pure function
refactoring?
No, strongly pure functions will always throw the same
On Tue, 09 Apr 2013 13:10:16 +0200, Artur Skawina art.08...@gmail.com
wrote:
A function that both directly depends on global mutable state (and
modifies it) can hardly be called pure. Can you (anybody) give a
D pure definition that allows for the program that I've posted
and still makes pure
On Tuesday, 9 April 2013 at 10:24:45 UTC, Timon Gehr wrote:
On 04/09/2013 10:33 AM, Manu wrote:
...
How can 'weak pure' reasonably be called any kind of 'pure'?
It's not
pure at all. The function returns a completely different
result when
called twice. That's the definition of not-pure.
On 04/09/2013 01:26 PM, Manu wrote:
On 9 April 2013 20:50, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 04/09/2013 12:28 PM, Manu wrote:
...
There's nothing 'pure' about a function that has side effects.
If it has the same side effects every time
On 04/09/2013 01:47 PM, Simen Kjærås wrote:
On Tue, 09 Apr 2013 13:10:16 +0200, Artur Skawina art.08...@gmail.com
wrote:
A function that both directly depends on global mutable state (and
modifies it) can hardly be called pure. Can you (anybody) give a
D pure definition that allows for the
On Tuesday, 9 April 2013 at 11:26:38 UTC, Manu wrote:
But it doesn't. It could do anything when called a second time,
same
arguments or not.
Can it?
David
On 9 April 2013 21:30, tn n...@email.com wrote:
On Tuesday, 9 April 2013 at 08:33:53 UTC, Manu wrote:
On 9 April 2013 18:04, Dicebot m.stras...@gmail.com wrote:
On Tuesday, 9 April 2013 at 07:57:37 UTC, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo
On 4/9/13 3:56 AM, Manu wrote:
Are you saying the example above is not actually valid code?
struct Foo {
int a = 0;
pure int bar( int n ) { // Weakly pure
a += n;
return a;
}
}
That's not pure. Call it twice with the same args, you'll different
answers.
The
1 - 100 of 173 matches
Mail list logo
