Quote from Erwin on March 9, 2021, 10:31 pm

Quote from Dave Voorhis on March 9, 2021, 10:23 am

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

V is for "new value" (actually a contradiction in terms which is the way he betrays that he just doesn't "get it" because somehow he manages to think that TTM's selectors aren't what he means here).

A is for "aggregation" and there's a mildly fair point there because I believe exposing something much closer to the real fundamental concepts underneath "aggregation" is both possible and feasible.  (Not that I believe poster's way of tackling this issue is getting us anywhere closer.)

and W is for, well, you know which word of your average procedural RBAR langauge (*) it stands for ...  (*) i.e. non-declarative as opposed to how/what a data language was always intended by Codd, and really ought to, be.

 

These posts are really tiresome.

Quote from dandl on March 9, 2021, 11:27 pm

So I was able to create an implementation of the 9 operator ERA (SPJRUN+VAW) natively within C#: fully functional, but unfortunately not immune to runtime type errors without a compiler mod or preprocessor. I think that's a good start, but if you want to drop the RA entirely I have no idea where you would go.

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

I got tired of repeating myself. SPJRUN is Alice's name for the basic Codd's RA named perspective: select,project,join,rename,union,negate. VAW is new value, aggregate,while. SQL/DML does all this, except with limited aggregation.

The possibility of runtime type errors is the sort of "undesirable caveats" I had in mind. Indeed, that's why we implement whole new languages -- to get around precisely those limitations in the popular programming languages.

What's interesting to me is what a programming language -- a general-purpose programming language -- would need to look like to make it (relatively) easy for a programmer to create a D using it.

Easy: C# with a header type, as I've already shown (provided you're willing to give up the dinky generated types and go with generics). Either:

• add a small amount of meta-programming to C#, so that the operations needed can be implemented as compile-time code, or
• add a pre-processor to do the same thing. C++ was created by adding a preprocessor to C, but the emitted code was still pure C. A similar strategy would do the same for C#.

It could possibly be done in C++ and other languages with sufficiently powerful generics/templates, but I don't know them at that level of detail. C++ was not created as a whole new language, and while you may not approve, it's been phenomenally successful at what it does. I'm writing C++ at present, I love/hate it, but this project could never have been written without it.

Maybe Java can do it, but it's not a good base to start from. And if you stick to the full TTM type system, there is no solution. Dead parrot.

1. 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.

 

Quote from dandl on March 9, 2021, 11:37 pm

Quote from Erwin on March 9, 2021, 10:31 pm

Quote from Dave Voorhis on March 9, 2021, 10:23 am

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

V is for "new value" (actually a contradiction in terms which is the way he betrays that he just doesn't "get it" because somehow he manages to think that TTM's selectors aren't what he means here).

A is for "aggregation" and there's a mildly fair point there because I believe exposing something much closer to the real fundamental concepts underneath "aggregation" is both possible and feasible.  (Not that I believe poster's way of tackling this issue is getting us anywhere closer.)

and W is for, well, you know which word of your average procedural RBAR langauge (*) it stands for ...  (*) i.e. non-declarative as opposed to how/what a data language was always intended by Codd, and really ought to, be.

Thanks Erwin. Are you familiar with the usage of new value in Alice? It has nothing to do with constructors or TTM selectors, it refers to the ability to introduce into a result a value that was not already there. It's a value that was not stated as a fact and/or provided as a literal, but computed from other values. In my ERA, every new value is simply provided by the application of a function to its arguments, expressed in the form of a relcon.

In my formal treatment of aggregation, I rely on a function that takes an unordered list (not a set) of values as its argument and returns a value. This keeps it as first order, whereas the TTM approach requires second order (the iterated application of a function).

W is for while, which is fixed point recursion, just like SQL. I do not yet have a formal definition, but it will be the fixed point summation of a series and not itself first order.

These posts are really tiresome.

What would you prefer? Silence?

Quote from Dave Voorhis on March 9, 2021, 11:43 pm

Quote from Erwin on March 9, 2021, 10:31 pm

Quote from Dave Voorhis on March 9, 2021, 10:23 am

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

V is for "new value" (actually a contradiction in terms which is the way he betrays that he just doesn't "get it" because somehow he manages to think that TTM's selectors aren't what he means here).

A is for "aggregation" and there's a mildly fair point there because I believe exposing something much closer to the real fundamental concepts underneath "aggregation" is both possible and feasible.  (Not that I believe poster's way of tackling this issue is getting us anywhere closer.)

and W is for, well, you know which word of your average procedural RBAR langauge (*) it stands for ...  (*) i.e. non-declarative as opposed to how/what a data language was always intended by Codd, and really ought to, be.

 

These posts are really tiresome.

Well, that's two letters cleared up.

Still baffled by 'W', despite the hint.

RBAR is "Row-by-agonising-row." I googled it. (I thought it was "record by" something, and maybe sometimes it is.)

ERA is Extended Relational Algebra?

SPJRUN; no idea and Google's no help. I'm sure I've asked before, too.

