Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Functions in functional programming have states, the input parameters and return output are states.


...which implies that (when viewing a computation as a sequence of states [vertices] connected by transitions [edges]) the more functional one's program is, the larger the chunks are that one can effectively model as atomic transitions, and the shorter these state sequences are.

Reducing N may not qualitatively do much from the pedant's point of view, but if one's (formal or informal) analyses tend to scale as O(N*3), reducing N quantitatively may make a difference: between tractable (for formal analysis) or "fits in developers' heads" (for informal analysis) on the one hand, and a big ball of mud on the other.


Being in particular function is itself a state, too. The program counter, stack pointer, and stack contents are all state.


That’s the C abstract machine, not the Lisp one.


The C abstract machine has nothing about stacks or program counters. There is the concept of sequencing: what is currently being evaluated, what has been evaluated and what is not yet evaluated. When a function is called, the calling function is suspended; then when the invoked function returns, the caller is resumed. From that we can infer that there must exist an activation chain.

Mainstream Lisps have all these abstract elements also. The main differences are in data, and environments what constitutes a value; what is a type; what is a variable; what is the lifetime of an object, and the scope of visibility of a binding, ...


Most language implementations have these or similar things. Variations don’t change the point I’m making.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: