HN user

trurl

297 karma
Posts0
Comments105
View on HN
No posts found.

I think one thing that would definitely help the mold project is to have a clearer price and licensing model. The only thing I can find is https://opencollective.com/mold-linker.

It would be much easier to be able to go to my manager with that kind of information. Right now the conversation goes:

"Hey, this linker could save us quite a bit of time on our enormous executable." "Okay, how much will it cost us?" "Well, there is this site where you can donate on a regular basis."

Yeah, I figured someone might try this argument.

Everyone seems to keep forgetting, there is already an option on iOS for developers not wanting to go through the App Store: web apps. I believe WASM can even be used these days. Except that Safari doesn't offer developers some privacy sensitive APIs other browsers do. The current side loading pressure has very little to do avoiding Apple's cut and everything to do with bypassing Apple's restrictions.

So I expect should Apple introduce a heavily sandboxed side-loading experience, we'd be seeing developers complain they are not adhering to the spirit or the law or lawsuit.

Fair enough, but to a database theoretician SQL means "non-recursive conjunctive queries". And I skimmed the tutorial and there is not a single example of using Logica to compute something recursively. Transitive closure is the canonical example for showing off Datalog.

It seems misleading to call this "Datalog". The GitHub repo even says "among database theoreticians Datalog and SQL are known to be equivalent", which is absolutely wrong without qualification. Some flavors of SQL will have recursive extensions so that they could be considered equivalent, but that is not true in general.

I can't find any mention of recursion on the original blog post or the GitHub page. Without recursion it isn't Datalog.

Probably fifteen years ago I discussed runtime code generation with some computer architects and they did indeed raise concerns about caching at the time. But now I am not as convinced this is as much of a worry as people seem to think. Sure if you were generating new code ever time you opened a file and did a write perhaps you would blow out the instruction cache with excessive amounts of freshly generated code. But if you waited to generate an optimized version of write until you see it is "hot spot" it seems like you would probably be okay.

I can only speculate, so maybe someone who knows better can correct me, but I would be surprised if many kernel syscall implementations would actually stay in cache after a dwq context switches. Especially with recent timing channel mitigations. But I'm just guessing.

And even if there are architectural issues, with processors seeing less benefit from Moore's Law I would expect computer architects to be looking for ways to eek out more performance such that they'd find solutions.

I don't see anywhere that mentions datalog in relationship to Stardog. I see OWL2 and SparQL, which as far as I can tell do not support recursion other than in experimental prototypes. If there is no recursion, it is just conjunctive queries and not datalog.

The LogicBlox platform is still in use and in active development at Infor. But yes, many of the principals have indeed left.

DOOP actually used LogicBlox before Souffle existed, but it is difficult to be competitive when Souffle doesn't need things like transactions, ACID, datasets larger than memory, incremental evaluation, etc.

There does not seem to be any equivalent of the notion of soundness in the world of dynamic typing. However, we can still talk about whether a dynamic type system strictly enforces type safety.

My understanding is that there are well understood definitions of soundness for dynamically typed languages. The soundness theorem will generally be weaker ("your program will evaluate to a value or abort on a type confusion") but it is certainly possible to be sure a given dynamically typed language definition will never make mistakes like confusing an integer for a pointer. Though in the scheme of things such theorems are not much weaker than what you get for a statically typed language with exceptions ("your program will evaluate to a value with the given type or throw some exception").

It is possible I am misunderstanding something, but I am pretty sure that is not cat(1) implemented in CakeML. It is an implementation of cat(1) verified using the same HOL libraries, tactics, etc. that they used to verify the implementation of CakeML. I didn't look closely enough to see if they have gone all the way and reimplemented HOL inside of CakeML.

I'm not sure why you need to restrict constraints between tables to be based on foreign keys. I guess maybe that is a limitation inherent to SQL?

We also allow constraints over aggregations. Though our syntax does require giving the result of the aggregation a temporary "table" name so that it can be used as part of the constraint.

We've had that for at least a decade in the LogicBlox database (which is based upon Datalog and not SQL). So you could say write

transfer_table(id, user, src, dest, amnt), amnt > 10000.0 -> auth_table(id, man), managed_by_table(user, man).

If you wanted to express that for a transfer involving more than 10,000 dollars that it must have been approved by the user's manager. Basically any logical formula can be used as a constraint. It's also possible to express basic temporal constraints like

+user_pass_table(user, pswd1), user_pass_table@prev(user, pswd2) -> pswd1 != pswd2.

So that says if the user's password has changed, and the user had a password in the previous transaction, they cannot be the same password.

It isn't really clear to me how this differs from usual database integrity constraints? However, I'm not familiar with what typical SQL databases provide.

The database I work on has had sophisticated integrity declarative integrity constraints for a decade now, so it seems surprising that this would be considered something new.

Yes, I'm well aware of tabling, which is why I said "naïve Prolog implementation". I'm also aware of using magic sets and demand transformations to allow writing Prolog-like relations in Datalog.

I also work on an industrial strength Datalog implementation and I can tell you unequivocally there is very little relationship with how a real Datalog engine is implemented and a Prolog implementation.

And no, learning Prolog will not help you learn Datalog. Unless you're going to always us tabling or demand transformations, the difference in evaluation model requires writing in a very different style.

I don't see any mention of recursion. If it doesn't support recursion it is not really accurate to call it Datalog.

To clarify, if you don't have recursion, you've just got a slightly different skin over relational algebra.

While it is possible to view Datalog as a subset of Prolog, they are really very different languages. In particular Datalog implementations generally use forward rather than backwards chaining evaluation. As such, programs you might write in Datalog might diverge in naïve Prolog implementation. Depending on what variant and extensions of Datalog you are using, a program that you could write in the subset of Prolog that matches Datalog might similarly diverge in a Datalog engine.

So really linking to a text on Prolog is not really relevant to a discussion of the merits of Datalog.