I'm ashamed to admit how long it took "TTM" to sink in.

Really not good with recognising or remembering acronyms, here. Please, use your words, people!

Quote from AntC on March 10, 2021, 7:39 am

Quote from Dave Voorhis on March 9, 2021, 11:43 pm

Quote from Erwin on March 9, 2021, 10:31 pm

Quote from Dave Voorhis on March 9, 2021, 10:23 am

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

...

These posts are really tiresome.

Seconded.

...

SPJRUN; no idea and Google's no help. I'm sure I've asked before, too.

I'm ashamed to admit how long it took "TTM" to sink in.

Really not good with recognising or remembering acronyms, here. Please, use your words, people!

Seconded, though I'm not seeing you need to address this request to "people" in general.

Unless dandl is typing his posts on a phone, it's really not difficult to copy'n'paste a 6-word list, rather than using acronyms.

dandl has used SPJRUN often enough, and Erwin has used RBAR enough I can recognise those (and SPJRUN is indeed from Alice). The other sets of letters I didn't recognise. (ERA can stand for rather a lot of things, see wikipedia's disambiguation page; and they've not included all the terms starting Enterprise Resource A.., beloved of ERP vendors.)

@dandl Are you familiar with the usage of new value in Alice?

Yes I am; and I find it a particularly strange term for what they're trying to say; and I'm not at all convinced dandl uses it in the same way as Alice. Irrespective, it's not a term I expect participants here would understand.

In my ERA, every new value is simply provided by the application of a function to its arguments, expressed in the form of a relcon.

Then you're taking a value from a relcon. Then it's not "new" in the sense in Alice. It's very similar to "taking" a value from relcon ADD in Appendix A. Hugh doesn't describe that as new value.

Quote from dandl on March 10, 2021, 8:28 am

Quote from AntC on March 10, 2021, 7:39 am

Quote from Dave Voorhis on March 9, 2021, 11:43 pm

Quote from Erwin on March 9, 2021, 10:31 pm

Quote from Dave Voorhis on March 9, 2021, 10:23 am

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

...

These posts are really tiresome.

Seconded.

...

SPJRUN; no idea and Google's no help. I'm sure I've asked before, too.

I'm ashamed to admit how long it took "TTM" to sink in.

Really not good with recognising or remembering acronyms, here. Please, use your words, people!

Seconded, though I'm not seeing you need to address this request to "people" in general.

Unless dandl is typing his posts on a phone, it's really not difficult to copy'n'paste a 6-word list, rather than using acronyms.

Nevertheless it would be nice to have some measure of agreement about which RA we're discussing, and some shorthand to reference it. This original post was specifically about formal definitions for a 9 operator RA (or Extended RA or perhaps ERA-9).

dandl has used SPJRUN often enough, and Erwin has used RBAR enough I can recognise those (and SPJRUN is indeed from Alice). The other sets of letters I didn't recognise. (ERA can stand for rather a lot of things, see wikipedia's disambiguation page; and they've not included all the terms starting Enterprise Resource A.., beloved of ERP vendors.)

@dandl Are you familiar with the usage of new value in Alice?

Yes I am; and I find it a particularly strange term for what they're trying to say; and I'm not at all convinced dandl uses it in the same way as Alice. Irrespective, it's not a term I expect participants here would understand.

In my ERA, every new value is simply provided by the application of a function to its arguments, expressed in the form of a relcon.

Then you're taking a value from a relcon. Then it's not "new" in the sense in Alice. It's very similar to "taking" a value from relcon ADD in Appendix A. Hugh doesn't describe that as new value.

Not so. I use relcon only to help those familiar with App-A, in which it is discussed but not formalised. My preference would be to call it a relfun or relational function. It is specifically a function presented in the guise of a relation resembling App-A and HHT, but in a form that allows it to be formalised. D&D never did that.

Quote from Dave Voorhis on March 10, 2021, 11:13 am

Quote from dandl on March 9, 2021, 11:27 pm

So I was able to create an implementation of the 9 operator ERA (SPJRUN+VAW) natively within C#: fully functional, but unfortunately not immune to runtime type errors without a compiler mod or preprocessor. I think that's a good start, but if you want to drop the RA entirely I have no idea where you would go.

Sorry, I must have missed something. I don't know what "9 operator ERA (SPJRUN+VAW)" means.

I got tired of repeating myself. SPJRUN is Alice's name for the basic Codd's RA named perspective: select,project,join,rename,union,negate. VAW is new value, aggregate,while. SQL/DML does all this, except with limited aggregation.

If you're tired of typing the same thing, create appropriate text and put it in a text file, then paste it as needed.

Overuse of acronyms winds up being effectively a private language. The chances of me remembering that SPJRUN means select, project, join, rename, union, negate is close to nil.

W == while?  Argh.

The possibility of runtime type errors is the sort of "undesirable caveats" I had in mind. Indeed, that's why we implement whole new languages -- to get around precisely those limitations in the popular programming languages.

