A TTM Tuple is not a Record
I'm not entirely sure what point you're making but I probably agree. I am not investigating whether a GP language such as C# makes a really good D, only whether it's reasonably possible.
I would have thought Andl itself would be sufficient proof that it's possible. Presumably, the Andl parser is manipulating constructs in a C# environment in exactly the same way a programmer could natively. Strip off the parser, unplug the TTM non-IM type system and replace it with native C# types and the job's done. No?
I mean, that's essentially what Rel is, except Java instead of C#. Low-level programmatic mechanisms for implementing the relational model plus Java is... It. How else would it be written?
Andl is not C#. Rel is not Java. Each of them (a) requires a programmer to learn a new language (b) obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'.
My 'C# is a D' project is simply to show that you don't need a new language, C# already is a D, you just didn't know it.
A C#/Java-native implementation of the relational model doesn't have to be a transpiler that accepts Tutorial D or SIRA_PRISE or Andl or <insert D here> and emits Java or C# source code. It's entirely reasonable for it to be a standalone relational library for Java or C# that doesn't need any new static definitions (though even those can be dynamically compiled, at least in Java) if it supports something like this:
Then we are in broad agreement. The aim of my 'C# is a D' project is (a) to demonstrate the truth of that statement (b) to devise a style that makes it reasonable to use (c) use static constructs that can in principle by incorporated into a compiler extension. What you provide here probably meets the first but not the second or the third. That's what I'm working on.
Quote from dandl on May 9, 2020, 1:10 amI'm not entirely sure what point you're making but I probably agree. I am not investigating whether a GP language such as C# makes a really good D, only whether it's reasonably possible.
I would have thought Andl itself would be sufficient proof that it's possible. Presumably, the Andl parser is manipulating constructs in a C# environment in exactly the same way a programmer could natively. Strip off the parser, unplug the TTM non-IM type system and replace it with native C# types and the job's done. No?
I mean, that's essentially what Rel is, except Java instead of C#. Low-level programmatic mechanisms for implementing the relational model plus Java is... It. How else would it be written?
Andl is not C#. Rel is not Java. Each of them (a) requires a programmer to learn a new language (b) obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'.
My 'C# is a D' project is simply to show that you don't need a new language, C# already is a D, you just didn't know it.
My point is that it might meet the TTM pre/pro-scriptions, but it isn't a D. What you've shown is that it's possible to achieve the letter of TTM adherence without any of its spirit, and to get any closer to its spirit -- and legitimately meet certain prescriptions like OO Pre 1 -- you have to create a preprocessor or code generator. If you've got a preprocessor or code generator where the input is specified by the programmer, you're requiring a programmer to learn a new language.
I'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
That isn't the case. Using the underlying relational engine is straightforward. The code winds up being somewhat verbose and various safety and sanity checks must occur at run-time prior to evaluation, but that's exactly what you've shown in C#.
I'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
What I means is: when you use C#/Java/C++/JS/etc you get immediate access to a vast infrastructure, built up over 20 years or more by thousands of contributors:
- syntax aware editing, completion, symbol search, incremental compilation, etc
- debugger, logging, reflection, runtime code generation
- libraries for every conceivable purpose: maths, comms, GUI, hardware, etc
- frameworks eg compiler tools, GUI shell, web site
- support tools: docs, SO, NPM/NuGet.
In your toy language you can laboriously expose access to a subset of those things, if you work hard at it, but they will never work 'right', as they would in the native language they import from.
As a challenge, show me the steps you would take to bootstrap Rel: that is, rewrite the whole of Rel, compiler, runtime, database access, GUI workshop, in Rel itself.
Quote from dandl on May 10, 2020, 1:25 amI'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
What I means is: when you use C#/Java/C++/JS/etc you get immediate access to a vast infrastructure, built up over 20 years or more by thousands of contributors:
- syntax aware editing, completion, symbol search, incremental compilation, etc
- debugger, logging, reflection, runtime code generation
- libraries for every conceivable purpose: maths, comms, GUI, hardware, etc
- frameworks eg compiler tools, GUI shell, web site
- support tools: docs, SO, NPM/NuGet.
In your toy language you can laboriously expose access to a subset of those things, if you work hard at it, but they will never work 'right', as they would in the native language they import from.
As a challenge, show me the steps you would take to bootstrap Rel: that is, rewrite the whole of Rel, compiler, runtime, database access, GUI workshop, in Rel itself.
I wouldn't, any more than I'd bootstrap SQL in SQL.
I think you misunderstood my point, or maybe I misunderstood yours. You wrote "[Rel] obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'."
It was in the context of discussing relational libraries in general purpose languages like C# or Java, so I thought you were referring to standalone use of the relational engine, written in Java, that underpins Rel.
Trying to use Rel as a substitute for C# or Java would indeed require creating -- or at least modifying -- a sizeable stack, and there'd be no reason to do so.
But using Rel's core relational engine from within Java is straightforward, and notionally very similar to what you've just created for C# right down to the limitations imposed by the capabilities of the host language. It's almost certainly notionally similar to equivalent libraries that must underpin SIRA_PRISE, Alf, DuroDBMS, RAQUEL, Alphora D4, and of course Andl.
I mean, you do have a relational library underpinning Andl, yes?
My point in general is that what you've created as a relational library for C# is essentially the same kind of internal library that every implementer has at the core of their D.
No?
Quote from Dave Voorhis on May 10, 2020, 9:39 amQuote from dandl on May 10, 2020, 1:25 amI'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
What I means is: when you use C#/Java/C++/JS/etc you get immediate access to a vast infrastructure, built up over 20 years or more by thousands of contributors:
- syntax aware editing, completion, symbol search, incremental compilation, etc
- debugger, logging, reflection, runtime code generation
- libraries for every conceivable purpose: maths, comms, GUI, hardware, etc
- frameworks eg compiler tools, GUI shell, web site
- support tools: docs, SO, NPM/NuGet.
In your toy language you can laboriously expose access to a subset of those things, if you work hard at it, but they will never work 'right', as they would in the native language they import from.
As a challenge, show me the steps you would take to bootstrap Rel: that is, rewrite the whole of Rel, compiler, runtime, database access, GUI workshop, in Rel itself.
I wouldn't, any more than I'd bootstrap SQL in SQL.
I think you misunderstood my point, or maybe I misunderstood yours. You wrote "[Rel] obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'."
It was in the context of discussing relational libraries in general purpose languages like C# or Java, so I thought you were referring to standalone use of the relational engine, written in Java, that underpins Rel.
No, it was in the context of devising a new language to completely fulfil TTM, and not just as a 'data sub-language'.
Trying to use Rel as a substitute for C# or Java would indeed require creating -- or at least modifying -- a sizeable stack, and there'd be no reason to do so.
Which means it is and will forever be a 'data sub-language'.
But using Rel's core relational engine from within Java is straightforward, and notionally very similar to what you've just created for C# right down to the limitations imposed by the capabilities of the host language. It's almost certainly notionally similar to equivalent libraries that must underpin SIRA_PRISE, Alf, DuroDBMS, RAQUEL, Alphora D4, and of course Andl.
I mean, you do have a relational library underpinning Andl, yes?
My point in general is that what you've created as a relational library for C# is essentially the same kind of internal library that every implementer has at the core of their D.
Of course. The RA library is a very modest amount of code, easily done. No, I was responding to the idea that the way to satisfy TTM is to create a new D language from scratch, and pointing out the vast gap between what a new language can hope to offer versus what language users have come to expect.
I say that the way to read TTM is as a kind of gap analysis. Pick your best GP language, work through TTM and figure out what's missing and how to fill the gap. Forget toy languages, start with industrial strength and build on that.
Turns out the gap is small and just a few small additions are all it will take. So that's the thing to focus on.
Quote from dandl on May 11, 2020, 11:20 amQuote from Dave Voorhis on May 10, 2020, 9:39 amQuote from dandl on May 10, 2020, 1:25 amI'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
What I means is: when you use C#/Java/C++/JS/etc you get immediate access to a vast infrastructure, built up over 20 years or more by thousands of contributors:
- syntax aware editing, completion, symbol search, incremental compilation, etc
- debugger, logging, reflection, runtime code generation
- libraries for every conceivable purpose: maths, comms, GUI, hardware, etc
- frameworks eg compiler tools, GUI shell, web site
- support tools: docs, SO, NPM/NuGet.
In your toy language you can laboriously expose access to a subset of those things, if you work hard at it, but they will never work 'right', as they would in the native language they import from.
As a challenge, show me the steps you would take to bootstrap Rel: that is, rewrite the whole of Rel, compiler, runtime, database access, GUI workshop, in Rel itself.
I wouldn't, any more than I'd bootstrap SQL in SQL.
I think you misunderstood my point, or maybe I misunderstood yours. You wrote "[Rel] obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'."
It was in the context of discussing relational libraries in general purpose languages like C# or Java, so I thought you were referring to standalone use of the relational engine, written in Java, that underpins Rel.
No, it was in the context of devising a new language to completely fulfil TTM, and not just as a 'data sub-language'.
Trying to use Rel as a substitute for C# or Java would indeed require creating -- or at least modifying -- a sizeable stack, and there'd be no reason to do so.
Which means it is and will forever be a 'data sub-language'.
A 'sub-language' typically means a language invoked from within a another language, like SQL or regexps or even HTML/CSS.
Rel can be used that way -- and I have used it that way -- but it's also standalone, which puts it in the same category (along with all the other D language implementations, to my knowledge) of being yet another language like Perl and Ruby and Python and Scala and Kotlin and Groovy and you-name-it.
There are many valid reasons for having yet another language, and whilst one might imagine the inclination to create yet another language would have ended long ago in favour of using one of the established general-purpose languages, that doesn't seem to be the case. There are numerous DSLs and special-purpose and even general-purpose languages still being created and used, and probably always will be. They have their place.
But using Rel's core relational engine from within Java is straightforward, and notionally very similar to what you've just created for C# right down to the limitations imposed by the capabilities of the host language. It's almost certainly notionally similar to equivalent libraries that must underpin SIRA_PRISE, Alf, DuroDBMS, RAQUEL, Alphora D4, and of course Andl.
I mean, you do have a relational library underpinning Andl, yes?
My point in general is that what you've created as a relational library for C# is essentially the same kind of internal library that every implementer has at the core of their D.
Of course. The RA library is a very modest amount of code, easily done. No, I was responding to the idea that the way to satisfy TTM is to create a new D language from scratch, and pointing out the vast gap between what a new language can hope to offer versus what language users have come to expect.
I say that the way to read TTM is as a kind of gap analysis. Pick your best GP language, work through TTM and figure out what's missing and how to fill the gap. Forget toy languages, start with industrial strength and build on that.
Turns out the gap is small and just a few small additions are all it will take. So that's the thing to focus on.
As usual, I think we'll each focus on the things we like to focus on. I'm all for implementing D or D-like libraries for GP languages (I am, after all, creating one now, though I've chosen a different set of tradeoffs from yours) but I'm also all for creating entirely new D languages. One of the great strengths of TTM is that it didn't define a single language but a language family. Therefore, the more we expand that family by creating various D implementations to target as many purposes and domains and approaches and niches as we can, the better.
Quote from Dave Voorhis on May 11, 2020, 11:53 amQuote from dandl on May 11, 2020, 11:20 amQuote from Dave Voorhis on May 10, 2020, 9:39 amQuote from dandl on May 10, 2020, 1:25 amI'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
What I means is: when you use C#/Java/C++/JS/etc you get immediate access to a vast infrastructure, built up over 20 years or more by thousands of contributors:
- syntax aware editing, completion, symbol search, incremental compilation, etc
- debugger, logging, reflection, runtime code generation
- libraries for every conceivable purpose: maths, comms, GUI, hardware, etc
- frameworks eg compiler tools, GUI shell, web site
- support tools: docs, SO, NPM/NuGet.
In your toy language you can laboriously expose access to a subset of those things, if you work hard at it, but they will never work 'right', as they would in the native language they import from.
As a challenge, show me the steps you would take to bootstrap Rel: that is, rewrite the whole of Rel, compiler, runtime, database access, GUI workshop, in Rel itself.
I wouldn't, any more than I'd bootstrap SQL in SQL.
I think you misunderstood my point, or maybe I misunderstood yours. You wrote "[Rel] obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'."
It was in the context of discussing relational libraries in general purpose languages like C# or Java, so I thought you were referring to standalone use of the relational engine, written in Java, that underpins Rel.
No, it was in the context of devising a new language to completely fulfil TTM, and not just as a 'data sub-language'.
Trying to use Rel as a substitute for C# or Java would indeed require creating -- or at least modifying -- a sizeable stack, and there'd be no reason to do so.
Which means it is and will forever be a 'data sub-language'.
A 'sub-language' typically means a language invoked from within a another language, like SQL or regexps or even HTML/CSS.
Rel can be used that way -- and I have used it that way -- but it's also standalone, which puts it in the same category (along with all the other D language implementations, to my knowledge) of being yet another language like Perl and Ruby and Python and Scala and Kotlin and Groovy and you-name-it.
Just so. Since there is no prospect of building it up to the standard of those others (which have the kind of infrastructure I describe) it can only ever be one of two things: a full stack language for teaching or toy applications; or a data sub-language for bigger things. My 'C# as D' provides a full stack language that is TTM compliant. You don't need SQL at all.
There are many valid reasons for having yet another language, and whilst one might imagine the inclination to create yet another language would have ended long ago in favour of using one of the established general-purpose languages, that doesn't seem to be the case. There are numerous DSLs and special-purpose and even general-purpose languages still being created and used, and probably always will be. They have their place.
Absolutely, and I'm a big fan. But if you want a DSL for the RA (instead of SQL), then TTM is not the way to go about it.
But using Rel's core relational engine from within Java is straightforward, and notionally very similar to what you've just created for C# right down to the limitations imposed by the capabilities of the host language. It's almost certainly notionally similar to equivalent libraries that must underpin SIRA_PRISE, Alf, DuroDBMS, RAQUEL, Alphora D4, and of course Andl.
I mean, you do have a relational library underpinning Andl, yes?
My point in general is that what you've created as a relational library for C# is essentially the same kind of internal library that every implementer has at the core of their D.
Of course. The RA library is a very modest amount of code, easily done. No, I was responding to the idea that the way to satisfy TTM is to create a new D language from scratch, and pointing out the vast gap between what a new language can hope to offer versus what language users have come to expect.
I say that the way to read TTM is as a kind of gap analysis. Pick your best GP language, work through TTM and figure out what's missing and how to fill the gap. Forget toy languages, start with industrial strength and build on that.
Turns out the gap is small and just a few small additions are all it will take. So that's the thing to focus on.
As usual, I think we'll each focus on the things we like to focus on. I'm all for implementing D or D-like libraries for GP languages (I am, after all, creating one now, though I've chosen a different set of tradeoffs from yours) but I'm also all for creating entirely new D languages. One of the great strengths of TTM is that it didn't define a single language but a language family. Therefore, the more we expand that family by creating various D implementations to target as many purposes and domains and approaches and niches as we can, the better.
IMO targeting a TTM/D as a full stack language now makes no sense. Either add a TTM type system to a GP language, or stick with having a DSL. If you want a DSL, TTM is not the right model.
Quote from dandl on May 12, 2020, 3:01 amQuote from Dave Voorhis on May 11, 2020, 11:53 amQuote from dandl on May 11, 2020, 11:20 amQuote from Dave Voorhis on May 10, 2020, 9:39 amQuote from dandl on May 10, 2020, 1:25 amI'm not sure what you mean by Rel "obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'".
What I means is: when you use C#/Java/C++/JS/etc you get immediate access to a vast infrastructure, built up over 20 years or more by thousands of contributors:
- syntax aware editing, completion, symbol search, incremental compilation, etc
- debugger, logging, reflection, runtime code generation
- libraries for every conceivable purpose: maths, comms, GUI, hardware, etc
- frameworks eg compiler tools, GUI shell, web site
- support tools: docs, SO, NPM/NuGet.
In your toy language you can laboriously expose access to a subset of those things, if you work hard at it, but they will never work 'right', as they would in the native language they import from.
As a challenge, show me the steps you would take to bootstrap Rel: that is, rewrite the whole of Rel, compiler, runtime, database access, GUI workshop, in Rel itself.
I wouldn't, any more than I'd bootstrap SQL in SQL.
I think you misunderstood my point, or maybe I misunderstood yours. You wrote "[Rel] obligates an implementer to grant access to a vast set of libraries in the underlying infrastructure by mechanisms that are never going to work 'right'."
It was in the context of discussing relational libraries in general purpose languages like C# or Java, so I thought you were referring to standalone use of the relational engine, written in Java, that underpins Rel.
No, it was in the context of devising a new language to completely fulfil TTM, and not just as a 'data sub-language'.
Trying to use Rel as a substitute for C# or Java would indeed require creating -- or at least modifying -- a sizeable stack, and there'd be no reason to do so.
Which means it is and will forever be a 'data sub-language'.
A 'sub-language' typically means a language invoked from within a another language, like SQL or regexps or even HTML/CSS.
Rel can be used that way -- and I have used it that way -- but it's also standalone, which puts it in the same category (along with all the other D language implementations, to my knowledge) of being yet another language like Perl and Ruby and Python and Scala and Kotlin and Groovy and you-name-it.
Just so. Since there is no prospect of building it up to the standard of those others (which have the kind of infrastructure I describe) it can only ever be one of two things: a full stack language for teaching or toy applications; or a data sub-language for bigger things. My 'C# as D' provides a full stack language that is TTM compliant. You don't need SQL at all.
I suppose if you don't need transactional, cross-language, concurrent-access storage, then you don't need SQL. But if you're using C# or Java, you don't need the relational algebra either. You only "need" -- to the extent that you need any data processing API -- .NET LINQ or Java Streams.
There are many valid reasons for having yet another language, and whilst one might imagine the inclination to create yet another language would have ended long ago in favour of using one of the established general-purpose languages, that doesn't seem to be the case. There are numerous DSLs and special-purpose and even general-purpose languages still being created and used, and probably always will be. They have their place.
Absolutely, and I'm a big fan. But if you want a DSL for the RA (instead of SQL), then TTM is not the way to go about it.
[...]
IMO targeting a TTM/D as a full stack language now makes no sense. Either add a TTM type system to a GP language, or stick with having a DSL. If you want a DSL, TTM is not the right model.
Why not?
Dan Muller's CsiDb (mentioned under Projects on thethirdmanfesto.com) is a DSL for bookkeeping/accounting based on TTM.
IMO targeting a TTM/D as a full stack language now makes no sense. Either add a TTM type system to a GP language, or stick with having a DSL. If you want a DSL, TTM is not the right model.
Why not?
Because a TTM compliant D is not a DSL. And a DSL will find TTM a useful source of ideas, but lacking in important respects.
Dan Muller's CsiDb (mentioned under Projects on thethirdmanfesto.com) is a DSL for bookkeeping/accounting based on TTM.
Which is consistent with my point.