Quote from dandl on December 8, 2021, 12:59 pm

Quote from Paul Vernon on December 8, 2021, 9:42 am

Quote from dandl on December 8, 2021, 4:50 am

This is precisely the goal I set out in "higher, shorter, safer". The design of languages such that "if it compiles it runs". No exceptions, no runtime errors, no infinite loops.

With the kind of (non) type system I have in mind. I would say that "if it syntactically parses it runs".  It is even curious to consider going further any saying that "everything parses", but that's a different thought.

It's not enough. The experience I have now is that I find it trivially easy (although time consuming) to write correct code, which then fails because of things I didn't know and that are outside my control. By 'runs' I means runs to completion and carries out the task it was correctly programmed to do. I want programming languages that take over more of the burden of finding and protecting against these errors.

Eiffel gives some idea of what can be done, but the field is wide open.

Curious how you'll determine "never return in your lifetime", or generally determine "return empty" for arbitrary code, given it's the Halting Problem.

No so. This is a language design problem such that those programs cannot be written. Every loop or recursive call to be provably terminating. Very different problem.

The problem with lack of computational completeness is that you then have to bifurcate your world into the "safe but limited" world of data (access), and the "unsafe but unlimited" world of programming.

To keep things as simple as possible, you would want one world (unless that is provably too simple).

As you said in your next post (my bold)

Please note: it's not Turing Complete (all queries are safe), and it can do most everything in SQL but not ordered queries.

I'm afraid that is not good enough

These are two separate topics: 'higher, shorter, safer' in a GP programming language and 'guaranteed safe' in a query language.

(P.S. by ordered queries, do you mean what D&D call "Quota Queries"?)

No, far more than that. Both SQL 92 and Tutorial D support roughly the same set of operators:

• SPJRUN much like Codd plus eXtend and partial support for Aggregation (many statistical functions cannot be expressed as queries).
• TD can execute queries with the results sorted by the artifice of ARRAY, but SQL does it more naturally.

But:

• SQL has TOP, FIRST, etc which align with TTM quota queries (not implemented in TD).
• SQL has CTE RECURSIVE, which aligns with TTM  Generalised Transitive Closure (also not implemented).
• SQL Window functions can do things banned from TTM including running sums, ranking, delta/lead/lag, trends, time series, median, string building and so on.

I have formal definition for all these except the last; Andl can do them all.

Quote from Dave Voorhis on December 8, 2021, 1:41 pm

Quote from Paul Vernon on December 8, 2021, 12:39 pm

Quote from Dave Voorhis on December 8, 2021, 9:42 am

Quote from dandl on December 8, 2021, 3:05 am

He didn't say "implements", he said "looks like (as far as you can get)" and no, there are no 'opaque' scalar values. This is a language of relations, it's relations all the way down, the expressions are written in a familiar style, and it will perform just fine. Indeed, given the right kind of lower level support taking advantage of parallelism it could easily out-perform 'the usual fashion'.

I think Paul confirmed my interpretation of his post in a subsequent post above.

'Opaque' means 'without type information', again appropriate to the context of the original discussion.

I was speaking of a single scalar expression, e.g., v := p + q, not a vectorisation of some relational operator like EXTEND r {v := p + q} or whatever, though even there I would presume any notional JOIN is optimised away.

