> [Datalog] is a subset of Prolog that lacks recursion
Datalog does allow for recursion — a common example is graph reachability:
reachable(a, b) :- edge(a, b).
reachable(a, c) :- edge(a, b), reachable(b, c).
(Evan mentioned implementing kCFA, which would require recursion like this...)
'Base datalog' guarantees termination by requiring all input relations to be finite. Notably this means that it doesn't have numerical operations like addition or multiplication, since `plus(a, b)` or `times(a, b)` would be infinite relations.
More practical Datalog engines like Souffle (https://souffle-lang.github.io/) have numerical operations but don't guarantee termination.
Recursive queries are not needed by most applications, but maybe Acadia could allow them (compiling to recursive CTEs) by proving that recursion only goes through finite relations.
Pure Datalog can't express peano up to infinity, its terms can't be functors as in Prolog. At best you could hardcode a successor relation up to a limit.
Hi, author here. Thank you so much for this unfudging! I knew I was fudging things up a bit, and I didn't really understand the relationships between Prolog, Datalog, Horn clauses, and first-order logic. This clears things up a lot, though I think I'll need to read it a couple more times for it to sink in! Thanks again.
Maybe the answer is for elm-html to put a cursor-state attribute on textual input elements, and have event handlers for selection change? Then you can have the cursor state in your atom if you need it without ports....
That might solve the cursor issue, but it's a bigger issue than cursor state.
The real issue is that Elm doesn't treat its programmers like grown-ups. That sounds harsh, so let me explain . . .
I've drank enough of the Haskell Kool-Aid to realize that, despite the surface discourse, Haskell is not about religious devotion to purity and lazy-evaluation. It's about managing side-effects, and being honest about them in your type signatures. Yes, Haskell allows functional purity but its real genius lies in how well it helps you manage state. (I did an imperative Algorithms course completely in Haskell, and the language really shines. Mutable unboxed arrays, mutable atomic references . . . it's all there when you really need it.)
Unfortunately, the folks driving Elm development take a paternalistic tack. (If someone seeks to argue this point, it's not hard to come up with many, many examples from the Elm mailing lists.)
I think it's healthy for programming languages to have a point of view; that is, languages should lead you in a direction. (Clojure does a great job at this.) Yet, ultimately, a language shouldn't censor its programmers.
Upshot: Component local state should be an option in Elm when you really need it.
The <~ for Signal.map is a good example for a "clever" thing which makes languages hard to read for newbies. It looks like it's part of the syntax and not a function. It's not hard to understand, but it's another thing to learn. I am very happy that things are removed from Elm (or not added in the first place, like type classes) because design is not finished when there is nothing more to add but when there is nothing more to remove.
I've seen Evan's talk. Evan confuses the presentation of features with the value of those features. (I suppose one could solve the difficulties people have in learning Mathematics by throwing out everything after Algebra I; another solution, however, might be to do a better job teaching the more difficult stuff.)
Just because you shouldn't expose new programmers to advanced concepts on the first day doesn't mean they shouldn't be a part of the language. Similarly, the fact (<~) might confuse someone new to Elm isn't a reason for removing it from the language.
I'm sympathetic to the concern that some code is too "clever" or dense; but Elm swings the pendulum too far.
This is what I expected would already be setup - it'd be a pain to deal with cross-browser stuff when implementing it, but it'd be a dream for app developers (me).
`elm-make --report=json MyFile.elm` gives the error messages as JSON; very easy to parse out line & col. It's how the vim plugin that there's a video of in the post was made.
Yeah, I actually agree. Him just open sourcing the Stop Drawing Dead Fish tool for instance would move things forward a lot -- just to see how the internal data structures & algos work.
Hopefully we can hope to see some of this good design thinking in Android, since the design lead of webOS, Matias Duarte, is now design lead at Android (http://en.wikipedia.org/wiki/Matias_Duarte)
Datalog does allow for recursion — a common example is graph reachability:
reachable(a, b) :- edge(a, b). reachable(a, c) :- edge(a, b), reachable(b, c).
(Evan mentioned implementing kCFA, which would require recursion like this...)
'Base datalog' guarantees termination by requiring all input relations to be finite. Notably this means that it doesn't have numerical operations like addition or multiplication, since `plus(a, b)` or `times(a, b)` would be infinite relations.
More practical Datalog engines like Souffle (https://souffle-lang.github.io/) have numerical operations but don't guarantee termination.
Recursive queries are not needed by most applications, but maybe Acadia could allow them (compiling to recursive CTEs) by proving that recursion only goes through finite relations.