FDJS - functional, declarative javascript

From Wikipedia, the free encyclopedia

This article may require cleanup to meet Wikipedia's quality standards.
Please improve this article if you can. (March 2008)

This article or section needs copy editing for grammar, style, cohesion, tone or spelling.
You can assist by editing it now. A how-to guide is available. (March 2008)

Though Javascript is typically used in an imperative, procedural way, the availability of closures in javascript opens the door to programming in a functional, declarative paradigm.

Functional programming and declarative programming benefit from their simplicity and highly expressive nature. User interface programming (typically what javascript is used for), in particular, can benefit from functional and declarative programming paradigms, simplifying the expression of how form elements interrelate.

Procedural implementations of user interface code results in complicated event handling with callbacks often exposing inconsistencies in the state of UI elements due to path dependencies. Functional programming avoids state and side-effects, and is therefore virtually immune to such inconsistencies.

1 Closures are the key
2 Pure functional vs. side-effects
3 Closures for declarative programming, too
4 Turning the world around: all getters, no setters
5 Example (traditional) javascript user interface code
6 Example code in functional, declarative javascript
7 See also
8 External links

[edit] Closures are the key

Closures, or "functions as variables," as they are sometimes described, are coded in javascript with the keyword "function" appearing as a right-hand-side value or in an argument to another function:

   var myadder := function ( a, b ) { return a + b }

   object2.setfunc( function ( x, y ) { return x * y } )

... and they are invoked using the name of the variable or parameter which "holds" the closure:

   var result := myadder( 10, 12 )

Closures are key to implementing Higher-order functions in Javascript. There are many implementations of functional libraries for javascript, encapsulating the work of transforming javascript into a decent functional language. Some good references are found in the external links.

[edit] Pure functional vs. side-effects

In its purest sense, functional programming exists only in a kind of vacuum, allowing no side-effects, no state, and no I/O. In reality, either the functional model is compromised in order to interact with the "real world", or a functional model is married to an event framework to handle the dirty work of I/O. As long as state is kept outside of the functional programming model, it is a reasonable compromise. Another approach to state and I/O in functional programming is Monads in functional programming. This is also just a compromise, introducing obvious complexity into the functional programming model.

Any functional implementation of user interface code (in Javascript) will require some model for coupling the state of the HTML form elements with the events which affect them, while the transforms may be coded in a pure functional sense.

[edit] Closures for declarative programming, too

In declarative programming code represents "what" is to be done, rather than "how" it is to be done. There are varying degrees to which a declarative programming language accomplishes this shift. All pure functional languages can be considered declarative inasmuch as they focus on defining output of a function in terms of its input, deemphasizing the order of operations. In contrast, procedural, imperative programming focuses on a series of ordered steps.

Closures open the door to declarative programming in Javascript, as well. By relating all of the state held in the browser's HTML form elements through closures, a declarative Javascript implementation can avoid coupling the events and state directly in the user interface code. The closures are evaluated as-needed, when form elements change or when other related closures are evaluated and produce a different result. In this way the code code focuses on what the form elements should do, rather than the order in which it will be done.

The Domain-specific programming language of spreadsheet "formulas" is declarative in this same fashion: Each cell is self-descriptive and self-consistent, containing the code which defines the value shown in the cell. Any change to other referenced cells causes reevaluation of the formula. This self-consistency is the goal of functional, declarative javascript.

[edit] Turning the world around: all getters, no setters

With closures installed as the only coupling between events and state changes, it is possible to use only pure functions (no side-effects). This completely eradicates the need to code with "setters", the imperative way of affecting another object's state. In functional, declarative javascript, convention demands that all relationships between form elements and intermediate variables are coded without the use of setters.