To be clear(ish), this is (partly) all about the old "treating operators as relations" discussions. I recall Hugh saying something along the lines of him "always liking the idea, but never being able to find a reasonable syntax to make it work in an actual language". (I can't find the actual quote just now).  So yes relations all the way down until you come to implementation matters (where vectorised highly parallel machine operations could indeed be used where the input relations (but not the functional relations - in all "special cases" such as + , / anyway)  have many values)  , and with a syntax that is as familiar as possible but still allowing things like empty result/no tuple for "invalid" operations/function input

Well, that is the thing -- if the syntax looks like conventional scalar expressions and it's acting on conventional scalar values, then it probably doesn't make sense to implement it via relations.

But if the syntax looks like conventional scalar expressions and it's acting on relations, that's something else -- maybe -- but I immediately think of more questions, so best I defer further them until I see your language's syntax and semantics, which will likely answer them and more.

I will note one thing also. I would not have v := p + qbecause I would not have variables. A variable - the database - yes, but not others. (Pure) functional programming languages have no variables-as-storage-locations, why do we think we need them?

Same reason pure functional programming languages have variables-as-names: to provide expressive syntactic convenience and avoid repetition.

(and, to be fair D&D do admit the possibility of a functional D - but then again relvars are quite important to TTM).

So might have p + qbut then also infix is a pain, so it might be (at best?)  + p q

Lisp fans will approve, I'm sure.

Depends on your target market, perhaps?

Quote from Paul Vernon on December 8, 2021, 1:51 pm

Quote from dandl on December 8, 2021, 12:59 pm

These are two separate topics: 'higher, shorter, safer' in a GP programming language and 'guaranteed safe' in a query language.

Maybe separate topics, but no reason why you can't have both in one language. At compile time the qualities of each given statement/expression/subexpression can noted, with things such as  'guaranteed safe', a certain cost (estimate/range), guaranteed to met assertions/constraints, etc, etc  and if no such qualities can be determined, it would be considered "unproven"/unsafe. From such data users/programmers/AI/etc. can decide how/if to proceed.

 

Quote from Paul Vernon on December 8, 2021, 2:01 pm

Quote from Dave Voorhis on December 8, 2021, 1:41 pm

I will note one thing also. I would not have v := p + qbecause I would not have variables. A variable - the database - yes, but not others. (Pure) functional programming languages have no variables-as-storage-locations, why do we think we need them?

Same reason pure functional programming languages have variables-as-names: to provide expressive syntactic convenience and avoid repetition.

OK. Thank you. Indeed the WITH construct (of both SQL and Tutorial D)  for introducing local names is one that a little troublesome for me...

Quote from Dave Voorhis on December 8, 2021, 2:06 pm

Quote from Paul Vernon on December 8, 2021, 2:01 pm

Quote from Dave Voorhis on December 8, 2021, 1:41 pm

I will note one thing also. I would not have v := p + qbecause I would not have variables. A variable - the database - yes, but not others. (Pure) functional programming languages have no variables-as-storage-locations, why do we think we need them?

Same reason pure functional programming languages have variables-as-names: to provide expressive syntactic convenience and avoid repetition.

OK. Thank you. Indeed the WITH construct (of both SQL and Tutorial D)  for introducing local names is one that a little troublesome for me...

SQL 'WITH' is restricted and varies in semantics across different SQL dialects/implementations, like most of SQL. (See https://modern-sql.com/feature/with)

But I'm a big fan of WITH in Tutorial D / Rel. I frequently use it.

Quote from Paul Vernon on December 8, 2021, 5:54 pm

Quote from Dave Voorhis on December 8, 2021, 2:06 pm

SQL 'WITH' is restricted and varies in semantics across different SQL dialects/implementations, like most of SQL. (See https://modern-sql.com/feature/with)

But I'm a big fan of WITH in Tutorial D / Rel. I frequently use it.

As an aside about WITH's, I generally prefer not to use them unless I do need to use the same sub-expression in two or more places in a SQL query. It's as much a personal preference as anything I think, but I'm happy with simple nesting even for large sub-expressions. That does mean I somewhat dislike the style of using WITH just to write a statement "inside-out" as it were. Which includes some/many of D&D's examples. So, e.g. I prefer

C FROM (
  TUPLE FROM (
    PLUS JOIN RELATION { TUPLE { A 2 , B 3 } }
  )
)

over

WITH ( T1 := PLUS JOIN RELATION { TUPLE { A 2 , B 3 } } ,
       T2 := TUPLE FROM T1 ) :
C FROM T2

C FROM (
  TUPLE FROM (
    PLUS JOIN RELATION { TUPLE { A 2 , B 3 } }
  )
)

WITH ( T1 := PLUS JOIN RELATION { TUPLE { A 2 , B 3 } } ,
       T2 := TUPLE FROM T1 ) :
C FROM T2

Quote from Dave Voorhis on December 8, 2021, 6:12 pm

Quote from Paul Vernon on December 8, 2021, 5:54 pm

Quote from Dave Voorhis on December 8, 2021, 2:06 pm

SQL 'WITH' is restricted and varies in semantics across different SQL dialects/implementations, like most of SQL. (See https://modern-sql.com/feature/with)

But I'm a big fan of WITH in Tutorial D / Rel. I frequently use it.

As an aside about WITH's, I generally prefer not to use them unless I do need to use the same sub-expression in two or more places in a SQL query. It's as much a personal preference as anything I think, but I'm happy with simple nesting even for large sub-expressions.

Yes. Larger expressions I make readable with suitable formatting rather than using WITH. WITH is for re-use of subexpressions.

Quote from dandl on December 8, 2021, 11:07 pm

I was speaking of a single scalar expression, e.g., v := p + q, not a vectorisation of some relational operator like EXTEND r {v := p + q} or whatever, though even there I would presume any notional JOIN is optimised away.

To be clear(ish), this is (partly) all about the old "treating operators as relations" discussions. I recall Hugh saying something along the lines of him "always liking the idea, but never being able to find a reasonable syntax to make it work in an actual language". (I can't find the actual quote just now).  So yes relations all the way down until you come to implementation matters (where vectorised highly parallel machine operations could indeed be used where the input relations (but not the functional relations - in all "special cases" such as + , / anyway)  have many values)  , and with a syntax that is as familiar as possible but still allowing things like empty result/no tuple for "invalid" operations/function input

At the risk of repeating myself, the language definition targets abstract translation and execution machines, which are built up from available hardware and software components. The implementation is invisible to the language.

The language I describe is trivial syntactically: just the 9 operators, relational values (including literals and relcons) and relational variables (depending on your language style prefs).

I will note one thing also. I would not have v := p + qbecause I would not have variables. A variable - the database - yes, but not others. (Pure) functional programming languages have no variables-as-storage-locations, why do we think we need them?  (and, to be fair D&D do admit the possibility of a functional D - but then again relvars are quite important to TTM).

So might have p + qbut then also infix is a pain, so it might be (at best?)  + p q

TTM describes a language that has a mixture of styles: an outer jacket of GP language, an embedded query language, and an inner expression language for select (WHERE) and extend. I wrote Andl in the same style. The ERA language I describe is a single style, similar to the query language. There is no 'v:=p+q'. There are no 'free' scalars.

Quote from dandl on December 8, 2021, 11:43 pm

Quote from Paul Vernon on December 8, 2021, 1:51 pm

Quote from dandl on December 8, 2021, 12:59 pm

These are two separate topics: 'higher, shorter, safer' in a GP programming language and 'guaranteed safe' in a query language.

Maybe separate topics, but no reason why you can't have both in one language. At compile time the qualities of each given statement/expression/subexpression can noted, with things such as  'guaranteed safe', a certain cost (estimate/range), guaranteed to met assertions/constraints, etc, etc  and if no such qualities can be determined, it would be considered "unproven"/unsafe. From such data users/programmers/AI/etc. can decide how/if to proceed.

My ERA language proposal can be made Turing Complete simply by adding full recursion or generator relcons, with or without loop invariant safeguards, but that doesn't make it a GP language.

A typical GP language has multiple points of failure and there is no prospect of an easy fix. Safer means a complete language redesign, with languages like Eiffel and Erlang as just a starting point. I don't see value in combining the two.

For some interesting thoughts on the topic see: https://cs.stackexchange.com/questions/93798/what-is-a-safe-programming-language.