Re: Deterministic Proposal

On Thu, Jun 22, 2017 at 9:14 AM, Andreas Rossberg wrote: > On 22 June 2017 at 01:24, Guy Ellis wrote: > >> My thoughts are along the lines that the developer would decide what a >> deterministic function was and decorate/tag it as such. That's why I

Re: Deterministic Proposal

On 22 June 2017 at 01:24, Guy Ellis wrote: > My thoughts are along the lines that the developer would decide what a > deterministic function was and decorate/tag it as such. That's why I used > the word deterministic and not pure. Basically the developer is signaling > the

Re: Deterministic Proposal

My thoughts are along the lines that the developer would decide what a deterministic function was and decorate/tag it as such. That's why I used the word deterministic and not pure. Basically the developer is signaling the compiler that given an identical parameter signature the result received

Re: Deterministic Proposal

On 21 June 2017 at 18:40, Bradley Meck wrote: > You probably mean "pure", not "deterministic", which has nothing to do >> with this. However, JavaScript is far, far too impure for any such >> annotation to ever make sense or enable any sort of memoization. Consider >> let

Re: Deterministic Proposal

> > You probably mean "pure", not "deterministic", which has nothing to do > with this. However, JavaScript is far, far too impure for any such > annotation to ever make sense or enable any sort of memoization. Consider > let i = 0 > let o = {valueOf() {return i++}} > sum(o, 0) > sum(o, 0) If

Re: Deterministic Proposal

On 21 June 2017 at 00:58, Guy Ellis wrote: > I have an idea rattling around that allowing the developer to mark a > function as deterministic would allow the compiler to determine if a > speed/memory memoization trade-off will improve performance. > > Possible syntax: > >

Re: Deterministic Proposal

To be honest it's probably solvable using decorators with memoization. If we ever have a decorators (any updates on proposal BTW?) language can have decorators with implementation-specific behaviour (eg. "functions decorated with @pure builtin decorator can be assumed by engine to not produce

Re: Deterministic Proposal

I'd like to note that even Haskell compilers (which can check for this trivially) never memoize implicitly. They only memoize infinite data structures. As for this proposal, I see exactly zero benefit whatsoever. Engines already cover the relevant optimization opportunity without this (through

Re: Deterministic Proposal

> deterministic function sum(a, b) { return a + b; } > Ironically, having the engine decide when to memoize would make the "deterministic" functions non-deterministic: deterministic function foo(a, b) { return { a, b }; } foo(1, 2) === foo(1, 2) // may or may not be true

Re: Deterministic Proposal

Hi, Think of it like this: It might be enough for your application only to memoize the last `n` results. If you don't, depending on your function, you might be blowing up memory rather quickly. But I don't know how much memory my data uses or how much memory is available. So I don't

Re: Deterministic Proposal

What was drawing me to this idea is that the compiler is already doing performance optimization and a typical performance optimization is memoization. If the compiler were aware that it could memoize the results of a function it could determine this on-the-fly in a way that a library would not be

Re: Deterministic Proposal

@kdex I initially thought of decorators but did not know that there were plans for a standard library that compilers would be "aware of" and would be able to draw this from. Thanks! On Tue, Jun 20, 2017 at 4:03 PM kdex wrote: > Can already be solved using decorators. Thus, no need

Re: Deterministic Proposal

Also, "compiler memoization" may not necessarily be as useful as one might think. It's a good thing to keep memoization abstract/parameterized, so if anything, it should be defined via a (standard) library as a function, not via syntax. Think of it like this: It might be enough for your

Re: Deterministic Proposal

Can already be solved using decorators. Thus, no need for new syntax. If we get a standard library to import some common decorators from, one could easily write: ```js import { memoize } from "std::decorators"; @memoize function sum(a, b) { return a + b; } ``` On Wednesday, June 21,

Deterministic Proposal

I have an idea rattling around that allowing the developer to mark a function as deterministic would allow the compiler to determine if a speed/memory memoization trade-off will improve performance. Possible syntax: deterministic function sum(a, b) { return a + b; } Use case: I can only think