Store mutable indirections in immutable data with this one weird trick! (page 4)

November 14, 2021

Re: Store mutable indirections in immutable data with this one weird trick!

Posted by Ola Fosheim Grøstad
in reply to Dukc

Permalink

Ola Fosheim Grøstad

Posted in reply to Dukc

Permalink

On Sunday, 14 November 2021 at 10:32:14 UTC, Dukc wrote:

In @safe code with only the language constructs, that is. You could still write sound @trusted pure library functions that can do those in efficient way.

Yes, but this is where things are starting to get hazy. Can we convince ourselves that various combinations of @trusted pure ensure that object identity does not become a dependency? Do we know whether it is easy to ensure this when writing custom library types? I don't know…

Maybe there is a methodology (design technique) that can be made explicit, but this is where mere arguments don't convince. We have to set up the rules that has to be followed and analyse them.

I think explicit rules for programmers to be followed are needed, in general, for a system level language that both wants to have a higher level type system, and also want to provide "assumption mechanisms" like @trusted.

Of course, system level programming should also give the programmer freedom to customize the runtime, like being able to restart threads on failure etc. So there might be good reasons to bend the rules of "pure". That is an extra layer of trickiness that I think often is forgotten in D discusssions. Often arguments are made as if D is a proper higher level language (more abstract).

On 2021-11-13 12:14, Paul Backus wrote: > On Saturday, 13 November 2021 at 16:57:47 UTC, Imperatorn wrote: >> On Saturday, 13 November 2021 at 14:43:00 UTC, Paul Backus wrote: >>> On Saturday, 13 November 2021 at 14:35:36 UTC, Imperatorn wrote: >>>> Many use the "compromise edition" to pure, I think it's ok. Pure in that sense is just same out for a given in, doesn't matter what the function does inside. >>> >>> [`pureMalloc`][1] does not return the same output for a given input. >>> >>> [1]: https://druntime.dpldocs.info/core.memory.pureMalloc.html >> >> Yeah, these words are not precise enough. > > To be fair, the language spec is also not very precise about this: > >> An implementation may assume that a strongly pure function that returns a result without mutable indirections will have the same effect for all invocations with equivalent arguments. It is allowed to memoize the result of the function under the assumption that equivalent parameters always produce equivalent results. > > What does "equivalent" mean, here? The intent seems to be something like "equal, if you ignore differences in memory addresses," but the term is never actually defined. The upside of these missing definitions is you have the opportunity to introduce them. I'm sure related pull requests would be received well.

Forums