Formal definitions for Relation Constant, Transitive Closure, Extended Transitive Closure
I think you don't understand. :-)
Certainly not where that seems to be headed.
Remember, I wrote, "Though purely academic -- I doubt there's any practical outcome from exploring this -- I think it's interesting to consider what a general-purpose language might look like that doesn't have those limitations."
This is an academic exercise, not a practical one. It's about thinking about what a post-Java, post-C# world might or should look like. Though I use C# and Java professionally almost every day, I have no illusion that these are the endpoint of commercial software development -- or that Python, JavaScript/Typescript, Rust, Julia, you-name-it are the future endpoint of commercial software development, either.
I think it's academically interesting to think about what an ideal, relational-enabled or relational-enabling general-purpose post-Java/post-C#/post-whatever language might look like. In short, it's fun to dream about a possible future.
There simply are no languages that look anything like that. I once asked a question on LambdaTheUltimate: are there any Ultra High Level Languages out there. The answer is no, really no.
4GLs tried to do it, and the Japanese even had a 5GL project, but they all failed. Turns out there was a major unsolved problem: a good enough 3GL/HLL, before you start worrying about 5GL/UHLL. Give or take a few tweaks, I think that one is largely solved. So now back to the UHLL.
My take FWIW is: less is more. The only way you can have a higher level language is by leaving out some of the lower level stuff. The 64 dollar question is: which bits?
IMHO the simple criterion is LOC. Give me a typical application of (say) 10K LOC and show me something that does exactly the same function in 1K LOC. Lots of the detail will be gone, many of the choices will have been made without my making them. But I only have to write 1/10 the lines of code. That's where the answer will be found.
As for the current commercial world, the TTM relational model largely doesn't apply. The closest we've got are SQL and NoSQL and the facilities of commercial tools, like Java Streams and C# LINQ. We create libraries that facilitate those, not replace them, and that's almost entirely not anything like TTM. Aspects of our work might be influenced by TTM thinking, but implementing the TTM relational model and type system into our current commercial world...?
No. That's a different issue and arguably, if we're using current tools there's no significant benefit anyway.
But that's not what I'm talking about here.
That's precisely what we'd like to avoid. Though purely academic -- I doubt there's any practical outcome from exploring this -- I think it's interesting to consider what a general-purpose language might look like that doesn't have those limitations.
For example, I imagine it would have a flexible compile-time type algebra to allow composition of arbitrary static types and thus (among other things) relation/tuple headings. External code generation and run-time type-checking would not be required.
For another example, perhaps it would have first-class built-in transactional persistence. Would it be key/value stores? Object persistence? Or something else? Or perhaps not at all and that should be left to library routines. I don't know.
Now we're way beyond remit, and I have no idea what need would drive that. Let me know if you ever figure it out.
What drives it for me is that there is always value in thinking about what the ideal software development future might -- or should -- look like.
That's not "way beyond remit", it's simply a different remit from how we get the TTM relational model (or some relational model) into current tools and, as an aside, perhaps a slightly more enjoyably discursive and less negatively emotional topic as it doesn't involve anyone trying to make money from it.
It has nothing to do with this forum topic or where is was headed until you did a left turn. Maybe you should start a new one.
- The GTC as per DTATRM.
Code as needed in a user-defined operator.
Have you ever written the code? It looks hard. I can't see how to do it in Andl, with no facility to iterate over tuples.
I haven't written the code. Tutorial D does have a facility to iterate over tuples (ARRAYs), so there is that.
Pretty clunky isn't it? Not something you're going to knock up in 5 minutes, and not generalisable either. Sounds like a good argument for WHILE.
And incidentally, WHILE turns out to be really useful for other times you want to add new tuples, not just GTC.
If I'm using Rel, it's not something I generalise. I create an operator as needed.
Given that it's straightforward to create user-defined operators, I don't see the need for a built-in WHILE.
I notice you didn't argue with 'clunky' or 'not in 5 minutes'. You don't see the need, but that doesn't mean it's not there.
I don't know whether it would be 'clunky' or 'not in 5 minutes' or not. I haven't tried it.
I've used transitive closure once. I don't remember the use case. I did it in Rel using TCLOSE. It seemed straightforward.
Anything beyond that would need more thought. I guess (to the extent that I care, which is not much) I'd like see some compelling practical use case.
Mine was simple: extend the RA to include GTC as per TTM. I found the result very satisfying.
Very satisfying for what practical use cases?
Doing what D&D could not: solve the problem set in their book. Then it turns out to be useful for building tables in less LOC (see above).
Quote from dandl on March 12, 2021, 10:25 amI think you don't understand. :-)
Certainly not where that seems to be headed.
By "certainly not", do you mean you certainly don't understand, or you certainly do?
Remember, I wrote, "Though purely academic -- I doubt there's any practical outcome from exploring this -- I think it's interesting to consider what a general-purpose language might look like that doesn't have those limitations."
This is an academic exercise, not a practical one. It's about thinking about what a post-Java, post-C# world might or should look like. Though I use C# and Java professionally almost every day, I have no illusion that these are the endpoint of commercial software development -- or that Python, JavaScript/Typescript, Rust, Julia, you-name-it are the future endpoint of commercial software development, either.
I think it's academically interesting to think about what an ideal, relational-enabled or relational-enabling general-purpose post-Java/post-C#/post-whatever language might look like. In short, it's fun to dream about a possible future.
There simply are no languages that look anything like that. I once asked a question on LambdaTheUltimate: are there any Ultra High Level Languages out there.
These are two different things.
An ideal, relational-enabled or relational-enabling general-purpose post-Java/post-C#/post-whatever language isn't necessarily Ultra High Level. I was thinking of a conventional 3GL but with a -- first and foremost -- better type system, multiple dispatch or predicate dispatch, maybe built-in persistence, etc. We know Java and C# (and C++, Typescript, PHP, Python, etc.) don't make a good D on their own, so it would be nice to consider what would make them better at becoming a D but not only that, what would make them better general-purpose 3GLs while we're at it.
As for Ultra High Level languages, there are -- apparently -- some. I was approached late last year by a company that makes one, ostensibly to see if I wanted to work for/with them. I didn't (I think... long story) but their product -- fully relational and based on Datalog -- is perhaps an ultra high level language.
It's declarative and apparently saves literally hundreds of thousands of equivalent C#/Java lines (they're converting such programs to use their product) in their niche domain. It's a niche apparently shared by competitors also making Datalog-based (or similar) products. There is nothing like them in general use or general availability -- and they almost certainly wouldn't be generally useful; this is all niche domain stuff -- and you won't get to see them unless the companies making them are either trying to hire you or you work in their domains and you have the seven digits or so in fees to spend on projects using them. I guess. I got a bit of a eyes-only glance at the product, and yes it's cool stuff -- by way of analogy, kind of like a power drill that will instantly blow holes in absolutely anything of any depth up to a mile, but only of a single small diameter.
But that's always been the case. The specialist world is full of specialist tools that ostensibly do near-magical things (I've seen similar claims for products based on D L Childs's extended set theory) that the rest of us never get to see.
I'm not suggesting an Ultra High Level Language, just wondering what a post-C#/post-Java language should look like -- in particular, but not limited to, what would make it easier to use it as a D.
What drives it for me is that there is always value in thinking about what the ideal software development future might -- or should -- look like.
That's not "way beyond remit", it's simply a different remit from how we get the TTM relational model (or some relational model) into current tools and, as an aside, perhaps a slightly more enjoyably discursive and less negatively emotional topic as it doesn't involve anyone trying to make money from it.
It has nothing to do with this forum topic or where is was headed until you did a left turn. Maybe you should start a new one.
Yeah, maybe. I'm not too concerned about staying strictly on topic, as this isn't a crowded forum where that sort of thing matters -- at least not to me. To those whom it does matter, feel free to spawn another topic.
- The GTC as per DTATRM.
Code as needed in a user-defined operator.
Have you ever written the code? It looks hard. I can't see how to do it in Andl, with no facility to iterate over tuples.
I haven't written the code. Tutorial D does have a facility to iterate over tuples (ARRAYs), so there is that.
Pretty clunky isn't it? Not something you're going to knock up in 5 minutes, and not generalisable either. Sounds like a good argument for WHILE.
And incidentally, WHILE turns out to be really useful for other times you want to add new tuples, not just GTC.
If I'm using Rel, it's not something I generalise. I create an operator as needed.
Given that it's straightforward to create user-defined operators, I don't see the need for a built-in WHILE.
I notice you didn't argue with 'clunky' or 'not in 5 minutes'. You don't see the need, but that doesn't mean it's not there.
I don't know whether it would be 'clunky' or 'not in 5 minutes' or not. I haven't tried it.
I've used transitive closure once. I don't remember the use case. I did it in Rel using TCLOSE. It seemed straightforward.
Anything beyond that would need more thought. I guess (to the extent that I care, which is not much) I'd like see some compelling practical use case.
Mine was simple: extend the RA to include GTC as per TTM. I found the result very satisfying.
Very satisfying for what practical use cases?
Doing what D&D could not: solve the problem set in their book. Then it turns out to be useful for building tables in less LOC (see above).
I'm not sure what you mean by "building tables."
I was looking more for real-world use cases.