User defined operators vs. SQL back ends
Quote from johnwcowan on August 29, 2019, 1:40 pmQuote from Dave Voorhis on August 29, 2019, 6:24 amD is the family of languages that adhere to the TTM pre/pro-scriptions. D is neither a specified syntax, nor a specified paradigm. D languages may have many different syntaxes and belong to different paradigms.
Technically yes. But it's clear that D was specified from the perspective of statically typed imperative languages. It's possible to mess with the rules a bit to make it more or less fit another paradigm, but the result would not be, strictly speaking, D.
FWIW, the TTM authors have explicitly acknowledged that limitation ("perspective of statically typed imperative languages") because push come to shove, that's the type of language they have come to be intimately acquainted with merely because when and where they had the heydays of their professional careers.
Blue book, page 9, final paragraph : "do not infer from our assumption of an imperative style that we discount the possibility of (e.g.) a functional style [followed by some observations that do show the authors' awareness of where "functional style" would make for some utter differences]".
(Meaning that's the type of language they felt competent/skilled enough about to write about, and therefore also meaning : taking these ideas to the next generations is ***OUR*** responsibility, no longer theirs.)
Quote from Erwin on August 29, 2019, 7:11 pmQuote from johnwcowan on August 29, 2019, 1:40 pmQuote from Dave Voorhis on August 29, 2019, 6:24 amD is the family of languages that adhere to the TTM pre/pro-scriptions. D is neither a specified syntax, nor a specified paradigm. D languages may have many different syntaxes and belong to different paradigms.
Technically yes. But it's clear that D was specified from the perspective of statically typed imperative languages. It's possible to mess with the rules a bit to make it more or less fit another paradigm, but the result would not be, strictly speaking, D.
FWIW, the TTM authors have explicitly acknowledged that limitation ("perspective of statically typed imperative languages") because push come to shove, that's the type of language they have come to be intimately acquainted with merely because when and where they had the heydays of their professional careers.
Blue book, page 9, final paragraph : "do not infer from our assumption of an imperative style that we discount the possibility of (e.g.) a functional style [followed by some observations that do show the authors' awareness of where "functional style" would make for some utter differences]".
(Meaning that's the type of language they felt competent/skilled enough about to write about, and therefore also meaning : taking these ideas to the next generations is ***OUR*** responsibility, no longer theirs.)
Yes.
It should be noted that TTM is neither a formal specification nor a demand for fealty. The prescriptions and proscriptions provide a set of general directions for achieving rigour, consistency, and logical foundation in database languages, but not necessarily the only such set. I am quite sure that any approach which achieves those goals would (a) inevitably build on TTM even as it deviates from it, as all good science builds on what came before; and (b) be applauded by Date & Darwen and anyone else who appreciates not just TTM but why there is a TTM.
Quote from johnwcowan on August 29, 2019, 1:40 pmQuote from dandl at August 29, 2019, 11:25 am
We don't really want to re-implement NumPy or LINPACK or IMSL in SQL code.
No, we don't. But there's no reason that SQL back ends shouldn't have access to arbitrary scalar libraries, either. PL/Java for PostgreSQL is a step in this direction, and most engines support some sort of C plugins, though they usually require pretty messy C glue.
I gave that as an example of how infeasible it would be to transcompile into SQL. The general reality is that every business has lots of code to implement a variety of complex business calculations (pricing, estimating and payroll come to mind). So you get to make trade-offs between choice of language and whether or not those functions are available to SQL queries. If it were possible to replace SQL in the server by one of the modern GP languages with RA extensions, the problem would largely go away.
Andl on Postgres is implemented as PL/Andl (much like PL/Java), but it has open expressions which AFAICT other languages do not. And yes, the C code is beyond messy (I had to write some).
Quote from Dave Voorhis on August 29, 2019, 8:52 pmQuote from Erwin on August 29, 2019, 7:11 pmQuote from johnwcowan on August 29, 2019, 1:40 pmQuote from Dave Voorhis on August 29, 2019, 6:24 amD is the family of languages that adhere to the TTM pre/pro-scriptions. D is neither a specified syntax, nor a specified paradigm. D languages may have many different syntaxes and belong to different paradigms.
Technically yes. But it's clear that D was specified from the perspective of statically typed imperative languages. It's possible to mess with the rules a bit to make it more or less fit another paradigm, but the result would not be, strictly speaking, D.
FWIW, the TTM authors have explicitly acknowledged that limitation ("perspective of statically typed imperative languages") because push come to shove, that's the type of language they have come to be intimately acquainted with merely because when and where they had the heydays of their professional careers.
Blue book, page 9, final paragraph : "do not infer from our assumption of an imperative style that we discount the possibility of (e.g.) a functional style [followed by some observations that do show the authors' awareness of where "functional style" would make for some utter differences]".
(Meaning that's the type of language they felt competent/skilled enough about to write about, and therefore also meaning : taking these ideas to the next generations is ***OUR*** responsibility, no longer theirs.)
Yes.
It should be noted that TTM is neither a formal specification nor a demand for fealty. The prescriptions and proscriptions provide a set of general directions for achieving rigour, consistency, and logical foundation in database languages, but not necessarily the only such set. I am quite sure that any approach which achieves those goals would (a) inevitably build on TTM even as it deviates from it, as all good science builds on what came before; and (b) be applauded by Date & Darwen and anyone else who appreciates not just TTM but why there is a TTM.
This topic has been discussed at length. My recollection is that the big issues were static typing and assignment. The expectation of static typing is pervasive (particularly as to RM Pre 18), so a modern dynamically-typed language would not qualify. There is no obvious way around this.
Most implementors of TTM/D have come up with a language largely in the functional mould (Andl is certainly one of those), and getting a clear definition of what qualifies as assignment (RM Pre 21) is not so simple. All FP languages provide some way to update persistent state, but don't call it assignment or expose it that way in the language. But this is mostly a definitional problem, not one of substance.
Quote from dandl on August 30, 2019, 12:45 amQuote from Dave Voorhis on August 29, 2019, 8:52 pmQuote from Erwin on August 29, 2019, 7:11 pmQuote from johnwcowan on August 29, 2019, 1:40 pmQuote from Dave Voorhis on August 29, 2019, 6:24 amD is the family of languages that adhere to the TTM pre/pro-scriptions. D is neither a specified syntax, nor a specified paradigm. D languages may have many different syntaxes and belong to different paradigms.
Technically yes. But it's clear that D was specified from the perspective of statically typed imperative languages. It's possible to mess with the rules a bit to make it more or less fit another paradigm, but the result would not be, strictly speaking, D.
FWIW, the TTM authors have explicitly acknowledged that limitation ("perspective of statically typed imperative languages") because push come to shove, that's the type of language they have come to be intimately acquainted with merely because when and where they had the heydays of their professional careers.
Blue book, page 9, final paragraph : "do not infer from our assumption of an imperative style that we discount the possibility of (e.g.) a functional style [followed by some observations that do show the authors' awareness of where "functional style" would make for some utter differences]".
(Meaning that's the type of language they felt competent/skilled enough about to write about, and therefore also meaning : taking these ideas to the next generations is ***OUR*** responsibility, no longer theirs.)
Yes.
It should be noted that TTM is neither a formal specification nor a demand for fealty. The prescriptions and proscriptions provide a set of general directions for achieving rigour, consistency, and logical foundation in database languages, but not necessarily the only such set. I am quite sure that any approach which achieves those goals would (a) inevitably build on TTM even as it deviates from it, as all good science builds on what came before; and (b) be applauded by Date & Darwen and anyone else who appreciates not just TTM but why there is a TTM.
This topic has been discussed at length. My recollection is that the big issues were static typing and assignment. The expectation of static typing is pervasive (particularly as to RM Pre 18), so a modern dynamically-typed language would not qualify. There is no obvious way around this.
Maybe that's as it should be. It's not difficult to argue that dynamic typing lacks the rigour intended by TTM.
Quote from Dave Voorhis on August 30, 2019, 7:38 am
Maybe that's as it should be. It's not difficult to argue that dynamic typing lacks the rigour intended by TTM.
To each their own taste, as the devil said when he painted his tail sky-blue. After all, one well-known kind of rigor is rigor mortis. :-)
Quote from johnwcowan on August 30, 2019, 11:25 amQuote from Dave Voorhis on August 30, 2019, 7:38 amMaybe that's as it should be. It's not difficult to argue that dynamic typing lacks the rigour intended by TTM.
To each their own taste, as the devil said when he painted his tail sky-blue. After all, one well-known kind of rigor is rigor mortis. :-)
I'm sure there's a perfect emoji response for this.
Since Version 1.3, DuroDBMS supports PostgreSQL as a backend.
Currently, DuroDBMS does not attempt to convert WHERE clauses that contain invocations of user-defined operators to SQL.