Mangle, a programming language for deductive database programming • Hacker News Board

Re: Mangle, a programming language for deductive database programming

#11

Post by throwaway484 » Sat, Nov 26, 2022, 11:11 PM UTC

linkdd wrote: post #2

Inventing a language seems to be a rite of passage for every engineer at google. Go, Dart, Carbon, Mangle, am I missing some? I'm not criticizing, I would not dare as I'm creating my own language as well :P

I can think of a few others…

Sawzall, a language focused around processing logs. Rob Pike led on this but use has pretty much all been replaced by Go. https://en.m.wikipedia.org/wiki/Sawzall_(programming_languag...

Dex, a language focused around array processing from the team behind the Jax machine learning library. Early stage research project. https://github.com/google-research/dex-lang

Rune, a language focused on security, early stage research project. https://github.com/google/rune

Wuffs, a language focused on writing safe file format handlers (parsing, encoding, decoding) https://github.com/google/wuffs

Re: Mangle, a programming language for deductive database programming

#12

Post by UncleEntity » Sat, Nov 26, 2022, 11:15 PM UTC

I’m probably wrong (I’ve been deep diving into RDF triplestores lately) but I think sparql does all that and has a W3C specification.

Maybe the difference is you don’t have to convert your data into (subject, property, object) triples?

Been reading this hexastore paper and they seem to be trying to solve the same problems but I’m no data scientist so who knows.

Re: Mangle, a programming language for deductive database programming

#13

Post by tmptmpgo » Sat, Nov 26, 2022, 11:15 PM UTC

triska wrote: post #10

tmptmpgo wrote: post #9

Earlier quoted context omitted.

Because syntactic doesn’t mean semantic subset. Datalog uses bottom-up evaluation by default while Prolog uses top-down. As such they are computationally very different.

Yes well, as you mention, that is only the default execution strategy, and nothing prevents us from using other execution strategies for either language. In fact, the main advantage of using a declarative language such as Prolog or Datalog is precisely that it can be readily interpreted with different execution strategies, and indeed many Prolog implementations already provide alternative execution strategies, the mo…

Yes, I’m well aware of tabling. But high performance Datalog implementations will fundamentally be very different than the usual Prolog implementations. But sure, it isn’t impossible. Just long a ways from ISO Prolog.

Consider Soufflé, designed for large scale program analysis. Or LogiQL, designed for efficient incremental evaluation.

You also failed to disclose that you are not exactly unbiased individual here.

Re: Mangle, a programming language for deductive database programming

#14

Post by rad_gruchalski » Sun, Nov 27, 2022, 12:32 AM UTC

triska wrote: post #10

tmptmpgo wrote: post #9

Earlier quoted context omitted.

Because syntactic doesn’t mean semantic subset. Datalog uses bottom-up evaluation by default while Prolog uses top-down. As such they are computationally very different.

Yes well, as you mention, that is only the default execution strategy, and nothing prevents us from using other execution strategies for either language. In fact, the main advantage of using a declarative language such as Prolog or Datalog is precisely that it can be readily interpreted with different execution strategies, and indeed many Prolog implementations already provide alternative execution strategies, the mo…

Datalog programs guarantee termination while Prolog programs do not.

Re: Mangle, a programming language for deductive database programming

#15

Post by triska » Sun, Nov 27, 2022, 12:35 AM UTC

rad_gruchalski wrote: post #14

triska wrote: post #10

Earlier quoted context omitted.

Yes well, as you mention, that is only the default execution strategy, and nothing prevents us from using other execution strategies for either language. In fact, the main advantage of using a declarative language such as Prolog or Datalog is precisely that it can be readily interpreted with different execution strategies, and indeed many Prolog implementations already provide alternative execution strategies, the mo…

Datalog programs guarantee termination while Prolog programs do not.

Yes, the subset of Prolog that is called Datalog can be interpreted in such a way that termination is guaranteed, and that is a nice and valuable property of this specific subset, i.e., the functor-free subset, of Prolog.

This is a good example to illustrate why it can be useful to interpret specific Prolog programs and fragments in specific ways, which may also differ from the default execution strategy.

As a specific instance of such an execution strategy, we can again consider SLG resolution: If we interpret any pure Prolog program that does not use compound terms with SLG resolution, then every query we post terminates universally.

Re: Mangle, a programming language for deductive database programming

#16

Post by capableweb » Sun, Nov 27, 2022, 12:39 AM UTC

linkdd wrote: post #2

Inventing a language seems to be a rite of passage for every engineer at google. Go, Dart, Carbon, Mangle, am I missing some? I'm not criticizing, I would not dare as I'm creating my own language as well :P

Initial version of AngularJS by Miško could almost be considered it's own (compile to JS) language.

Re: Mangle, a programming language for deductive database programming

#17

Post by rad_gruchalski » Sun, Nov 27, 2022, 12:41 AM UTC

triska wrote: post #15

rad_gruchalski wrote: post #14

Earlier quoted context omitted.

Datalog programs guarantee termination while Prolog programs do not.

Yes, the subset of Prolog that is called Datalog can be interpreted in such a way that termination is guaranteed, and that is a nice and valuable property of this specific subset, i.e., the functor-free subset, of Prolog. This is a good example to illustrate why it can be useful to interpret specific Prolog programs and fragments in specific ways, which may also differ from the default execution strategy. As a specif…

I don’t understand what you mean. Okay, you can create anything you want on top of Prolog. Is your point that authors of Mangle should have created a Prolog instead of their own Datalog?

Or is more “why don’t they just use Prolog”.

Re: Mangle, a programming language for deductive database programming

#18

Post by PaulHoule » Sun, Nov 27, 2022, 12:48 AM UTC

triska wrote: post #4

This seems already almost valid Prolog syntax, which is also a syntactic superset of Datalog. The main question I have for implementors of Datalog and Prolog variants like this: If you are that close to using Prolog syntax, why not go all the way and rely fully on Prolog, a language for which a well-defined ISO standard and several interesting implementations already exist. One of the key benefits you get in this way…

Prolog is not purely logical in that you can write imperative programs by taking advantage of the fixed order of search and also alter the executing with cuts. One of the great disasters of symbolic AI in the 1980s was the discovery that you can’t parallelize Prolog.

Re: Mangle, a programming language for deductive database programming

#19

Post by operator-name » Sun, Nov 27, 2022, 12:49 AM UTC

linkdd wrote: post #2

Inventing a language seems to be a rite of passage for every engineer at google. Go, Dart, Carbon, Mangle, am I missing some? I'm not criticizing, I would not dare as I'm creating my own language as well :P

Inventing a language is a rite of passage for every engineer. Domain specific problems are best appreciated in the constraints (and flexability) of a domain specific language.

Re: Mangle, a programming language for deductive database programming

#20

Post by rad_gruchalski » Sun, Nov 27, 2022, 1:03 AM UTC

theodpHN wrote: post #8

Some of the other stuff looks intriguing, but regarding the claim that "Unlike SQL, our Mangle rule projects_with_vulnerable_log4j has a name and can be referenced in other queries." goes, SQL in a VIEW or common table expression (CTE) can also be referenced in other queries.

I don’t think a CTE or a VIEW is an intended reasoning behind this claim. It’s more like choosing a part of a WHERE statement based on previous criteria and prior results.