Quote from dandl on June 17, 2019, 1:47 pm

Quote from Dave Voorhis on June 17, 2019, 11:18 am

Ensuring that "every value can be produced by every selector" is technically unenforceable; it can only be satisfied by design. Even a comprehensive unit test suite, to be truly comprehensive, might not show a green bar until well after the heat death of the universe.

I'm pretty sure POSSREPs in Rel work as they should (modulo known bugs and limitations), but there is no way to guarantee -- in any automated fashion -- that every user-defined type guarantees that every value can be produced by every selector.

That's what I intended. I read RM Pre 4 as requiring this to be so by design (at least for UDTs). There are various strategies that I'm sure you know for testing edge cases and sampling, none of which can guarantee correctness if it wasn't (or couldn't be) designed in.

As a case in point, the language product I wrote and maintain has its own decimal arithmetic. After thousands of test case executions, millions of lines of user land code, and the passage of more than 10 bug-free years someone tried to divide some Turkish currency values with 14 digits, and found a bug in division that more or less mirrored the famed Pentium bug. Gotcha!

Every software product has bugs. Some of them you know about.

Quote from AntC on June 17, 2019, 2:11 pm

Quote from johnwcowan on June 17, 2019, 12:13 pm

Quote from Dave Voorhis on June 17, 2019, 9:22 am

I think there is over-emphasis here on the significance of references/pointers in object oriented programming languages,

I think part of the problem is that TTM, like older programming languages, conflates under the name variable the logically distinguishable notions of names and what Scheme calls locations.

"like older programming languages" sounds like an insult. If you're suggesting that somehow OOP is modern and therefore better, I could perhaps remind you the first OOP languages and their semantics date from the 1960's. What specific languages are you talking about? And why do you think the age of a language has anything to do with its semantics?

I think TTM is following the thoroughly modern idea that within the language itself, the semantics are that variables denote values. That's why TTM distinguishes the physical representation (which might have some boxes/locations vs contents structure); distinguishes in order to make clear TTM is only talking about possible representation within the language.

The former are the identifiers that can be used in the language to refer to something; the latter are the boxes that can hold different things at different times.

It's been a useful discipline for me (coming from an imperative/destructive assignment paradigm) to program in Haskell. Haskell variables do not "hold different things at different times", they denote (the value of) some expression/referential transparency. Much more like algebra.

Note that locations aren't necessarily storage locations, and some values may have storage addresses, unique or not: this is a concept of the model, not of the implementation.

A variable, then, is in these terms the name of a location,

No: that is exactly the confusion/implementation concern that TTM wants to avoid, by talking only about possrep. You have just been too brainwashed by OOP.

and there are two things that can potentially vary; the binding of the name to the location, and the contents of the location.  In D as defined by TTM, every name corresponds to a location and vice versa, and the binding of the name cannot be changed.  (Chapter 5 mentions the idea of values being named, but that is not part of D.)

You're talking about a possible implementation/a physical representation. Stop.

Also BTW this name-binding-to-a-location idea breaks down with recursive functions/procedures. All we need to say is that a variable is bound to a value. (And with recursive invocations, there are multiple variables referred to by the same name in different scopes.)

Given this, we can say clearly what an (OO) object is: it is a first-class (and so potentially anonymous) thing containing zero or more locations as well as zero or more values.  Values can be identified with the subset of objects that contain no locations.  Note that this completely abstracts away from all talk of pointers.

Well if it wasn't clear from previous discussion; it's not pointers as such that TTM is avoiding. It's avoiding the idea that within the language you can distinguish the location from its (current) content or ask to compare two names to see if they reference the same location. All you can ask is if two names denote the same value.

OOP further bundles methods inside the object; and actually requires that you access the value only by invoking some method (even if the method is a trivial read).

TTM wants something far simpler to understand. You're just bamboozling yourself. Nothing in TTM corresponds to an OO object: not variables; not values of variables (not so-called immutable objects); not tuples or relations. And I think to say something in TTM is "isomorphic" to something in OO is just exacerbating the confusion.

Quote from Dave Voorhis on June 17, 2019, 2:29 pm

Quote from AntC on June 17, 2019, 2:11 pm

...

And I think to say something in TTM is "isomorphic" to something in OO is just exacerbating the confusion.

