Lambda the Ultimate

I don't buy that. First of all, CS is not a science, but an engineering, which is perfectly fine as many other engineering disciplines are fairly credible and even support lots of scientific research (though most engineers do engineering).

Second of all, design is...design, its not something you can use empirical evidence to guide. We can conduct user research after the fact to see which design is "better" with respect to some problem. There is a good reason why most of the successful language design comes from outside of academia.

Because people from outside academia have more empirical evidence?

Because people inside academia need empirical evidence to publish papers :) When you write a paper, you need some kind of evaluation section to show how the approach is better, so its very difficult to publish just on design. So what you have is feeling and preference...

Its a science dealing with one central notion: computation. Now whether that makes it a subcategory of math, I don't know, but a science nonetheless.

Whether its an interesting, or even a good, science, no idea. The sceptic would say that CS's major scientific contribution to industry would be C, and a bunch of algorithms.

[I am not _that_ sceptic.]

looking forward to that.

The idea looks interesting, but you need something meatier to express the differences to a functional approach. Three questions spring to mind that you could answer with bigger examples:

The bigger examples exist in my SuperGlue work (here and here). But then you could also look at any constraint system like Kaleidoscope, pseudo high-level environments like Citrus or Adam and Eve. Actually, there are a lot of languages out there that are based on binding rather than application/composition. But the declarative binding is managed in different ways to regain expressiveness.

In the functional case the definition is constructive; we can extract a sequence of state transitions to get from the initial state to the target state directly from the semantics of function reduction. In the declarative binding case it is not quite so obvious. You seem to be binding properties to logical relations, there is no obvious reduction to get from one to the other. How are you defining it?

I'm not sure they are logical relations, just binding properties to values and guarding those bindings somehow to restrict universal quantification. My is_blue_button is simply a type used in this way (and of course, types are one form of predicates). Other constraint systems have other ways of restricting the scope of a constraint (in imperative systems, applying a declarative constraint can even be an imperative operation!).

2. As your targets seem to be logical relations you should be able to express certain properties more easily than you can with functions - for example if I define a second implication make_button_red can you derive that this implication and the original are mutually exclusive?

In SuperGlue, you would wind up with a run-time error since the blue and red binding would conflict. I'm not sure statically checking consistency properties is feasible, but checking them at run-time is still useful. In a functional approach, you could easily make a blue button red, without any error occurring (but then again, you could check that the value you are shadowing in the function is not already a visible color).

3. How do you introduce recursion? If I want to make a list of buttons blue then it is straightforward to do so using a recursive make_button_blue, what is the equivalent step in declarative binding?

The goal would be to avoid explicit recursion; e.g., by applying bindings with respect to universally quantified variables. In this case, the rule that made buttons blue applies to all buttons that can pass the rule's guard. Function application is definitely more expressive than declarative binding, but declarative binding can be more usable in situations where the full power of lambda isn't necessary.

". . . but declarative binding can be more usable in situations where the full power of lambda isn't necessary" confuses me because it seems to me that ToonTalk (TT), the actor model of Hewett, and Janus are all constraint languages and therefore examples of declarative binding, but they also provide the full power of lambda. When I say TT, actors, and Janus exemplify declarative binding, does that make it evident that I am missing something about what "declarative binding" means?

A language can have both declarative binding and lambda. But even though lambda is/can be Turing complete, it wouldn't be used for everything like it is in say...Haskell or Lisp.

Missing the context, at least. Sean's use of 'declarative binding' is in reference to its use in the reactive programming context described in the OP. That is, he is exploring how to best go about expressing that one value is related to another such that as one varies over time, so shall the other.

The declarative binding approach: create a variable, and - based upon conditional decisions that are not captured - bind to this variable a particular time-varying expression. Later time-varying changes to the variables that led to this decision will not be reflected in the variable binding. IO, presumably, may also feed into the decision for the binding.

The pure functional 'composition' approach: variables are indistinct from expressions - no delayed assignment - and, as one consequence, you must capture any conditional decisions for a property within the functional expression. IO is prohibited in the functional expression. The lack of delay has other significant consequences. I currently take a rather firm position in favor of this approach.

Janus, TT, Oz, etc. do perform 'declarative binding', but they are dealing with immutable quantities. Because the quantities are immutable there is simply no reason (other than debugging, perhaps) to 'capture the conditional decisions'. After all, if you apply an immutable function to an immutable value, you'll invariably come to the same immutable decision.

Sean's 'declarative binding vs. composition' isn't a true dichotomy, of course. Here's an approach that wasn't explored:

