[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Xiaodi Wu]

I don't know very much about this topic, so I won't pretend that I have
strong feelings about Michel's questions, but they are undeniably important
and undoubtedly only one of many.

Before we get to any syntactic bikeshedding, can the proponents of this
feature write up a comparative summary to educate us about the current
state of the art? How have other languages have defined purity? I recall an
earlier message about D, and some rough comparisons or non-comparisons to
C++ constexpr. Roughly, it would be very helpful to get some sense of the
following:

What other C-family languages have a concept of purity?

How is purity defined in those languages?

What use cases are enabled by those definitions of purity, and just as
important, what use cases are notably excluded by them?

If there is evidence in the public record to this effect: if the designers
of those languages could do it again, have they expressed any thoughts
about how they would do it differently with respect to purity?

It has been said that Haskell and other functional languages prioritize
purity over ergonomics of impure functions like I/O. With that in mind,
what design choices surrounding purity made by those languages are
off-limits for Swift?

What use cases or even compiler optimizations are possible in Haskell and
other non-C family languages with a more expansive or stricter concept of
pure functions that we don't find in C-family languages?

If Swift were to adopt some of these beyond-C rules, how would that impact
the user experience with common impure functions (I/O, etc.)?

On Sun, Feb 19, 2017 at 14:45 T.J. Usiyan via swift-evolution <
swift-evolution at swift.org> wrote:

> I'm going to update the draft with points addressed here and the twitter
> conversation. There have been quite a few implications to consider pointed
> out.
>
> This feature is not 'for' the compiler as much as it is for humans writing
> code, but I will address that in the update.
>
> On Sun, Feb 19, 2017 at 3:34 PM, David Sweeris <davesweeris at mac.com>
> wrote:
>
>
> On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> 7. Is it desirable that the optimizer sometime take the pure attribute to
> heart to combine multiple apparently redundant calls into a single one? Or
> is pure not intended to be usable for compiler optimizations? The ability
> to optimize will likely be affected by the answer to these question and the
> loopholes you are willing to allow.
>
>
> AFAIK, "compiler optimizations" are main point of having a keyword for
> pure functions. (Well, that and whatever role it might play in supporting
> constant expressions, but that seems like more of a compiler implementation
> detail than an actual "feature" of pure functions.)
>
> Calling fatalError() is fine IMHO because, at that point, any side-effects
> become a moot point.
>
> I'm inclined to say that passing in reference values is ok, as long as we
> can prove the function doesn't modify anything. Don't know how we'd do
> that, though, since classes don't need that `mutating` keyword for
> functions that mutate `self`.
>
> If someone is determined to use pointers to pointers to get global state
> or something to trick the compiler into accepting *semantically* impure
> code as *syntactically* pure, I'm not sure there's a way we can really
> stop them. Not and still have @pure be useful. (Or maybe we can... I'm
> merely thinking of the saying, "every time someone builds a fool-proof
> system, the world makes a bigger fool".)
>
> I would think that allocating memory is ok, as long as it's either
> deallocated by the time the function exits or it's part of the return
> value, but I don't know a lot about low-level implementation details, so
> maybe there's something I'm missing. If that is a problem, though, I think
> the answer to your "what subset..." question would, more or less, be
> whatever subset doesn't rely on the runtime (the usefulness of that subset
> should expand if/when we extend the syntax around tuples or support
> fixed-length arrays in some other way).
>
> In any case, yeah, IMHO you're correct that we should nail down the
> semantics before worrying so much about the syntax.
>
> - Dave Sweeris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170220/91b53d25/attachment.html>