Object-oriented (immutable value) objects + static factory methods (or constructors) are isomorphic to TTM multiple possreps to the extent that I described and no more. I have intentionally not said they're the same thing, because they're not.

However, programming-wise, a given developer implementing a given application in two languages -- a D with multiple possreps, and a conventional object-oriented language -- will almost certainly use multiple possreps or multiple constructors (or static factory methods) equivalently to accomplish the same end.

Quote from johnwcowan on June 17, 2019, 3:52 pm

Quote from AntC on June 17, 2019, 2:11 pm

"like older programming languages" sounds like an insult.

No insult intended — I enjoy, use, and sometimes implement languages of all ages from the 1950s to the 2010s.

And why do you think the age of a language has anything to do with its semantics?

I don't, of course.

I think TTM is following the thoroughly modern idea that within the language itself, the semantics are that variables denote values.

Cobol had this "modern" property from 1959 to 2002.  (While I'm at it, the first pure functional programming language was apparently PAL-R, published by A. Evans in 1968.  Its only imperative operation was Print.)

It's been a useful discipline for me (coming from an imperative/destructive assignment paradigm) to program in Haskell. Haskell variables do not "hold different things at different times", they denote (the value of) some expression/referential transparency.

Correct: there are no locations at all in Haskell.  This is very different from Fortran, Cobol, and Basic (to pick three older languages), which bind names immutably to locations (in the case of arrays, collections of locations).  The name/location/value is intended to be a general one handling all programming languages, though not all languages require its full generality.

You have just been too brainwashed by OOP.

"That turns out not to be the case."  The model comes from the 1986 Scheme standard (section 3.1), which was not at all affected by what is now called OOP (though OOP goes back a long way in Lisp).  The previous 1984 standard had the confusion: it said that variables were first-class.  There are languages like Common Lisp in which names are first-class, but Scheme isn't one of them: what's first-class is locations.

Haskell variables do not "hold different things at different times", they denote (the value of) some expression [...] All we need to say is that [in D] a variable is bound to a value.

The point of the model is to expose and clarify the ambiguity of "a variable is bound to a value".  In Haskell, a name is bound to a value unchangeably; in D, a name is bound to a location unchangeably, but the location can be changed (which is the point of locations).

OOP further bundles methods inside the object; and actually requires that you access the value only by invoking some method (even if the method is a trivial read).

There are OOP versions that don't, especially those involving multi-methods like CLOS.  In the mainstream of OOP you are of course correct.

TTM wants something far simpler to understand. You're just bamboozling yourself. Nothing in TTM corresponds to an OO object: not variables; not values of variables (not so-called immutable objects); not tuples or relations. And I think to say something in TTM is "isomorphic" to something in OO is just exacerbating the confusion.

For several posts now you have been responding to me like someone whose religion is under attack.  I'm sorry to have pushed your buttons so hard.  "A man convinced against his will is of the same opinion still," so I'm going to just, as you have said repeatedly, stop.

Quote from dandl on June 18, 2019, 12:15 am

Quote from Dave Voorhis on June 17, 2019, 2:29 pm

Quote from AntC on June 17, 2019, 2:11 pm

...

And I think to say something in TTM is "isomorphic" to something in OO is just exacerbating the confusion.

Object-oriented (immutable value) objects + static factory methods (or constructors) are isomorphic to TTM multiple possreps to the extent that I described and no more. I have intentionally not said they're the same thing, because they're not.

However, programming-wise, a given developer implementing a given application in two languages -- a D with multiple possreps, and a conventional object-oriented language -- will almost certainly use multiple possreps or multiple constructors (or static factory methods) equivalently to accomplish the same end.

And this is precisely the point I disagree with. And since I would have thought you know better, I'm interested in why you say this.

Yes, it is more or less possible to fake value types in an OO language, even in Java. You can use static to create a singleton, implement all the equals and hash code functions and block internal meddling with private, but almost no-one ever does. Most OO programmers explicitly think of terms of little packets of state and the methods used to manipulate that state. They routinely pass object references as arguments to functions knowing that the method will mutate its inputs as well as provide an explicit output. There is a whole discipline about query-command separation.

None of that happens in FP languages and value types. Values are just values, no matter how complex. If you want to mutate state expressed as a complex value, you have to provide some other kind of bundling principle. Yes, you can have a function that takes a value as an argument and produces another value of the same type as its result, but there are a lot of steps between that single function and "accomplishing the same end" with an OO class and a rich set of attached mutators.

Quote from johnwcowan on June 18, 2019, 12:34 am

Quote from dandl on June 18, 2019, 12:15 am

Yes, it is more or less possible to fake value types in an OO language, even in Java. You can use static to create a singleton, implement all the equals and hash code functions and block internal meddling with private, but almost no-one ever does. Most OO programmers explicitly think of terms of little packets of state and the methods used to manipulate that state. They routinely pass object references as arguments to functions knowing that the method will mutate its inputs as well as provide an explicit output. There is a whole discipline about query-command separation.

Most code is written in the currently fashionable paradigm, whatever it is, and most of it is bad.  Programmers massively misuse OO styles where they don't apply, follow pointless rituals, and generally produce an unmaintainable mess.  "Real programmers can write Fortran in any language."  (Good Fortran is a thing of beauty.)

If Haskell, or dumbed-down Haskell, becomes the new hotness, we will see programmers writing their entire programs in the IO monad, and whole libraries of unsafeThisAndThat with which to get "real work" done

Quote from AntC on June 18, 2019, 2:04 am

Quote from johnwcowan on June 17, 2019, 3:52 pm

Quote from AntC on June 17, 2019, 2:11 pm

"like older programming languages" sounds like an insult.

No insult intended — I enjoy, use, and sometimes implement languages of all ages from the 1950s to the 2010s.

I think TTM is following the thoroughly modern idea that within the language itself, the semantics are that variables denote values.

Cobol had this "modern" property from 1959 to 2002.  (While I'm at it, the first pure functional programming language was apparently PAL-R, published by A. Evans in 1968.  Its only imperative operation was Print.)

OOP further bundles methods inside the object; and actually requires that you access the value only by invoking some method (even if the method is a trivial read).

There are OOP versions that don't, especially those involving multi-methods like CLOS.  In the mainstream of OOP you are of course correct.

TTM wants something far simpler to understand. You're just bamboozling yourself. Nothing in TTM corresponds to an OO object: not variables; not values of variables (not so-called immutable objects); not tuples or relations. And I think to say something in TTM is "isomorphic" to something in OO is just exacerbating the confusion.

For several posts now you have been responding to me like someone whose religion is under attack.  I'm sorry to have pushed your buttons so hard.  "A man convinced against his will is of the same opinion still," so I'm going to just, as you have said repeatedly, stop.

I think I'm in good company with this visceral reaction against trying to see 'objects everywhere'. D&D's manifesto is the "third" as a reaction against the first two, which made a load of complaints against the 'Relational Model' (they meant against SQL, which should certainly be complained about, but the only so-called complaints specifically about the RM amounted to 'it's not objects'). The final trigger for HD was a series of proposals at the SQL Standards committee to introduce objects there, which would have introduced yet more non-orthogonal features and semantics into an already-bloated, creaking monstrosity. There was no justification except 'we must have objects, because everybody does'.

A second source of frustration with OO/ORM is the complexity and brittleness it produces in database-centric applications. I spend a lot of professional time rescuing projects that have encapsulated business logic inside methods/objects that are at the wrong point in the business process. I have seldom seen the alleged benefit that OOP is write-once, use anywhere. It's much more write-once, copy-and-amend umpteen times, worry about coherence after release (if ever). This in recent decades has been compounded by Agile approaches/get the code in front of the users ASAP/worry about software architecture after release (if ever).

Now I'm going to get told this is OOP done badly/Agile done badly/I'm drawing a caricature. Perhaps it is. Perhaps there's a bunch of disciplines that aren't being observed. Then those disciplines aren't getting promulgated in programming schools AFAICT. Perhaps there's a bunch of legacy mindsets and language technology that is holding us back from reaching OOP nirvana. Due to the shackle of backwards compatibility, Java has to live with all the bad decisions/misunderstandings of language design from 20 years ago. But frankly I've been waiting half a century for OOP to deliver, and it still isn't getting it right.

And consistently the most brittle part of OOP/ORM-based applications is encapsulating state inside objects, with hidden assignments to private values. Because objects embody distributed logic, this is harder to unravel than (imperative) 'spaghetti code'. As Dave has said repeatedly on the forum, the only place to represent state must be in the database. Which is why I'm surprised he's continuing to allege an isomorphism with objects.

I'm not entirely sure this is an inherent weakness of OOP. I'm well aware there are many different OO languages, each with different semantics. If there were an OO language with only value semantics, no possibility of sneaking in reference semantics/object identity; and no way to encapsulate methods/state inside the objects; then perhaps I'd be seeing different outcomes.

So to come back to the point: there is in TTM's semantics no concept of location/box vs contents. The only reason for introducing such terminology would be to find some generalisation that will include OO semantics. But we want to exclude OO semantics from the database; and we want the data structure of relations/tuples/Attribute-value pairs to be all there is. No secret state. No other/invisible stuff bound in. No opportunity to detect two names denote the same value but are distinguishable. No reason to write gobbledygook like

 in D, a name is bound to a location unchangeably, but the location can be changed (which is the point of locations).

I just have no idea what that's trying to say. In D, a name is bound to a value. TTM has a strong imperative flavour, so we must add that as program execution continues, that name might get bound to a different value. The mechanism of that binding is an implementation concern/physical representation. On which TTM is quite rightly silent. Stop.

Quote from AntC on June 18, 2019, 2:53 am

Quote from johnwcowan on June 17, 2019, 3:52 pm

(While I'm at it, the first pure functional programming language was apparently PAL-R, published by A. Evans in 1968.  Its only imperative operation was Print.)

Thanks for that reference, but hmm? the wiki says "sometimes cited as the first computer-based functional programming language" is IPL 1956. And perhaps LISP in 1950's (very debatable how much that's FP). PAL was based on Landin's ISWIM design 1966. I see developers include James H Morris (is that of Brooker+Morris compiler-compiler?) and Martin Richards, who developed BCPL = "Basically Christopher's Programming Language" Christopher Strachey of CPL, the CPL that inspired 'Structured Programming' Dahl/Dijkstra/Hoare. Dahl who went on to develop Simula. What a time to be alive in programming languages!

If Haskell, or dumbed-down Haskell, becomes the new hotness, we will see programmers writing their entire programs in the IO monad, and whole libraries of unsafeThisAndThat with which to get "real work" done

No I'm not advocating for Haskell or FP over other languages/paradigms. I do draw on Haskell for ideas, because its semantics seem so clean and well-typed. (And because Monads seem to be a well-principled way to tackle mutable state in databases. Although Monads are not exclusive to Haskell.) And note that even SQL (for all its many warts) is regarded as 'declarative', not OOP, not imperative. (That is, if we keep to purely the query parts of it not the PLT.)

I do advocate for sum-of-products datatyping, which perhaps first came to maturity in FP languages (not especially Haskell). But these days is mainstream (except in TTM and SQL).

If you're going to make cheap jibes about "unsafeThisAndThat", you should be aware that most of the type-theoretic development going on inside Haskell is to separate out where calls to unsafe operations are actually safe, and improve type inference to detect that. Then you don't need to call unsafeAnything. And all the difficulties are interfacing to other languages with strict semantics and bloody pointers and mutable state.

Quote from Dave Voorhis on June 18, 2019, 8:46 am

Quote from AntC on June 18, 2019, 2:04 am

Quote from johnwcowan on June 17, 2019, 3:52 pm

Quote from AntC on June 17, 2019, 2:11 pm

TTM wants something far simpler to understand. You're just bamboozling yourself. Nothing in TTM corresponds to an OO object: not variables; not values of variables (not so-called immutable objects); not tuples or relations. And I think to say something in TTM is "isomorphic" to something in OO is just exacerbating the confusion.

For several posts now you have been responding to me like someone whose religion is under attack.  I'm sorry to have pushed your buttons so hard.  "A man convinced against his will is of the same opinion still," so I'm going to just, as you have said repeatedly, stop.

I think I'm in good company with this visceral reaction against trying to see 'objects everywhere'.

I can't speak for others, but I'm certainly not trying to "see 'objects everywhere'"; I simply identify semantic similarities where they (inevitably, if we're comparing programming languages) exist.