posted by bryanedds

posted by bryanedds

posted by SteveRichter

Now the mention of aliasing immediately led my thoughts to Bertrand Meyer's paper on the theory and calculus of aliasing.

posted by exoteric

http://lamp.epfl.ch/~imaier/pub/DeprecatingObserversTR2010.pdf

It is interesting in that it demonstrates a little of what Jonathon Edwards was talking about. By the middle of the paper I was excited about FRP and DataFlow programming in general, but by the end of it I was trying to wrap my head around the complex compositional relationships I would now have to manage. If you were to use instead a declarative model, a large portion of the complexity could simply be represented by implied relationships in a declarative expression.

In defense of scala (though I personally have a love-hate relationship with the language), scala has an expression-based syntax, not a statement based one (like C#, not counting LINQ). This single distinction makes custom declarative programming models a natural part of the language, and in fact this is one of the features that are critical to implementing internal DSLs in scala. For example, you can (and some have tried already: http://github.com/vladimirk/scalalinq/) implement things like linq in scala without using any custom syntax or compiler plugins - just plain scala.

posted by JeroMiya

1) Isn't this bring a form of sql to the desktop?  Declaritive and data driven language?  Linq?

2) Declaring the data first sounds like we can still learn some things from Cobol's declarations section.  Declare the data tree first. The data is the application model.  A tree would seem to solve a few other problems regarding transactions and rollback and locking.  With a tree, the runtime can know what the locking order is by tree order.

3) Couldn't you start experiments on this idea without boiling the ocean?  I mean a framework like Rx can express some pretty progressive ideas without have to start from a new runtime and language.  It could take five years or more just to get the point of being able to experiment with the core ideas to see if it any of them work.

4) Haven't people like Jim Gray solved some of this on server end using parallel pipelines, trees and folk-joins? 

posted by staceyw

posted by bryanedds

C

posted by Charles

The view would be markup language agnostic as long as it understands bindings and has a provider to communicate with the View VM. Ie. You could declare a text box or red cube if the markup supported it in XAML, html or VRML and it would display as needed.

The super code behind (SCB) would be a declarative domain specific language (DSL) that provided attributes, behaviours, triggers, events landings, and bindings to the data management layer and/or program smarts layer.

An optional program smarts layer (PSL) would be programming language agnostic as long as it compiled to an IL that could be used by the SCB. Basically it is the foreign code access layer that can do all the dangerous stuff like access file system directly, internet, C libraries, etc. How you would be able to do this would be similar what I said in Brian Beckman’s monads and coordinate systems where the VM would declare binary landmarks that the language assembly provider would work out how that relates to its types and structures, then be sandboxed in an security overseer.

The data management layer (DML) would be about organising access points to data sources that you could declaratively work with. This would enable you to add data access points to text/xml files, sql/object/no-sql databases, data services, etc. as long as each data point had a provider that we could declaratively read/write to. Eg. In the PSL you could use LINQ to query data from a text file merging it with sql server data and a web service. The SCB would display the data as it arrived and signalled to the SCB that more data is on the way to display as such in the View. The DML would also have its own code behind DSL that could be called to perform data source specific features. Ie. Non-read/update/add/delete operations.

That's how I would describe my idea of programming futures.

posted by N2Cheval

Perhaps the use of 'Domain' in DSL is a misnomer. What is special about a DSL is not the domain it covers, but the specialized forms of expression it provides to solve a specific class of problems (in this case, defining dataflows). The class of problems don't necessarily have to apply to a specific application domain AFAIK, though that's a common usage.

In short, a DSL captures an expression model. That expression model can be conveniently applied to one or more domains (assuming the DSL is well-motivated).

I've only written a couple of DSLs, though, so someone please correct this if there is a more concrete or better definition.

posted by bryanedds

posted by edwards

posted by edwards

Using a declarative approach, perhaps there's a way to specify the outcome (state delta or some such) of desired changes under certain conditions instead of invoking mutating operators / imperative statements directly. Since you'd be specifying the outcome declaratively, presumably it can be done within a DSL. I've not implemented such a feature before, however, so I don't know if it will actually work...

posted by bryanedds

posted by staceyw