Arc Forumnew | comments | leaders | submitlogin
Purely functional programming with Arc?
10 points by are 6175 days ago | 3 comments
With the very limited number of special forms that Arc has, would it be possible to determine at compile-time (after macro-expansion, of course) whether a particular compiled Arc-expression has side effects or not? Could be important for supporting concurrent programming etc...

(And just to clarify, the answer to this sort of question may be well-trodden ground in e.g. the Scheme community, without me being aware of it. In any case, I would like to know whether the differences between Arc and Scheme would affect the answer.)



4 points by viergroupie 6175 days ago | link

I imagine a conservative purity analyzer wouldn't be too difficult to write. Mark a set of primitives as pure. An expression is pure if it is composed of pure primitives or other pure expressions. If an FFI is involved, you'll probably have to manually annotate foreign functions as pure or impure. How does that sound?

-----

4 points by Darmani 6175 days ago | link

A purity analyzer would need to be a little more complex than that - the "=" operator would be pure or impure depending on the scope of the location being set. The simple way to solve that would be to make locations created within any lexical context that is discarded with the completion of the function pure and those without impure, although they may be slightly complicated.

Of course, some situations, such as code that sets unset values in an outside hash table to the default value, may arguably be "pure" functional code, although dealing with such things is outside the domain of a "conservative" purity analyzer.

-----

2 points by ehird 6174 days ago | link

it is impossible. it is the halting problem. sorry.

(Well, monads without unsafePerformIO would work..)

-----