At Mon, 4 Oct 2010 10:04:04 -0800, Robert Ramey wrote:
David Abrahams wrote:
At Tue, 28 Sep 2010 10:17:39 -0800, Robert Ramey wrote:
And I didn't see that this was a question regarding the serialization library per se, but rather the whole question of the relationship between programming language (or any algebraic) syntax and underlying meaning. These questions have been extensively studied
Yes.
and I believe effectively put to rest in a way which supports my view that what we can hope for from semantics is limited by factors outside outside our perview.
That statement is sufficiently vague so as to be irrefutable. Unfortunately that also makes it kind of meaningless.
My view on this is probably best described in Douglas Hofstadter Godel, Escher, Bach - Chapter II which describes the mapping of symbol expressions to deeper meaning. This left me concluding that that it's unknowable what some formal syntax might map to.
Yeah, it's unknowable, unless it's specified. I don't think anyone has a question about what the formal syntax called "Java" maps to.
And indeed there are many cases where the same formal system maps to sidely differing domains. (e.g. differencial equations to systems of springs and weights and compacitors and inductors). So, although the "semantics" provides motivation and direction in an intuitive way, it can't be formulized itself.
I don't even know what that means.
So, I tended to regard your proposal as like a design for a very clever perpetual motion machine which I know cannot work, but cannot refute the very clever and intricate explanation of it's inventor without a lot of investment of effort.
Maybe I shouldn't have been, but this remark left me feeling quite insulted on Joaquin's behalf.
You're right, you shouldn't have been insulted on anyone's behalf.
to suggest that he's some kind of charlatan ...
I didn't do that.
Comparing his proposal to a design for a perpetual motion machine suggested to me that you think he's either trying to put one over on you, or is pathetically misguided. But maybe it was just an poorly-chosen analogy.
Of course, "sort" *does* have a rigorously-defined meaning that corresponds exactly to common convention, so it's actually much less important that someone repeat that definition than in your case.
If it could be done.
If _what_ could be done? Defining "sort" mathematically? Or serialize/deserialize?
Joaquin essentially gave a rigorous definition to "serialize" and "deserialize." Maybe you don't think something like that matters, but for understanding what your library is actually supposed to do, it matters to me.
It's not so much that I don't think that it matters, it's that I think the minute you try to pin it down, you discover that there are some ambiguities. When you try pin those down, it gets deeper and deeper.
Do you think that's true of sort? If so, I'll dig up the mathematical descriptions and you can show me the ambiguities.
Using the serialization library as an example. Suppose someone says "this is OK" there's only one thing, I don't want the library to create new objects when a pointer is serialized. I want it to just update the objects pointed to". This is a perfectly plausible point of view which is consistent with the current syntax of the library. If someone makes such an archive, should be be considered "non-confoming" in some sense?
I don't know. Let's look at Joaquin's proposal and see if it's compatible with such an archive, and decide whether or not you think it should be allowed. That will help us know whether Joaquin's proposal works for your idea of the library.
If so, how would this be detected and enforced?
Detection and enforcement is beside the point. You can't reliably detect a broken comparison predicate used with sorting, but knowing the mathematical constraints make it understandable how to build one that will allow the sort algorithm to, um, actually sort.
Maybe my reservations about the idea of "formal semantics" are more clear.
They're clear. You are saying, AFAICT, that you don't want to try to pin down any semantics because that might rule out, purely on the basis of specification, some useful application of your existing code. The only problem with that is that without some such specification, nobody even knows if their existing applications of your code are going to work tomorrow. We're in a "use the source, Luke" situation at the moment. -- Dave Abrahams BoostPro Computing http://www.boostpro.com