History Rewriting: In a system like Janus one could, presumably, keep all those declarative-binding activation records around in order to capture the decisions that lead to each variable binding. This hybrid would, like all hybrids, share both the best and the worst of both the binding and the functional approaches. It would inherently result in maintaining a very large dependency-graph of variables. Basically, after any change in the reactive quantities (which exists outside the program) one would be recomputing the whole history of the program as it would have been computed if the quantity were at its new value all along. I'm not quite sure where or how IO would fit.

I'm curious as to how well this could perform and scale. I suspect it could perform well with enough graph rewriting to optimize it, but that it would be easy to (by accident) let the program grow wildly out of control - at which point performance at a similar scale would be moot.

History Rewriting: In a system like Janus one could, presumably, keep all those declarative-binding activation records around in order to capture the decisions that lead to each variable binding. This hybrid would, like all hybrids, share both the best and the worst of both the binding and the functional approaches. It would inherently result in maintaining a very large dependency-graph of variables. Basically, after any change in the reactive quantities (which exists outside the program) one would be recomputing the whole history of the program as it would have been computed if the quantity were at its new value all along. I'm not quite sure where or how IO would fit.

I'm curious as to how well this could perform and scale.

We call that a memory leak.

I doubt step-wise debugging would work. In SuperGlue, I would just debug the interpreter, but that was mostly because my implementation was buggy :). Perhaps additional rules to debug assumptions, along with a visualization of how the rules work together?

that is an interesting turn of phrase because it does make me think a little bit about what it means to debug. other people have, of course, thought about that question already, although i haven't studied it a lot -- which i should. at a high level, the problem is that the programmer had a mental model with which they predicted outcome (or failed to see edge cases) and that doesn't jive with what happened. so traditionally they need to see the state and the history of that state sometimes, with the code. partially because they don't know which assumptions are wrong, so they can't make assertions ahead of time (although presumably DbC somewhat disagrees with me here) because otherwise they wouldn't have made the mistake? well, at least locally.

This would, for example, allow me to say that "a button is usually colored grey" in rulebook A, and say "a 'go' button is colored green" in rulebook B, and to assert "a 'commit' button in a foobaz panel is colored red if said panel is in an invalid commit state" in rulebook FooPanels. I could then create a 'model' by combining rulebooks, using precedence and heuristics to resolve conflicts. In a fully reactive system, even the rulebooks themselves (and the 'set' of applied rulebooks for a particular model) may be reactive entities, allowing developers and users to tweak rules at runtime, create pluggable and runtime upgradeable rules-sets, etc.

This is what SuperGlue already does very concisely. In the "Live Programming" dialect:

class Button : Widget;
Button.Color = Grey;
class Go : Button;
Go.Color = Green;
class Commit : Button;
class foobaz : Panel;
var CommitInFooBaz : Commit, foobaz.Child, Invalid;
CommitInFooBaz.Color = Red;

SuperGlue uses inheritance relationships to prioritize connection binding, which was the whole point of my dissertation. The live programming dialect supports dynamic inheritance, so we can have classes that inherited only at certain times, while types can refer to container objects.

Your "is" in your rulebook description suspiciously resembles a declarative binding construction to me. I know its possible to express logic programming with forward chaining in a functional programming language, but then doesn't the language become something else?

This is what SuperGlue already does very concisely.

Your example lacks a mechanism for organizing rules independently of the data to which they are later applied, which prevents declarative maintenance of parallel views (i.e. where buttons with 'go' text are displayed blue in one model and green in another, without ever creating a new object).

Your "is" in your rulebook description suspiciously resembles a declarative binding construction to me.

It's declarative. One might similarly assert that foo 1 "is" 10. This is a partial function definition of 'foo'.

