I want to start a side conversation about effects. Rust has a user-defined effect system. I thought about that in BitC, but concluded it doesn't work out well. The problem is that the "ground" operations from which effects are determined are hard to specify. This tends to leave me thinking that user-defined effects may be better handled with attributes and offline tools, at least until we understand better what we want to do with them, what they are intended to check, and how to specify which ground operations are of concern to us.
But that leaves open the question of what effects we *do* want the language to be able to track. Here are the ones currently on my personal list. I'd like your thoughts, additions, and counter-arguments. - *GCAlloc* allocates in the general GC heap - *DynamicRegionAlloc* allocates in some dynamic region - *NoEscape* data sent in to this procedure does not flow to any super-region of the regions specified by the parameters. - *NoDetect* - The procedure's execution does not detect effects on any location *other than* those reachable from it's parameters. In particular, any locations within the closure (if any) or the globals that is accessed by the procedure (if any) is deep-constant. The distinction between "NoEscape" and "NoDetect" is this: a "NoEscape" procedure will not leak your data. A "NoDetect" procedure will not alter its behavior based on the behavior of any other code. In particular, a "NoDetect" procedure cannot be the recipient of state from any third-party by way of access to shared global state. In consequence, the behavior of a NoDetect procedure is a strict function of its arguments. The execution of a "NoEscape, NoDetect" procedure having only deep-constant arguments is pure. In consequence, *pure* should be treated as a convenience quasi-effect in the interest of reduced annotation burden. For similar reasons, *NoHeap* should be a convenience quasi-effect meaning *!(GCAlloc OR DynamicRegionAlloc)*. What other built-in effects do people see a use for?
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
