Deterministic Proposal

Lars Hansen lhansen at
Thu Jun 22 11:05:00 UTC 2017

On Thu, Jun 22, 2017 at 9:14 AM, Andreas Rossberg <rossberg at>

> On 22 June 2017 at 01:24, Guy Ellis <wildfiction at> 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 compiler that given an identical parameter signature the result
>> received back from the first call can be used for all subsequent results.
>> The developer implementing compiler optimization would then have a flag
>> available against any method that would signal if it is deterministic or
>> not and would decide to use that information or not.
> Except in a very small set of uninteresting cases, such an optimisation is
> not allowed, because it changes the semantics of the function. A "tag" as a
> compiler hint would not change that. The semantics of every language
> construct has to be well-defined, and must not depend on whether or not a
> compiler chooses to apply certain optimisations.

​Well, the annotation could be a hint that the optimization is allowed, and
if the implementation could check cheaply that the function is indeed pure
it might still be a win.  Depending on details, of course.  Not that I'm
advocating it :)

​I *think* that a purity annotation was at least proposed for early
versions of the Parallel JS work (Intel's "RiverTrail", later
Intel/Mozilla's "PJS") but I can't find any details anywhere.   If there
were such annotations they were already gone by 2012 [1].  All PJS work I
know about based itself on assuming a kind of observational purity of the
kernel functions that were being run in parallel -- side effects were OK as
long as you were only touching memory that was private to the invocation,
in general this required a combination of compile-time and run-time checks
-- with a fallback to sequential execution.  This turned out to be hard to
spec and to implement [2].  A purity annotation would probably not move the
needle on the difficulty; in effect, all kernel functions for PJS were
implicitly annotated as pure (or really, observationally pure, which is
more powerful).




>> The question is: Would that extra information provide the Compiler
>> Optimizing Developer with information that they could use to improve
>> performance or anything else? If you are/were such a
>> Compiler-Optimizing-Developer how would you use this information?
>> On Wed, Jun 21, 2017 at 9:59 AM Andreas Rossberg <rossberg at>
>> wrote:
>>> On 21 June 2017 at 18:40, Bradley Meck <bradley.meck at> 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 i = 0
>>>>> let o = {valueOf() {return i++}}
>>>>> sum(o, 0)
>>>>> sum(o, 0)
>>>> If type coercion was disabled within "pure" functions I am not sure
>>>> this would be a problem.
>>> A new language mode with modified semantics is a whole new dimension
>>> that is far from simple to add to JS. And even then the pure subset of JS
>>> would remain tiny.
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list