On Mon, 19 May 2014 18:46:22 -0400, Dicebot pub...@dicebot.lv wrote:
On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 16:23:34 -0400, Dicebot pub...@dicebot.lv wrote:
Oh, and are probably eager to show me links to specs which indicate
what part of my
On Mon, 19 May 2014 23:33:30 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Mon, 19 May 2014 15:20:46 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot pub...@dicebot.lv wrote:
On
On Mon, 19 May 2014 23:14:03 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Mon, 19 May 2014 13:11:43 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via
Digitalmars-d
On Monday, 19 May 2014 at 05:39:49 UTC, Jonathan M Davis via
Digitalmars-d wrote:
1. it makes it easier to reason about code, because it
guarantees that the
function didn't access any global or static variables.
It can, through the parameters, like an array of pointers. And
avoiding IO is
On Mon, 19 May 2014 06:05:26 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 19 May 2014 at 05:39:49 UTC, Jonathan M Davis via
Digitalmars-d wrote:
1. it makes it easier to reason about code, because it
guarantees that the
function didn't access any global or static
On Monday, 19 May 2014 at 06:30:46 UTC, Jonathan M Davis via
Digitalmars-d wrote:
makes dealing with immutable far, far more pleasant. It's
particularly useful
when you need to allocate an immutable object but also need to
mutate it as
part of initializing it. If you do it in a pure function
On Mon, 19 May 2014 07:37:55 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 19 May 2014 at 06:30:46 UTC, Jonathan M Davis via
Digitalmars-d wrote:
makes dealing with immutable far, far more pleasant. It's
particularly useful
when you need to allocate an immutable
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via
Digitalmars-d wrote:
On Thu, 15 May 2014 08:43:11 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via
Digitalmars-d
On Monday, 19 May 2014 at 08:51:11 UTC, Jonathan M Davis via
Digitalmars-d wrote:
Perhaps you're hung up on the fact
that the term pure is being used, and you're thinking about
functional
purity?
No, I just don't think it makes much sense the way pure is
defined in D. Since it doesn't
On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer
wrote:
It shouldn't matter. Something that returns immutable
references, can return that same thing again if asked the same
way. Nobody should be looking at the address in any meaningful
way.
I think this is at odds with generic
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer wrote:
It shouldn't matter. Something that returns immutable references, can
return that same thing again if asked the same way.
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer
wrote:
Returning the same immutable object, when called with the same
immutable parameters, should never cause a break in code, pure
or not.
This isn't at all obvious to me. Also I think the coin flip
trick represent a class of
On Mon, 19 May 2014 13:44:59 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
Returning the same immutable object, when called with the same
immutable parameters, should never cause a break in code,
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer
wrote:
Anything that uses the order of unrelated addresses is
incorrect outside of the heap code itself.
Nah, not on modern archiectures without GC compaction.
Then you should have no problem producing an example, right?
I did.
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer wrote:
Then you should have no problem producing an example, right?
I did. Besides, I think language constructs should be proven
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer
wrote:
It shouldn't matter. Something that returns immutable
On 05/19/2014 09:03 PM, Dicebot wrote:
immutable(Object*) alloc() pure
{
return new Object();
}
bool oops() pure
{
auto a = alloc();
auto b = alloc();
return a is b;
}
This is a snippet that will always return `true` if memoization is at
work and `false` if strongly pure
On Mon, 19 May 2014 15:03:55 -0400, Dicebot pub...@dicebot.lv wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot pub...@dicebot.lv
wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
On Mon, 19 May 2014 16:23:34 -0400, Dicebot pub...@dicebot.lv wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot pub...@dicebot.lv wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
On Mon, 19 May
On Monday, 19 May 2014 at 18:55:57 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer
wrote:
Then you should have no problem producing an example,
On Mon, 19 May 2014 16:56:58 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014 at 18:55:57 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Monday, 19 May 2014
On Mon, 19 May 2014 17:14:44 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Mon, 19 May 2014 16:56:58 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
I've given several examples
Links?
BTW, you probably shouldn't expect any response from me, I'm about
On Monday, 19 May 2014 at 21:16:19 UTC, Steven Schveighoffer
wrote:
BTW, you probably shouldn't expect any response from me, I'm
about to go into travel-prep mode, and I likely will not be
checking forums. If you are at dconf, perhaps we can continue
the discussion in person :)
I am not
On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 16:23:34 -0400, Dicebot pub...@dicebot.lv
wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot
pub...@dicebot.lv wrote:
On Monday, 19
On Mon, 19 May 2014 13:11:43 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via
Digitalmars-d digitalmars-d@puremagic.com wrote:
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d
On Mon, 19 May 2014 14:33:55 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
The whole POINT of pure functions is that it will return the same
thing. The fact that it lives in a different piece of memory or not
is not important. We have to accept that. Any code
On Mon, 19 May 2014 15:20:46 -0400
Steven Schveighoffer via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot pub...@dicebot.lv wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 13:31:08 -0400, Ola
On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
On Thu, 15 May 2014 08:43:11 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 5/15/14, 6:28 AM, Dicebot wrote:
This is not true. Because of such code you can't ever
On Sun, 18 May 2014 06:58:25 -0700
H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Davis via
Digitalmars-d wrote:
On Thu, 15 May 2014 08:43:11 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
On Monday, 19 May 2014 at 01:19:29 UTC, Jonathan M Davis via
Digitalmars-d wrote:
It's already so rare that memoization of a function call can
occur, that I'm
pretty much convinced that memoization is useless as an
optimization - at
least as long as the compiler is doing it. After all, how
On Mon, 19 May 2014 05:16:13 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Monday, 19 May 2014 at 01:19:29 UTC, Jonathan M Davis via
Digitalmars-d wrote:
It's already so rare that memoization of a function call can
occur, that I'm
pretty much convinced that memoization is
On Thu, 15 May 2014 08:43:11 -0700
Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com
wrote:
On 5/15/14, 6:28 AM, Dicebot wrote:
This is not true. Because of such code you can't ever automatically
memoize strongly pure function results by compiler. A very practical
concern.
On Thu, 15 May 2014 11:03:13 -0700
Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 5/15/2014 2:45 AM, Don wrote:
An interesting side-effect of the recent addition of @nogc to the
language, is that we get this ability back.
I hadn't thought of that. Pretty cool!
On 05/16/2014 07:41 PM, Andrei Alexandrescu wrote:
On 5/16/14, 4:53 AM, Timon Gehr wrote:
...
Yes, either that or one could even just implement it in the existing
language by introducing types for evidence, and basic termination
checking.
eg. http://dpaste.dzfl.pl/33018edab028
On 5/16/14,
On 05/17/2014 09:29 PM, Timon Gehr wrote:
Typo: int_leibiz_equality :o). -- Andrei
If that is everything, then I am in good shape! :o)
It could be argued though, that this axiom was not too aptly named in
the first place, because it describes the indiscernibility of identicals
instead
On Friday, 16 May 2014 at 00:27:34 UTC, Andrei Alexandrescu wrote:
On 5/15/14, 2:52 PM, Timon Gehr wrote:
On 05/15/2014 08:03 PM, Andrei Alexandrescu wrote:
Purity of allocation is frequently assumed by functional
languages
Examples?
cons 1 2 is equal to cons 1 2
...
I don't see
On Thursday, 15 May 2014 at 21:48:16 UTC, Timon Gehr wrote:
The term pure function is only needed in a non-functional
language.
Applicative/functional languages only have mathematical
functions, no
need for the term pure there.
In discussions about e.g. Haskell, it is often used to denote
Yes, the VRP has been a nice win for D. No other language does
it.
I don't know why you keep saying things like that, you don't know
all the languages out there. Nimrod does it too fwiw...
On 5/16/2014 1:54 AM, Araq wrote:
Yes, the VRP has been a nice win for D. No other language does it.
I don't know why you keep saying things like that, you don't know all the
languages out there. Nimrod does it too fwiw...
I having trouble finding it in the spec:
Walter Bright:
Yes, the VRP has been a nice win for D.
There are ways to improve it in very useful ways, that increase
static safety and cut down the number of useless casts required.
Some currently refused examples:
---
int[100] array;
void main() {
foreach (immutable
On 05/16/2014 01:00 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 15, 2014 at 03:22:25PM -0700, Walter Bright via Digitalmars-d wrote:
On 5/15/2014 2:41 PM, Timon Gehr wrote:
On 05/15/2014 11:33 PM, Walter Bright wrote:
On 5/15/2014 9:07 AM, Timon Gehr wrote:
Why? A memoizable function
On 05/16/2014 01:56 AM, Walter Bright wrote:
On 5/15/2014 4:00 PM, H. S. Teoh via Digitalmars-d wrote:
What if the language allowed the user to supply a proof of purity, which
can be mechanically checked?
I think those sorts of things are PhD research topics.
Well, feasibility has long ago
On Thu, 15 May 2014 18:30:55 -0400, David Nadlinger c...@klickverbot.at
wrote:
On Thursday, 15 May 2014 at 15:09:32 UTC, Steven Schveighoffer wrote:
But in this case, you have ignored the rules, […]
Which rules exactly? My point is mainly that this area of the language
is underspecified.
On 5/16/14, 4:53 AM, Timon Gehr wrote:
On 05/16/2014 01:00 AM, H. S. Teoh via Digitalmars-d wrote:
On Thu, May 15, 2014 at 03:22:25PM -0700, Walter Bright via
Digitalmars-d wrote:
On 5/15/2014 2:41 PM, Timon Gehr wrote:
On 05/15/2014 11:33 PM, Walter Bright wrote:
On 5/15/2014 9:07 AM, Timon
On Thursday, 15 May 2014 at 05:51:16 UTC, Ola Fosheim Grøstad
wrote:
However mmap to a fixed address is pure if it throws an
exception on failure because the exception bypass the call site
of the pure function (pure functions should not catch side
effect exceptions).
This of course presumes
Ola Fosheim Grøstad:
Pure in D seems pointless to me.
If you start using pure in D you see it's like const: it allows
you to remove certain kinds of your mistakes from the code, and
it makes it more easy to reason about the code.
You can use mutability inside a strongly pure function.
Ola Fosheim Grøstad:
If the result of a series of pure function calls can be used to
flip a coin within a transaction, then those functions cannot
be considered pure in any meaningful sense.
A little example of D purity (this compiles):
bool randomBit() pure nothrow @safe {
return (new
On Thursday, 15 May 2014 at 06:24:30 UTC, bearophile wrote:
If you start using pure in D you see it's like const: it allows
you to remove certain kinds of your mistakes from the code, and
it makes it more easy to reason about the code.
As lint like functionality, yes.
You can use mutability
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles):
bool randomBit() pure nothrow @safe {
return (new int[1].ptr) (new int[1].ptr);
}
Yes, and then you may as well allow a random generator with
private globals. Because memoing is
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yep, purity implies memoing.
No, it doesn't. _All_ that it means when a function is pure is that it cannot
access global or static variables unless they can't be changed after being
initialized (e.g. they're
On Thursday, 15 May 2014 at 06:59:08 UTC, Jonathan M Davis via
Digitalmars-d wrote:
And it _definitely_ has nothing to do with functional purity.
Which makes it pointless and misleading.
Now, combined with other information, you _can_ get functional
purity out it -
e.g. if all the parameters
And mutating through parameters does not affect functional purity
in the theoretical sense if the function holds the only reference
to it. It is comparable to taking one value and returning a new
version of it.
Rigor is important in language design. If you cannot say ALWAYS,
then the
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yep, purity implies memoing.
No, it doesn't. _All_ that it means when a function is pure is that it cannot
access global or static
On Thu, 15 May 2014 07:22:02 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 15 May 2014 at 06:59:08 UTC, Jonathan M Davis via
Digitalmars-d wrote:
And it _definitely_ has nothing to do with functional purity.
Which makes it pointless and misleading.
Now, combined
On Thu, 15 May 2014 10:14:48 +0200
luka8088 via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yep, purity implies memoing.
No, it
On Thursday, 15 May 2014 at 08:14:50 UTC, luka8088 wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yep, purity implies memoing.
No, it doesn't. _All_ that it means when a function is
On 15.5.2014. 11:35, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 10:14:48 +0200
luka8088 via Digitalmars-d digitalmars-d@puremagic.com wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d
On Thursday, 15 May 2014 at 09:23:00 UTC, Jonathan M Davis via
Digitalmars-d wrote:
functions that weren't pure. It allowed for mutation within the
function, and
it allowed for allocation via new, but from the outside, the
function _was_
functionally pure.
If it didn't return the memory
On 15.5.2014. 11:45, Don wrote:
On Thursday, 15 May 2014 at 08:14:50 UTC, luka8088 wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yep, purity implies memoing.
No, it doesn't. _All_
On Thursday, 15 May 2014 at 10:31:47 UTC, luka8088 wrote:
On 15.5.2014. 11:45, Don wrote:
On Thursday, 15 May 2014 at 08:14:50 UTC, luka8088 wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via Digitalmars-d digitalmars-d@puremagic.com
On Thursday, 15 May 2014 at 09:45:52 UTC, Don wrote:
But it turns out that @memoizable isn't actually an interesting
property, whereas '@noglobal' is.
No global state is a deep, transitive property of a function.
Memoizable is a superficial supersetextra property which the
compiler can
On Thu, 15 May 2014 10:10:57 +
via Digitalmars-d digitalmars-d@puremagic.com wrote:
On Thursday, 15 May 2014 at 09:23:00 UTC, Jonathan M Davis via
Digitalmars-d wrote:
functions that weren't pure. It allowed for mutation within the
function, and
it allowed for allocation via new, but
On Thursday, 15 May 2014 at 10:46:21 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 15 May 2014 at 09:45:52 UTC, Don wrote:
But it turns out that @memoizable isn't actually an
interesting property, whereas '@noglobal' is.
No global state is a deep, transitive property of a
function. Memoizable
Don:
I'd personally like to have an annotation '@global', and put
'pure:' at the top of every module.
I suggested a little more powerful @outer:
https://d.puremagic.com/issues/show_bug.cgi?id=5007
Bye,
bearophile
On Thu, 15 May 2014 10:48:07 +
Don via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yes. 'strong pure' means pure in the way that the functional
language crowd means 'pure'.
'weak pure' just means doesn't use globals.
But note that strong purity isn't an official concept, it was
On 15.5.2014. 12:48, Don wrote:
On Thursday, 15 May 2014 at 10:31:47 UTC, luka8088 wrote:
On 15.5.2014. 11:45, Don wrote:
On Thursday, 15 May 2014 at 08:14:50 UTC, luka8088 wrote:
On 15.5.2014. 8:58, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 05:51:14 +
via
On 15.5.2014. 13:04, Jonathan M Davis via Digitalmars-d wrote:
On Thu, 15 May 2014 10:48:07 +
Don via Digitalmars-d digitalmars-d@puremagic.com wrote:
Yes. 'strong pure' means pure in the way that the functional
language crowd means 'pure'.
'weak pure' just means doesn't use globals.
On Thursday, 15 May 2014 at 05:51:16 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 15 May 2014 at 02:49:28 UTC, Adam Sakareassen via
Digitalmars-d wrote:
The more D allows 'pure' functions to diverge from functional
purity the less relevant the flag is for compiler
optimisations.
...
By the
Marc Schütz:
And the optimizations can still be done, because strongly pure
functions can be recognized by their signatures.
What optimizations do you think GDC compiler is doing (or will
do) on pure functions?
Bye,
bearophile
On Thursday, 15 May 2014 at 11:03:35 UTC, Don wrote:
And you can still access globals, you just need a guarantee
that globals don't change until you are done.
Sure, but how can the compiler statically check that? It's a
tough problem.
(That's not a rhetorical question, BTW. If you have a
On 15 May 2014 10:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/14/2014 5:03 PM, Meta wrote:
Allocating memory through new and malloc should always be pure, I think,
because
failure either returns null in malloc's case,
malloc cannot be pure if, with the same
On Thursday, 15 May 2014 at 11:35:46 UTC, bearophile wrote:
Marc Schütz:
And the optimizations can still be done, because strongly pure
functions can be recognized by their signatures.
What optimizations do you think GDC compiler is doing (or will
do) on pure functions?
I don't know
On Thursday, 15 May 2014 at 11:31:34 UTC, Marc Schütz wrote:
There's an important difference between malloc and new: malloc
returns a pointer, but new returns a typed object. This is
crucial IMO, because the returned objects are equal to each
other.
I most code, but not all, so how does the
On Wed, 14 May 2014 21:11:30 -0400, Brian Schott briancsch...@gmail.com
wrote:
On Thursday, 15 May 2014 at 00:48:52 UTC, Walter Bright wrote:
On 5/14/2014 5:44 PM, Brian Schott wrote:
Can we say that Mallocator failures are not recoverable?
malloc itself does not have that property. But
On Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 15 May 2014 10:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/14/2014 5:03 PM, Meta wrote:
Allocating memory through new and malloc should always be pure, I
Ola, you do not understand 'pure.'
To consider the design of pure, you must first consider that you
cannot add functional purity to an imperative language. It cannot
be done. What you can do instead is what D offers with a 'weak
purity' guarantee. That global state is not modified indirectly,
On Thursday, 15 May 2014 at 11:01:38 UTC, Jonathan M Davis via
Digitalmars-d wrote:
functions with mutable parameters. It doesn't. And it would
actually be very
difficult for it to do so without doing full program
optimization, which
really doesn't work with the C linking model that D uses.
On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles):
bool randomBit() pure nothrow @safe {
return (new int[1].ptr) (new int[1].ptr);
On Wed, 14 May 2014 20:50:08 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/14/2014 5:03 PM, Meta wrote:
Allocating memory through new and malloc should always be pure, I
think, because
failure either returns null in malloc's case,
malloc cannot be pure if, with the same
On Thursday, 15 May 2014 at 12:37:22 UTC, w0rp wrote:
To consider the design of pure, you must first consider that
you cannot add functional purity to an imperative language.
Of course you can. Functional languages execute in an imperative
context. That's why you need monads.
The term pure
On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer
wrote:
To be honest, code that would exploit such an anomaly is only
ever used in proof exercises, and never in real code. I don't
think it's an issue.
That's the wrong attitude to take when it comes to the compiler
and runtime.
On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer
wrote:
On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles):
bool
On 15 May 2014 22:30, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 15 May 2014 10:50, Walter Bright via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 5/14/2014
On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer wrote:
To be honest, code that would exploit such an anomaly is only ever used
in proof exercises, and never in real code. I
On Thu, 15 May 2014 09:40:03 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 15 May 2014 22:30, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 15
On Thu, 15 May 2014 09:28:57 -0400, Dicebot pub...@dicebot.lv wrote:
On Thursday, 15 May 2014 at 12:57:43 UTC, Steven Schveighoffer wrote:
On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile
On Thursday, 15 May 2014 at 06:50:06 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles):
bool randomBit() pure nothrow @safe {
return (new int[1].ptr) (new int[1].ptr);
}
Yes, and then you may as well
On Thursday, 15 May 2014 at 13:40:16 UTC, Manu via Digitalmars-d
wrote:
Why should returning a mutable pointer imply weak purity?
The argument here is that a valid mutable pointer returned from a
pure function could always point to a new allocation, as new is
allowed in pure code.
More
On Thursday, 15 May 2014 at 13:42:58 UTC, Steven Schveighoffer
wrote:
On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
That's the wrong attitude to take when it comes to the
compiler and runtime.
There are always ways around the guarantees.
On Thu, 15 May 2014 10:42:00 -0400, David Nadlinger c...@klickverbot.at
wrote:
On Thursday, 15 May 2014 at 13:42:58 UTC, Steven Schveighoffer wrote:
On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
That's the wrong attitude to take when it
On 5/15/14, 3:31 AM, luka8088 wrote:
Yeah, I read all about weak/string purity and I do understand the
background. I was talking about strong purity, maybe I should pointed
that out.
So, to correct myself: As I understood strong purity implies
memoization. Am I correct?
Yes, as long as you
On 5/15/14, 6:02 AM, Steven Schveighoffer wrote:
On Wed, 14 May 2014 20:50:08 -0400, Walter Bright
newshou...@digitalmars.com wrote:
On 5/14/2014 5:03 PM, Meta wrote:
Allocating memory through new and malloc should always be pure, I
think, because
failure either returns null in malloc's case,
On 05/15/2014 02:57 PM, Steven Schveighoffer wrote:
On Thu, 15 May 2014 02:50:05 -0400, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles):
bool randomBit() pure nothrow
On 5/15/14, 6:28 AM, Dicebot wrote:
This is not true. Because of such code you can't ever automatically
memoize strongly pure function results by compiler. A very practical
concern.
I think code that doesn't return pointers should be memoizable. Playing
tricks with pointer comparisons would
David Nadlinger:
I'd suspect that it is enough to disallow using the content of
pointers explicitly, i.e. as a sequence of bytes instead of
just a handle to an object.
Yes, if you allow only a referentially pure view of pointers,
then you have a strong purity.
Bye,
bearophile
On 15 May 2014 23:47, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On Thu, 15 May 2014 09:40:03 -0400, Manu via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 15 May 2014 22:30, Steven Schveighoffer via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On
On 05/15/2014 05:24 PM, Andrei Alexandrescu wrote:
On 5/15/14, 3:31 AM, luka8088 wrote:
Yeah, I read all about weak/string purity and I do understand the
background. I was talking about strong purity, maybe I should pointed
that out.
So, to correct myself: As I understood strong purity implies
1 - 100 of 143 matches
Mail list logo