But there is no binding. The partial definition binds nothing to the values 1 or 10 (i.e. if someone else asks for 1.foo, they'll just get an error). Properly, it isn't even a introducing a 'binding' on foo. foo isn't an object! 'foo' identifies a function, for which a partial definition is offered. Whether that particular partial definition gets accepted depends on potential for higher-precedence partial definitions selected by a 'composer' function.

I know its possible to express logic programming with forward chaining in a functional programming language, but then doesn't the language become something else?

Though I didn't express logic programming above, I agree with your basic sentiment: since the above is not a straightforward application of functional programming (it relies upon discipline, perhaps a small framework or EDSL transform), it is not unreasonable to refuse to call it 'functional'.

But one might call it a functional design pattern. We had an related LtU discussion on first-class patterns. One solves a composition problem by distributing a function definition across a collection of inputs. The implementation is (ignoring static type-safety and termination analysis) entirely straightforward in functional. The above applies this design pattern atop a reactive medium, using functional reactive behaviors (which may reference external resources) in place of pure functions.

Your example lacks a mechanism for organizing rules independently of the data to which they are later applied, which prevents declarative maintenance of parallel views (i.e. where buttons with 'go' text are displayed blue in one model and green in another, without ever creating a new object).

I disagree. The rules are organized by type of the targets they affect. If you can somehow make the model a part of the button type, then problem solved (go buttons in model A are blue while go buttons in model B are green).

But there is no binding. The partial definition binds nothing to the values 1 or 10 (i.e. if someone else asks for 1.foo, they'll just get an error). Properly, it isn't even a introducing a 'binding' on foo. foo isn't an object! 'foo' identifies a function, for which a partial definition is offered. Whether that particular partial definition gets accepted depends on potential for higher-precedence partial definitions selected by the 'compose' function.

I was referring to your english description. You talk about a rule that binds properties on certain conditions. I refer to that as declarative because you don't specify each instance of the rule's execution. Rather, the rule fires when its conditions are satisfied (I might be taking liberties on terminology here).

I agree with your basic sentiment: since the above is not a straightforward application of FRP, relying upon discipline and meta-programming, it is not unreasonable to refuse to call it FRP. But since the properties most closely match FRP, and its implementation is (ignoring static type-safety and termination analysis) entirely straightforward in FRP, one might reasonably call it an FRP 'design pattern'.

True, but I feel like I have a hard time communicating with FRP people, since what we have in common (declarative manipulation time-varying values) is overshadowed by different ways of basically "building the graph" (function application or via declarative connection/binding/etc...). Functions are a dandy way of building a graph, or anything else that you want, but they aren't the only way and maybe not even the best way. Perhaps my question is...what is the best paradigm for building a FRP-style dependency graph? Arrows?

If you can somehow make the model a part of the button type, then problem solved (go buttons in model A are blue while go buttons in model B are green).

Your answer seems very far from a solution...

Creating a tight coupling between the source of the button and its color is essentially the opposite of: "organizing rules independently of the data to which they are later applied".

Needing to create even ONE 'new GoButton' (regardless of whether it be in Model A or Model B) is a clear violation of "without ever creating a new object" - that is, you are demanding a violation of declarative composition.

A 'pure FP' design never needs to create buttons, which in turn means it never needs to maintain buttons... FP declaratively 'interprets' buttons into a platonic existence from another resource, then decides things like the color of those buttons it has interpreted into existence. The 'rulebooks' in the above example were a mechanism for organizing such decisions as button color independently of the transform that initially produce the buttons. (One might relate this to XSLT or CSS, given all the references to buttons.)

You talk about a rule that binds properties on certain conditions. [...] the rule fires when its conditions are satisfied (I might be taking liberties on terminology here)

I did not talk about "a rule that binds properties" or that "fires".

I apologize if the use of 'rulebooks' terminology threw you. Full rules-based programming tends to involve triggered behaviors, which are often imperative in nature. But I spoke of pure FP design, and thus of pure rules. Examples are: "all pigeons are birds" or "a fever contributes to a conclusion of a cold" or "unless there is argument contrariwise, buttons say a button is colored gray".

These rules get composed into functions like "bird? X" by testing to see if X is a pigeon, or "color B" that tests if B is a button and, if so, says it's grey unless some other rule overrides. A function is responsible for the composition of these rules, thus there is meta-programming involved.

Perhaps my question is...what is the best paradigm for building a FRP-style dependency graph? Arrows?

There probably isn't a "best paradigm", but one certainly could build a list of known problems to solve. Were I to write such a list, the problems I listed for declarative binding would certainly be on it. A couple more would be: avoid assuming a history - even a modest history of just one value - is maintained by arbitrary data resources; avoid hindering demand-driven multi-cast or caching; avoid syntactic risk of cyclic reactive expression; avoid side-effects on updates; avoid need to observe intermediate values if several variables shift in a short time frame.

The only design I know that solves all the problems I can name is the 'pure functional' composition, augmented by a few common design patterns.

Your answer seems very far from a solution...

Creating a tight coupling between the source of the button and its color is essentially the opposite of: "organizing rules independently of the data to which they are later applied".

Needing to create even ONE 'new GoButton' (regardless of whether it be in Model A or Model B) is a clear violation of "without ever creating a new object" - that is, you are demanding a violation of declarative composition.

I agree with you on this. But then we are getting into very different territory. Actually, what you are talking about is sort of a holy grail of UX programming that has been chased for 20 years. To say that we just specify "what we want" from the UI, then have a bunch of rules create a UI based on the context (e.g., a mobile, multi-touch table, or standard desktop). Yes, of course, that's how it should be! But this modularization is similar to a very hard AI problem, no one has been able to do it yet in a very satisfactory way and we begin to wonder if that's possible. Function composition doesn't help much at all, I think.

What I'm specifying isn't a 'Holy Grail'. I don't offer any miracle paradigms that read our minds and give us 'what we want' as opposed to 'what we specify'.

Further, you have made reasonable arguments elsewhere that physics may be a more suitable - more "naturalistic" - basis than FRP for UI tasks, since physics allows one to tune transitions in state and include external forces. For physics, Declarative Binding doesn't hurt you because you require object identity and system 'state' in order to control transitions.

What function composition design patterns do offer is a means to tweak style and other properties based on rules distributed among different resources. In the context of UI, you could relate this to HTML with CSS, using 'classid="go"' and such to choose the color green. Except, in a reactive context, reactive HTML + reactive CSS would avoid any need to ever 'refresh' a page. The main problem with such a UI would be transitions: i.e. a button might bounce around the screen based on external changes, unless the browser does some special physics-style work render-side to support transitions.

The OP isn't about UI specifically. It's about declarative composition of reactive 'models'. Whether a UI is a reactive model (view) of some external service, as opposed to an entity in and of itself, is really up to the developer of a particular UI. Arguments for the reactive model concept relate to mashups, sharing, persistence, zoomability.

Regardless, function composition and similar mechanisms of organizing and tweaking the 'rules' guiding the model independently of the 'data' guiding it will be a huge part of any modularity solution, whether it be reactive (tweaking transforms) or physics based (tweaking the physics) or a combination of the two. I think you grossly underestimate the value of said resulting separation of concerns.

What I'm specifying isn't a 'Holy Grail'. I don't offer any miracle paradigms that read our minds and give us 'what we want' as opposed to 'what we specify'.

I didn't say that you were. I'm merely talking about the pure modularization between content and presentation: that we can talk about actions, data, and input independently of layout, widgets, and visuals. So not to have a button at all, but rather an action like "delete the currently selected email message."

Further, you have made reasonable arguments elsewhere that physics may be a more suitable - more "naturalistic" - basis than FRP for UI tasks, since physics allows one to tune transitions in state and include external forces. For physics, Declarative Binding doesn't hurt you because you require object identity and system 'state' in order to control transitions.

Maybe this is orthogonal: I believe that physics is a more suitable approach to the underlying task of maintaining a dependency graph once built, but because physics can handle more relationships and more complicated constraints. Both declarative binding or function composition could give us the dependency graph that physics would process, however. Admittedly, I don't know what physics-based functional reactive programming would actually look like.

Regardless, function composition and similar mechanisms of organizing and tweaking the 'rules' guiding the model independently of the 'data' guiding it will be a huge part of any modularity solution, whether it be reactive (tweaking transforms) or physics based (tweaking the physics) or a combination of the two. I think you grossly underestimate the value of said resulting separation of concerns.

I think we are working with separate ideas in how these systems work. I didn't see reactive or physics as being the primary concern, but expressing relationships or configuration as the hard problem.

At any rate, I need to think about this, really going to physics could completely change the way we think about relationships, which would necessarily affect how we express them. In reality, the color of something depends on their material combined with the properties of lighting. The position depends on where the thing is placed, which can be influenced by various force combinations. Hmm...

I didn't see reactive or physics as being the primary concern, but expressing relationships or configuration as the hard problem.

How is 'expressing relationships' relevant if they aren't being maintained over time? I don't believe you can usefully separate the expression of a relationship from the semantics of expressing said relationship. How you wish to express them will be closely related to why you wish to express them. (How is Why, backwards.)

I'm merely talking about the pure modularization between content and presentation: that we can talk about actions, data, and input independently of layout, widgets, and visuals. So not to have a button at all, but rather an action like "delete the currently selected email message."

Using a word like "merely" there doesn't seem appropriate.

Anyhow, I've seen this sort of modularization before.

But it takes a LOT of meta-data to make it work... i.e. the presentation side needs to know which actions are specified for 'the currently selected email message' if it is to group them into a menu.

We often resort to 'artificial' meta-data intended primarily for hooking by the presentation layer (such as 'classid' and 'id' on HTML elements) or for providing suggestions to the presentation layer. This 'artificial' meta-data to support relationships and offer suggestions is convenient, but largely eliminates 'purity' of any modularization; in practice, most coding for presentation ends up in those 'suggestions' and other hooks.

If we were to assume a capability UI, where the only information you can obtain about a capability (without actually applying it) is meta-data that has been provided to you, then I suspect a pure separation would be impossible. The difficulty in analyzing actions for intrinsic properties makes almost any script just as difficult to analyze as a capability. Thus, chances are slim to none we'll ever see a pure separation.

Rather than separation of content and presentation in the initial configuration, I think it better to focus on enabling late-binding transformations and recomposition (for mashups, accessibility, stylization, etc.) of content annotated ('marked up') for presentation. Transformations could then trade one presentation for another, or manipulate content, and so the 'separation of content and presentation' could still be achieved as a 'discipline' for organizing transformations.

Actually, what you are talking about is sort of a holy grail of UX programming that has been chased for 50 years.

Fixed that for you...