Proposal for a Functional D
Quote from Dave Voorhis on December 8, 2019, 7:09 amQuote from dandl on December 7, 2019, 11:45 pmQuote from AntC on December 7, 2019, 9:33 amQuote from dandl on December 7, 2019, 2:50 amThe following changes are proposed to evolve the current imperative TTM/D into a functional form.
You'll need to explain first why you haven't chosen a monadic (or at least continuation-passing) style to represent updating the database. I don't find your proposal is in a 'functional form'.
You should get out more, you're just seeing everything through a Haskell fog. The paradigm I've chosen can span the entire range from 'OO pretending to be FP' right through to fully functional. It enables FP, rather than demanding it.
Incidentally, this paradigm is well known in the JS world. My inspiration includes Flux, Redux and Elm, not Haskell.
Anything "well known in the JS world" can almost certainly be dismissed.
(big) If wikipedia on those "inspiration"s is any guide ...
- JavaScript is multi-paradigm. Having functions as first-class is not sufficient to make it Functional Programming IMO. Furthermore David's proposals might be from the imperative-paradigm parts of JS. (That's certainly how they read to me.)
- Elm's semantics seem to be tightly bound to JavaScript's. " the Elm compiler targets HTML, CSS, and JavaScript." Then ditto. "Elm does not support higher-kinded polymorphism," then it's not up to the job of supporting a D, nor of supporting Monad's or continuation-passing.
- Redux is a JavaScript library. Then ditto. Redux "operates in a similar fashion to a reducing function, a functional programming concept." Whoop-de-doo. You don't need no Functional Programming paradigm to implement a reducing function.
- Flux is an architecture "... concept of unidirectional data flow (which might be contrasted with AngularJS's bidirectional flow),". "Flux features actions which are sent through a central dispatcher to a store, and changes to the store are propagated back to the view." "A React component under the Flux architecture should not directly modify any props passed to it, but should be passed callback functions that create actions which are sent by the dispatcher to modify the store."
OK this sounds more like continuation-passing. A Monad is a higher-kinded container for exactly managing actions to modify the 'world' external to the program (including the database). Notably carrying out those actions is outside the flow-of-control of the application, with results (including changes to the database) propagated back to the view/application uni-directionally.
I find the description of Flux architecture inconsistent with David's proposals about " the value of the database at an earlier point in time" and rollback/undo.
Seeing "through a Haskell fog" provides influential clarity. Much of the JS and 'OO pretending to be FP' and other functionally-inspired world we owe to Haskell, but to Javascript we owe the exact opposite, whatever that might be.
The opposite looks like a plum-duff of FP concepts mashedup with imperative implementation, with all the 'power' of imperative/destructive update and all of the pitfalls; along with a not-high-enough-typed semantics that fails to seal off (program-external) effects/actions from referentially-transparent manipulation of values.
I understand your criticisms, but I don't accept them. It was always my intention to enable an FP language as D, not to mandate it or any particular flavour. What I wrote is perfectly adequate for that purpose.
There are two aspects of what I wrote that may not suffice. One is allowing external communications, side-effects and persistent storage in the body of a program, which would make it not a pure function, but might well make it more useful, more practical and more acceptable. Many such languages have made that choice, but many bad things can be done in such dark places. Perhaps that should go.
The other is to move the state change operation of updating the database outside the program. That makes the spec far simpler to write and is sufficient for the stated purpose of a 'database language', but would make it fall short of being suitable for general use. I see replacing that by a 'controlled assignment' as a significant complication for a marginal benefit.
I won't respond to criticisms of JS. It's sitting there at no 7 on the TIOBE list, with Haskell at no 41. I don't want an FP beauty contest won by Haskell because it was the only qualified entrant. I can Get Stuff Done with JS (or any of the top 7), and I can write FP-style code in most of them.
But really, this was always intended as an invitation. This is my list of changes to TTM that would be easy for any kind of FP to satisfy. Please do take the opportunity to put forward your own proposal.
Quote from dandl on December 9, 2019, 2:57 amI won't respond to criticisms of JS. It's sitting there at no 7 on the TIOBE list, with Haskell at no 41. I don't want an FP beauty contest won by Haskell because it was the only qualified entrant. I can Get Stuff Done with JS (or any of the top 7), and I can write FP-style code in most of them.
There's no doubt JavaScript is popular, which has occurred for various (mostly bad) reasons. The point is that it's a weak basis for FP-oriented thinking. Haskell -- along with various academic and technical references -- is much better, which is why Haskell is the primary proving ground and conceptual basis for implementation of FP ideas, not JavaScript.
I'm all for a functional D, but I'd expect any proposal for one to make explicit reference to TTM Pre's 12 - 16, 19 and 21. 17 shouldn't simply be waved away but appropriately accommodated, and 12 - 16, 19 and 21 should be rewritten not to eliminate relvars but recast them in a functionally-pure form. I'd expect such a recasting to feature the phrase "I/O monad" or something rather like it, which essentially allows you to take the example I posted at https://forum.thethirdmanifesto.com/forum/topic/fp-ttm-and-d-was-new-implementation/ and notionally turn it inside-out, so stateful assignment to the database is conveniently written inside pure functional code, but still safely occurs outside of it.
While Haskell has made an invaluable contribution in researching and teaching FP concepts, its core principles are not so widely adopted by other FP and FP-like languages and there are differing viewpoints on how to deal with side-effects. I'm looking to accommodate FP and FP-like languages, not prescribe one.
I think your number list is off, but I would agree that all mentions of variables requires some tweaking (as I attempted). I stick with my main point of recasting the database as a single variable holding an immutable value, and thus dispensing with MA and transactions. Whether you want to perform database update as a visible controlled assignment or invisibly as I proposed is perhaps less important. There are consequences when the type system is involved that need careful thought.