54 karma · joined June 16, 2014
def a(b):
m = 0
return b(m)
Or even: def a(b):
m = b(1)
return m+7
I don't see how these are not a form of function composition. I'm definitely no expert. But I'd really appreciate an elaboration so I can learn from any mistake I'm making.I personally find this view a little overbearing.
In "lay programmer's" terms, functions as first-class objects can often come down to being able to pass functions to other functions or function composition. Most of us learned about function composition in Algebra 2... So that's pretty straightforward even at its worst.
Eliminating side effects is equally straightforward in that all it means is that any variables outside the scope of a given function are not changed by the function.
I would argue that there are many languages (and no reason they couldn't) act otherwise with regard to that second quote. However, the line between pure functional and not starts to become fuzzy as well.
I never found out what the actual paper or project was that accomplished this. But these two papers[1][2] seems pretty interesting - having to do with guaranteeing safety of database access.
[1] http://www.cis.upenn.edu/%7Eeir/papers/2012/singletons/paper...
[2] http://www.cis.upenn.edu/~ahae/papers/dfuzz-popl2013.pdf
Isn't this the definition of a declarative programming paradigm? (I.e. SQL?)
http://stackoverflow.com/questions/16436165/detecting-cycles...
This is at least very easy to reason about. However, if you are still right my thought process is just very wrong.
type a = b
type b = a
If a program has a structure like this with cyclic dependencies, then the compiler must be aware of this and break. (At least, I can imagine a situation where this could be a desired attribute.)