FBP and query languages?

[Samuel Lampa]

It seems to me that query languages (SQL, datalog, LINQ, OCL etc etc) have a strong connection to FBP in that query syntax is often transformed into a kind of flow-based program behind the scenes.

Query languages seem to be very popular and successful also ... perhaps by fitting well with how people thing about problems -- allowing them to specify what data they want in a declarative way.

Thus, I was interested in the experience, thoughts and ideas in this community, about this connection?

Some more specific questions:

1. How strong is the query lang <-> FBP connection. Are there certain characteristics making the flow-based programs generated by query systems very different from other FBP systems?

2. Based on my limited understanding, it seems the processes in query-generated FBP programs are often more generic (generic join, filter processes etc). 

BUT, could it be that more specialized FBP components could also be fit into a query language?

3. Could it be that some query language would be the optimal high-level language for quickly designing FBP systems?

4. Is there some even more generic language than queries, that one would aim for, as the utopian, high level declarative language for computation?

Cheers

// Samuel

[Sam Watkins]

On Tue, May 09, 2017 at 02:07:30AM -0700, Samuel Lampa wrote:
> It seems to me that query languages (SQL, datalog, LINQ, OCL etc etc) have
> a strong connection to FBP in that query syntax is often transformed into a
> kind of flow-based program behind the scenes.

I agree, I use a lot of SQL at work, and often wish I could specify more
exactly the process components that would implement a query, rather than hoping
the DBMS will do it correctly. I would love to use FBP structures for queries
rather than SQL, or some sort of "declarative FBP" where I could specify the
details or choose to leave them vague.

> 1. How strong is the query lang <-> FBP connection. Are there certain
> characteristics making the flow-based programs generated by query systems
> very different from other FBP systems?

There's a very strong connection in my opinion. A query like this:
select id, name from customer
join order on order.customer_id = customer.id
where order.total > 1000

Can convert nicely to a FBP network:
order -> [where total > 1000] -> [join customer ...] -> [select id, name]

> 2. Based on my limited understanding, it seems the processes in
> query-generated FBP programs are often more generic (generic join, filter
> processes etc).
> BUT, could it be that more specialized FBP components could also be fit
> into a query language?

I think so. In some cases it's good to leave the details of how the query is
implemented to the query engine. So I think a declarative language which can
implement FBP would be more powerful than normal FBP.

> 3. Could it be that some query language would be the optimal high-level
> language for quickly designing FBP systems?

I think declarative graph programming would be more powerful and expressive
than both FBP or query languages.

> 4. Is there some even more generic language than queries, that one would
> aim for, as the utopian, high level declarative language for computation?

Yes, in theory; I don't think we have a good implementation for such a language
yet though. It should be able to specify everything from math equations
through to FBP processes and networks in a uniform graph language, and it
should support some sort of macro processing to rewrite specified networks to
(nearly) optimal executable networks for the specific problem. It should also
support a fairly concise and textual notation for the language, many people
prefer to use a textual notation, but the langauge should be naturally
graphical.


Sam

[Samuel Lampa]

Thanks for the very interesting input.

On Tuesday, May 9, 2017 at 3:09:06 PM UTC+2, Sam Watkins wrote:

> 1. How strong is the query lang <-> FBP connection. Are there certain
> characteristics making the flow-based programs generated by query systems
> very different from other FBP systems?

There's a very strong connection in my opinion.  A query like this:
        select id, name from customer
        join order on order.customer_id = customer.id
        where order.total > 1000

Can convert nicely to a FBP network:
        order -> [where total > 1000] -> [join customer ...] -> [select id, name]

Indeed, and thinking about it, I have realized that more "forward chaining" thinking like this, such as when chaining bash commands with pipes, tends to be a lot easier to develop in an iterative fashion.

What I like about languages like datalog though, is that you can create named queries to represent concepts, which can be combined indefinitely into further queries, and this way get an iterative way of working too.

> 3. Could it be that some query language would be the optimal high-level
> language for quickly designing FBP systems?

I think declarative graph programming would be more powerful and expressive
than both FBP or query languages.

Interesting.

 

> 4. Is there some even more generic language than queries, that one would
> aim for, as the utopian, high level declarative language for computation?

Yes, in theory; I don't think we have a good implementation for such a language
yet though.  It should be able to specify everything from math equations
through to FBP processes and networks in a uniform graph language, and it
should support some sort of macro processing to rewrite specified networks to
(nearly) optimal executable networks for the specific problem.  It should also
support a fairly concise and textual notation for the language, many people
prefer to use a textual notation, but the langauge should be naturally
graphical.

Also very interesting. Leads me to think about the wolfram language, which seems to have a lot of the "math language" and "specifying declarative relationships" to it, although I have no idea how FBP-like it is under the hood ... as it is not very open.

It also seems prolog and datalog are going partly in this direction, with the ability (at least in some subsets of it) to write a translator or compiler that you can run backwards, etc etc.

Still nothing that goes all the way towards what you describe though, but I agree that that sounds like a very interesting direction!

Best

// Samuel