The memory layouts don't need to be known to the user. Different hardware architectures can have the concept of floats and ints and code can be written using them the same way while the underlying representations are distinct. I promise that IEEE754 is not the only way to represent floating point values handed down from god to man on a golden scroll.

> > And you need to know what the types of the inputs to a query wrapper function are to be able to call it properly.

> That's the interface.

Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure". Now you acknowledge that the interface necessarily includes the types of the arguments?

This isn't relevant one way or another.

Different hardware architectures can have the concept of floats and ints

This also isn't relevant. Data types aren't expected to be cross platform unless they are specifically made for that, like file formats.

Funny, I recall you not very long ago saying "interfaces describe behavior, types describe shape and structure"

I never said that.

Also just because two things work together doesn't mean they are the same thing.

> This isn't relevant one way or another.

What needs to be known to the user of an interface is the most relevant aspect of describing that interface.

> Data types aren't expected to be cross platform unless they are specifically made for that, like file formats.

It's going to be difficult to reconcile that position with https://en.wikipedia.org/wiki/Abstract_data_type

Data types can optionally specify machine representation but need not. They specify behavior (i.e. possible values and operations) first and foremost. In programming, nearly every use of data type is in the abstract, entirely separate from its hardware representation. The "Int", the "Bool", the "2", the "UTCTime" being specified in TFA don't care about bit arrangements. They're describing valid values and operations, not hardware.

> I never said that.

You're right. Apologies. It was the other poster at the top of the thread. But it still seems apt to the thread and to your specific portrayal.

Not every scenario cares about bit arrangements but they are still there.

You seem to just be shifting around and coming up with new, more abstract arguments that drift further from whatever point you originally had.

You said

"Shape and structure are behavior."

One is data, one is execution. These are two different things.

The more they are conflated together, the more problems people have with their programs.

Not separating them and letting them mix is a huge part of bad software architecture and leads to lots of unnecessary complexity.