4 ms·
Unfortunately "functional" is coming close to being the Next Big Idea, which means it stops meaning anything specific. If you look at unlambda[0] as the kind of
by bandrami 12y ago
Unfortunately "functional" is coming close to being the Next Big Idea, which means it stops meaning anything specific. If you look at unlambda[0] as the kind of Platonic ideal of functional languages you might see what GP is talking about.
It lacks any facility for bindings because any binding is a storage of state. Roughly, since you can refer to every function and value literally, the idea behind unlambda is that you should.
(Note that by this way of looking at things, closures are not "functional" at all and are in fact embeddings of imperative mini-languages.) Historically, closures were more or less developed by accident as LISP codified its scoping rules; in that sense their presence isn't particularly indicative of "functional ness"; it's just that using them requires a GC and 40 years ago only functional languages had one.
[0] http://www.madore.org/~david/programs/unlambda/ http://www.madore.org/~david/programs/unlambda/
- kibwen 12y agoAlthough historically closures have required GC, both C++ and Rust have implemented a design for closures without that requirement (and the latter manages to retain memory safety while doing so).
- the_af 12y agoI agree there is no widely accepted and formal definition of "functional". Thanks for the link! I didn't know about Unlambda. A couple of remarks though: by the author's own admission, Unlambda is not a purely functional language, when using the accepted terminology. The author then goes on to introduce what he acknowledges to be nonstandard terminology, so I'm not sure what this says about closures being functional or not under more mainstream definitions. Furthermore, Unlambda is a purposefully obfuscated language! Not sure how it is relevant for the purpose of my post or the OP's :) Thanks anyway for the link, it's interesting.