Re: [boost] [guidelines] why template errors suck

Subject: Re: [boost] [guidelines] why template errors suck
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-04 13:51:59

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