On Mon, 19 May 2014 23:14:03 -0400, Jonathan M Davis via Digitalmars-d
wrote:
On Mon, 19 May 2014 13:11:43 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via
Digitalmars-d wrote:
> On Mon, 19 May 2014 09:42:31 -0400
> Steven Schve
On Mon, 19 May 2014 23:33:30 -0400, Jonathan M Davis via Digitalmars-d
wrote:
On Mon, 19 May 2014 15:20:46 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot wrote:
> On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schveighoffer wrote:
>> On Mo
On Mon, 19 May 2014 18:46:22 -0400, Dicebot wrote:
On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 16:23:34 -0400, Dicebot wrote:
Oh, and are probably eager to show me links to specs which indicate
what part of my snippet breaks the type system? Is
On Mon, 19 May 2014 15:20:46 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Mon, 19 May 2014 15:03:55 -0400, Dicebot 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
> >> wrote:
> >>
> >>> On
On Mon, 19 May 2014 14:33:55 -0400
Steven Schveighoffer via Digitalmars-d
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 that DEPENDS on
> that be
On Mon, 19 May 2014 13:11:43 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via
> Digitalmars-d wrote:
>
> > On Mon, 19 May 2014 09:42:31 -0400
> > Steven Schveighoffer via Digitalmars-d
> > wrote:
> >
> >> On Sun, 18 May 2014 09:58:25
On Monday, 19 May 2014 at 20:51:22 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 16:23:34 -0400, Dicebot
wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot
wrote:
On Monday, 19 May 2014 at 17:35:34 UTC, Steven Schv
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 going
On Mon, 19 May 2014 17:14:44 -0400, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 16:56:58 -0400, Ola Fosheim Grøstad
wrote:
I've given several examples
Links?
BTW, you probably shouldn't expect any response from me, I'm about to go
into travel-prep mode, and I likely will not b
On Mon, 19 May 2014 16:56:58 -0400, Ola Fosheim Grøstad
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
wrote:
On Monday, 19 May 2014 at 18:33:55 UTC, Steven Schveighoffer wrote:
Then you should have n
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
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 lang
On Mon, 19 May 2014 16:23:34 -0400, Dicebot wrote:
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot 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øst
On Monday, 19 May 2014 at 19:20:46 UTC, Steven Schveighoffer
wrote:
On Mon, 19 May 2014 15:03:55 -0400, Dicebot
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
wrote:
On Monday, 19 May 2014 at 17:11:43 UTC,
On Mon, 19 May 2014 15:03:55 -0400, Dicebot 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
wrote:
On Monday, 19 May 2014 at 17:11:43 UTC, Steven Schveighoffer wrote:
It shouldn't matter. Something that ret
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 fu
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
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
On Mon, 19 May 2014 14:49:41 -0400, Ola Fosheim Grøstad
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 sound a
priori, not post mortem..
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. Be
On Mon, 19 May 2014 13:44:59 -0400, Ola Fosheim Grøstad
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, pure or not.
This isn't at all obviou
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 al
On Mon, 19 May 2014 13:31:08 -0400, Ola Fosheim Grøstad
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. Nobody should be
looking at the addr
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 pro
On Mon, 19 May 2014 12:35:26 -0400, Jonathan M Davis via Digitalmars-d
wrote:
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
wrote:
> On Sat, May 17, 2014 at 11:51:44AM -0700, Jonathan M Da
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 ac
On Mon, 19 May 2014 09:42:31 -0400
Steven Schveighoffer via Digitalmars-d
wrote:
> On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
> 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
> >>
On Sun, 18 May 2014 09:58:25 -0400, H. S. Teoh via Digitalmars-d
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
wrote:
> On 5/15/14, 6:28 AM, Dicebot wrote:
> > This is not
On Mon, 19 May 2014 07:37:55 +
via Digitalmars-d 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 object but also need t
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 whe
On Mon, 19 May 2014 06:05:26 +
via Digitalmars-d 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 variables.
>
> It ca
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 not
On Mon, 19 May 2014 05:16:13 +
via Digitalmars-d 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 useless as an
> > op
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 often
On Sun, 18 May 2014 06:58:25 -0700
"H. S. Teoh via Digitalmars-d" 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
> > wrote:
> >
> > > On 5/15/14, 6:28 AM, Dicebot wrot
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
> wrote:
>
> > On 5/15/14, 6:28 AM, Dicebot wrote:
> > > This is not true. Because of such code you can't ever
> > > automatically memo
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 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 Thu, 15 May 2014 11:03:13 -0700
Walter Bright via Digitalmars-d 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!
Definitely, but we also ne
On Thu, 15 May 2014 08:43:11 -0700
Andrei Alexandrescu via Digitalmars-d
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.
>
> I think code that
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 Thu, 15 May 2014 18:30:55 -0400, David Nadlinger
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.
The rules that we
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 b
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
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 idx
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:
http://nimrod-lang.org/
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 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
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 anythin
On Thursday, 15 May 2014 at 13:42:58 UTC, Steven Schveighoffer
wrote:
In any case, the alternative is to have D pure functions avoid
using pointers. It's as drastic as that.
You need:
1. references with value semantics.
2. "non pure exceptions" that cannot be caught within a pure
chain, but
On 5/15/2014 5:20 PM, bearophile wrote:
Walter Bright:
I think those sorts of things are PhD research topics. It's a bit beyond the
scope of what we're trying to do with D.
Perhaps yes.
Yet, the Whiley language is not PhD-level, and it's inspiring :)
Things like value range propagation show
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 anything whose specification would need to mention
'allocation'.
That's th
Walter Bright:
I think those sorts of things are PhD research topics. It's a
bit beyond the scope of what we're trying to do with D.
Perhaps yes.
Yet, the Whiley language is not PhD-level, and it's inspiring :)
Things like value range propagation show that even rather small
amounts of static
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. It's a bit beyond the
scope of what we're trying to do with D.
On 5/15/2014 4:32 PM, Andrei Alexandrescu wrote:
On 5/15/14, 11:03 AM, Walter Bright 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!
Yah, that's unexp
On 5/15/14, 11:03 AM, Walter Bright 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!
Yah, that's unexpected in a nice way. -- Andrei
H. S. Teoh:
it may be possible in some cases that the compiler can
mechanically
verify a user-supplied proof, and thus provide the same
guarantees
as it would for directly-provable code.
Yes, this is common enough. As an example the Whiley
(http://whiley.org/ ) is not able to find the proof
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 is still memoizable if it is changed
> >>>internally
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.
This means format("%x", ptr) isn't allowed to be pure?
The short answer would b
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 is still memoizable if it is changed
internally to
memoize values in global memory, for example.
I doubt a compiler could prove it was pure.
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 anything whose specification would need to mention 'allocation'.
because without it it would be difficult to get m
On 05/15/2014 03:06 PM, "Ola Fosheim Grøstad"
" wrote:
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 "imperativ
On 05/15/2014 11:33 PM, Walter Bright wrote:
On 5/15/2014 9:07 AM, Timon Gehr wrote:
Why? A memoizable function is still memoizable if it is changed
internally to
memoize values in global memory, for example.
I doubt a compiler could prove it was pure.
Yes, that was actually my point. Memoi
On 5/15/2014 9:07 AM, Timon Gehr wrote:
Why? A memoizable function is still memoizable if it is changed internally to
memoize values in global memory, for example.
I doubt a compiler could prove it was pure.
On 05/15/2014 07:41 PM, Steven Schveighoffer wrote:
Not really, allocation is just an implementation detail. The
computational language is meaningful independent of how you might
achieve evaluation of expressions. I can in principle evaluate an
expression of such a language on paper without mana
On 15.5.2014. 17:24, 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 purit
On 5/15/14, 9:03 AM, Timon Gehr wrote:
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
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 Thu, 15 May 2014 11:42:00 -0400, Timon Gehr wrote:
On 05/15/2014 02:57 PM, Steven Schveighoffer wrote:
On Thu, 15 May 2014 02:50:05 -0400, 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 randomB
On Thu, 15 May 2014 12:01:35 -0400, Manu via Digitalmars-d
wrote:
On 15 May 2014 23:47, Steven Schveighoffer via Digitalmars-d
Because if it were strong-pure, the compiler could optimize two
sequential
calls as returning the same exact thing. Imagine if a constructor to a
mutable object
On 05/15/2014 11:45 AM, Don wrote:
"No global state" is a deep, transitive property of a function.
"Memoizable" is a superficial supersetextra
Why? A memoizable function is still memoizable if it is changed
internally to memoize values in global memory, for example.
property which the comp
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
On 15 May 2014 23:47, Steven Schveighoffer via Digitalmars-d
wrote:
> On Thu, 15 May 2014 09:40:03 -0400, Manu via Digitalmars-d
> wrote:
>
>> On 15 May 2014 22:30, Steven Schveighoffer via Digitalmars-d
>>
>> wrote:
>>>
>>> On Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
>>> 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.
I think code that doesn't return pointers should be memoizable. Playing
tricks with pointer comparisons would be
On 05/15/2014 02:57 PM, Steven Schveighoffer wrote:
On Thu, 15 May 2014 02:50:05 -0400, 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) > (
On 5/15/14, 6:02 AM, Steven Schveighoffer wrote:
On Wed, 14 May 2014 20:50:08 -0400, Walter Bright
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
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 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 don
On Thu, 15 May 2014 10:42:00 -0400, David Nadlinger
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
wrote:
That's the wrong attitude to take when it comes to the compiler and
runtime.
There are always
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
wrote:
That's the wrong attitude to take when it comes to the
compiler and runtime.
There are always ways around the guarantees. This one isn't as
detectable, since t
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 prec
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 Thu, 15 May 2014 09:28:57 -0400, Dicebot 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
wrote:
On Thursday, 15 May 2014 at 06:29:06 UTC, bearophile wrote:
A little example of D purity (this compiles)
On Thu, 15 May 2014 09:40:03 -0400, Manu via Digitalmars-d
wrote:
On 15 May 2014 22:30, Steven Schveighoffer via Digitalmars-d
wrote:
On Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
wrote:
On 15 May 2014 10:50, Walter Bright via Digitalmars-d
wrote:
On 5/14/2014 5:03 PM, Me
On Thu, 15 May 2014 09:24:54 -0400, Ola Fosheim Grøstad
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 don't think it's an
issue.
That's
On 15 May 2014 22:30, Steven Schveighoffer via Digitalmars-d
wrote:
> On Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
> wrote:
>
>> On 15 May 2014 10:50, Walter Bright via Digitalmars-d
>> wrote:
>>>
>>> On 5/14/2014 5:03 PM, Meta wrote:
Allocating memory through new an
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
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 (n
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: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 "pur
On Wed, 14 May 2014 20:50:08 -0400, Walter Bright
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 arguments, it returns null
s
On Thu, 15 May 2014 02:50:05 -0400, 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 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.
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 Thu, 15 May 2014 07:52:20 -0400, Manu via Digitalmars-d
wrote:
On 15 May 2014 10:50, Walter Bright via Digitalmars-d
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 Wed, 14 May 2014 21:11:30 -0400, Brian Schott
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 you could design a
wra
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 c
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 whet
On 15 May 2014 10:50, Walter Bright via Digitalmars-d
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 arguments, it re
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 solut
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 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 sam
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 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 "
1 - 100 of 144 matches
Mail list logo