What's interesting to me is what a programming language -- a general-purpose programming language -- would need to look like to make it (relatively) easy for a programmer to create a D using it.

Easy: C# with a header type, as I've already shown (provided you're willing to give up the dinky generated types and go with generics). Either:

• add a small amount of meta-programming to C#, so that the operations needed can be implemented as compile-time code, or
• add a pre-processor to do the same thing. C++ was created by adding a preprocessor to C, but the emitted code was still pure C. A similar strategy would do the same for C#.

It could possibly be done in C++ and other languages with sufficiently powerful generics/templates, but I don't know them at that level of detail. C++ was not created as a whole new language, and while you may not approve, it's been phenomenally successful at what it does. I'm writing C++ at present, I love/hate it, but this project could never have been written without it.

Maybe Java can do it, but it's not a good base to start from. And if you stick to the full TTM type system, there is no solution. Dead parrot.

Why isn't Java a good base to start from?

We can easily create relational algebra implementations in popular programming languages -- we've all done so in our various Ds (including those using Java) -- but they all have undesirable limitations that precludes their use as a D, such as those you've noted for your C# implementation: it needs code generation, or type checking gets deferred to runtime. (The same applies to Java.)

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.

1. 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.

Quote from dandl on March 11, 2021, 9:43 am

What's interesting to me is what a programming language -- a general-purpose programming language -- would need to look like to make it (relatively) easy for a programmer to create a D using it.

Easy: C# with a header type, as I've already shown (provided you're willing to give up the dinky generated types and go with generics). Either:

• add a small amount of meta-programming to C#, so that the operations needed can be implemented as compile-time code, or
• add a pre-processor to do the same thing. C++ was created by adding a preprocessor to C, but the emitted code was still pure C. A similar strategy would do the same for C#.

It could possibly be done in C++ and other languages with sufficiently powerful generics/templates, but I don't know them at that level of detail. C++ was not created as a whole new language, and while you may not approve, it's been phenomenally successful at what it does. I'm writing C++ at present, I love/hate it, but this project could never have been written without it.

Maybe Java can do it, but it's not a good base to start from. And if you stick to the full TTM type system, there is no solution. Dead parrot.

Why isn't Java a good base to start from?

Because first you have to add things that are already in C#. Java/JVM is fine for the backend, it's just more work up front.

We can easily create relational algebra implementations in popular programming languages -- we've all done so in our various Ds (including those using Java) -- but they all have undesirable limitations that precludes their use as a D, such as those you've noted for your C# implementation: it needs code generation, or type checking gets deferred to runtime. (The same applies to Java.)

I really don't think you understand. It takes a massive amount of effort to create a fully-fledged GP programming language, so starting from scratch is just plain stupid. Objective-C, Go, Rust, C++ and many others were created against a background of known languages to solve a small set of specific problems. To say that C# 'only' needs a small amount of compile-time smarts to fully satisfy the requirements of TTM, including full compile-time type safety, is a major plus, not an admission of failure. It places a full working D within easy reach, instead of at the far end of a lengthy newlang process.

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.

1. 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.

 

Quote from Dave Voorhis on March 11, 2021, 11:40 am

Quote from dandl on March 11, 2021, 9:43 am

What's interesting to me is what a programming language -- a general-purpose programming language -- would need to look like to make it (relatively) easy for a programmer to create a D using it.

Easy: C# with a header type, as I've already shown (provided you're willing to give up the dinky generated types and go with generics). Either:

• add a small amount of meta-programming to C#, so that the operations needed can be implemented as compile-time code, or
• add a pre-processor to do the same thing. C++ was created by adding a preprocessor to C, but the emitted code was still pure C. A similar strategy would do the same for C#.

It could possibly be done in C++ and other languages with sufficiently powerful generics/templates, but I don't know them at that level of detail. C++ was not created as a whole new language, and while you may not approve, it's been phenomenally successful at what it does. I'm writing C++ at present, I love/hate it, but this project could never have been written without it.

Maybe Java can do it, but it's not a good base to start from. And if you stick to the full TTM type system, there is no solution. Dead parrot.

Why isn't Java a good base to start from?

Because first you have to add things that are already in C#.

Like what?

Java/JVM is fine for the backend, it's just more work up front.

We can easily create relational algebra implementations in popular programming languages -- we've all done so in our various Ds (including those using Java) -- but they all have undesirable limitations that precludes their use as a D, such as those you've noted for your C# implementation: it needs code generation, or type checking gets deferred to runtime. (The same applies to Java.)

I really don't think you understand. It takes a massive amount of effort to create a fully-fledged GP programming language, so starting from scratch is just plain stupid. Objective-C, Go, Rust, C++ and many others were created against a background of known languages to solve a small set of specific problems. To say that C# 'only' needs a small amount of compile-time smarts to fully satisfy the requirements of TTM, including full compile-time type safety, is a major plus, not an admission of failure. It places a full working D within easy reach, instead of at the far end of a lengthy newlang process.

I think you don't understand. :-)

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.

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.

1. 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?