Pure functions/effect system

[SoniEx2]

Can we get pure fn which would be a way to indicate a function has no side-effects/can only call other pure fns?

It'd prohibit mutation of statics, pointers and references, and heap allocations. Traits would be able to demand pure fns, which would be useful for getters.

[burdges]

Would unsafe would allow mutation or calls to non-pure functions inside a pure fn? I suppose say taking a reference to an Arc<T> is not pure since it must update the reference count?

[eddyb]

@burdges Taking a reference to Arc<T> is free, .clone() does a refcount increment.

[eddyb]

I believe the general solution for this which is not completely cumbersome, and can support various predicates on the behavior (another useful one is "can panic/abort") is an effect system, but I can't find open issues on anything like that.

[SoniEx2]

@burdges I guess unsafe could be used to say "this doesn't strictly follow pure rules, but we can guarantee it's still pure ourselves"...

[SoniEx2]

I guess unsafe blocks inside pure impls would be useful for RPC and stuff.

[burdges]

I'd agree with @eddyb that one should work out how a (non-)effects system might fit into Rust.

A priori, I'd wager this requires first working out how higher-kinded types fit in, if only because effects are monads in Idris. Ain't clear if a non-effect like pure can or should be viewed a monad, comonad, etc., but I doubt you drop abstraction with the non.

There might be interesting papers on using HTKs to do non-effects like pure in non-pure functional languages. Ask @edwinb if he's seen anything similar. :)

[birkenfeld]

Did anything change since http://thread.gmane.org/gmane.comp.lang.rust.devel/3674/focus=3855 ?

[glaebhoerl]

Rust's affine types would in fact already enable having a really strong and flexible notion of purity that's well-integrated with the existing type system, without having to add any major new features or annotations on top of it. If you chase links from this recent discussion I had on reddit you can read more of my thoughts about it. TL;DR there'd be a zero-sized IO type (a capability token) that's not Copy or Clone, I/O and shared mutable state like Cell and RefCell would require it, and any fn and &Fn which don't receive IO as an argument could therefore not be anything other than pure. Further refinements possible.

But it's not something that could be easily retrofitted onto Rust 1.x.

[ticki]

I am against this because of the lack of generality. pure is just one of many effects systems, which could be useful. Ideally, these should be expressed through the type system (i.e., as traits implemented by function pointers and closures), but I am unsure how it can be "restricted" (in the sense that pure code can't call impure code, non-panic code can't call panicable code, and so on). In particular, there are two ways of breaking such an restriction. The first one being by propagating it, namely letting callers carry the same bound. The second way is local and non-propagating way, which might not always be allowed.

Either way, such an addition should be general and most importantly expressive, covering lots of possible use cases (an example is the insecure, denoting standard non-UB security problems, which is frequently asked for).

Finally, I could see such a feature being abused in one way or another, especially since it might not be consistent across libraries. One way that could be solved is to provide a medium sized collection of common "effect systems" (in the lack of a better term), but uniformity is still not guaranteed: each library might have its own definition of "secure" and "not secure", and these might or might not play well together.

[SoniEx2]

pure should be synonym for "mathematical function", and unsafe inside pure should let you use I/O for RPC.

[HallM]

Design by contract may be a possible path for this by allowing a contract to flag all side effects a function may generate. With Spark14 (maybe Ada12 as well), you specify which globals/statics you may read from, which you may read & write, and which parameters you may write. Params passed in are assumed read access. Then would need the compiler to propagate those contracts and enforce that if B calls A, then B's contract must contain the same level of side effects as A in it's contract. For backwards compatibility, no listed contracts would have to be assumed as "anything goes".

I would not agree with allowing unsafe or impure blocks inside of a pure. It breaks the contract and purpose of saying the function is pure. I use layers where the outer-most layer handles IO/user input/anything external to the app, calls an internal pure-layer to do processing, then that returns something to return back out of the app.

[SoniEx2]

I think "unsafe pure" is "hey compiler, you can't check the purity of this but I'm a smart developer so trust me on this".

Allowing some RPCs to be pure would be nice, and "unsafe pure" does exactly that. In theory you'd need to use unsafe { unsafe { stuff here } } to be able to do unsafe things, in practice that'd be a pain for the compiler and you'd instead either have impure {} or just use a plain unsafe for both.

The compiler can't guarantee a RPC is pure because 1. it knows nothing about RPCs 2. it's implemented over I/O which's impure, but that doesn't mean a RPC isn't pure.

Take, for example, getting the title of a Guake tab. This must be implemented as a RPC, but it's still pure as it mutates nothing.

[killercup]

Huh, I may be crazy, but: How much of the pure fn stuff is already available by using const fn?

[gsnoff]

@killercup I think there are quite a lot of limitations in the current RFC for const fn per se (see here, for example), and it's also quite likely that any existing implementation for that is even more limited.

[killercup]

That was my expectations as well. There are (unofficial) plans to use Miri
in the future for const eval, though.

Ilyas Gasanov notifications@github.com schrieb am Mo. 15. Aug. 2016 um
18:00:

@killercup https://github.com/killercup I think there are quite a lot
of limitations in the current RFC for const fn per se (see here
https://github.com/rust-lang/rfcs/blob/master/text/0911-const-fn.md#detailed-design,
for example), and it's also quite likely that any existing implementation
for that is even more limited.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1631 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABOXwBaMWh268pLgzMbKhV31dIbqU58ks5qgI0fgaJpZM4Inbba
.