Malcolm Cohen wrote:
> 
> Roger Glover said:
> > C++ users seem to be willing to bear the cost in order to gain the
> > functionality.  If Fortran users are not willing to bear the cost, or
> > are not numerous enough to share the cost burden as effectively...
> > well, that is a different issue.
> 
> Huh?  You don't think C++ users vastly outnumber Fortran ones?

Rather the opposite.  My statement was a concession of sorts to
the practical realities of the Fortran community.


> > > You end up with increased cost,
> > > undocumented restrictions, or a cruddier environment.
> >
> > In theory, yes.  In practice I have not really seen any of these
> > problems in any of the C++ implementations I use frequently.  The
> > consumer price of a C++ compiler and programming evironment seem
> > to me to be are comparable to the price of previous C implementations.
> 
> The consumer price of these things is what the market will bear, not
> what it costs to originally produce.

However, doesn't the producer expect to cover his costs and make
some sort of profit?  I don't think all the former C vendors who
moved to C++ would sell at the price points they do if their
business model would not support it.


> These things are, after all,
> sold in some considerable volume.

Of course,  that is what I was trying to say above.  We are, as
you say, "in violent agreement."


> I am quite serious - what do you think are the "excellent" tools we are
> lacking?

A serious answer would take us quite far afield from the topic
at hand.  I will answer in depth under a separate cover.


> > > In particular,
> > > every tool that might mention the name to the user really needs to be
> > > changed... which includes most of my list!  QED.
> >
> > But in a unified programming environment (and perhaps in general) the
> > changes can be implemented in code ONCE and shared among all the tools,
> 
> Indeed; either you need to create a UPE to hide the low-level stuff
> that does not directly support your long names (and creating a UPE is not
> trivial),

It seems to me that there are much more serious market pressures
pushing vendors toward UPE implementation.  For myself, I try as
hard as I can to avoid any NON-unified programming environment,
as such a system seems to be extremely volitile over the lifetime
of any application written under it.  Thus, I doubt name mangling,
were it needed, would be the only factor pushing a vendor to
undertake the task of creating a UPE.

If this is an unrealistic view, I gladly concede the point.


> or rewrite the low-level stuff to support it (which might be
> nearly trivial if you own the low-level stuff to begin with, but is not
> if it means you have to write replacements etc. yourself - e.g. if you are
> not the machine/os vendor).

It would be nice if your "partnership" with the OS vendor could
extend to providing you with hooks such as these at key release
levels.  Unfortunately, these days it seems that the OS vendor is
more likely to be a competitor than a partner, so I will concede
this one unconditionally.


> > I was getting a gist of "unlimited name length just can't be done with
> > limited name length loaders."
> 
> Huh?
> 
> I did not say that.  I did not imply that.  The loader was only one of the
> items on my list anyway!

I had just finished reading and replying to John Bray's previous
message, and I unjustly read yours through that same filtered
context.  I apologize.


> > This is simply not true.
> 
> Yes it "simply" is true - just exhaust the limited name space.

In theory...


> (In practice this might not be feasible of course...)

How can we two people with the same opinion apply such different
connotations to it?!

Yes, "unlimited name length" is theoretically impossible to
implement on a computer altogether!  In a corollary sense it is
theoretically impossible to implement "unlimited name length"
through name mangling.

It is also theoretically impossible to represent an arbitrary
member of an uncountably infinite mathematical field with a
finite array of bits, but there are nonetheless Fortran data
types called "REAL" and "COMPLEX."  The last time I checked they
seemed to be fairly useful features of the language as well.

How finely must we split these hairs?


> > If the actual intent was to say "acheiving unlimited name length is not
> > feasable," then on that point I have no opinion.
> 
> Good grief, what a weird way of reading my message!

Yeah, particularly with all my misspellings :^).  It had been a
long day.

But remember, when I wrote that statement, I was looking at two
messages of yours, not one.


> The message I was replying to was "so why should anything care about name
> length" so I replied with a list of tools that were very likely to care
> about name lengths, thus showing a technical reason why one would want
> to have a limited name length.

And to *that* I replied that C++ does not have a "problem" (by
which I meant a technical problem with implementation details)
with any of the tools mentioned.

And to *that* you replied:
> > > Sure it does - it costs more to implement on some systems because of
> > > having to cope with or change inferior tools.

Thus you interpreted "problem" to mean a problem of resources.
It seemed to me that, by this statement, you were implying that
implementing unlimited name length through name mangling was a
"feasibility" rather than a "capability" issue.

If I misinterpreted your second message somehow, I am sorry.

So, your point is that there is a reason to avoid unlimited
name length, not that it is unfeasible...


> Obviously none of these problems are insurmountable (even if name mangling
> is not acceptable you can just rewrite the linker, debugger, librarian, etc.
> etc. - at (IMO) reasonable cost to the machine/os vendor, and (IMO)
> unreasonable cost for the third-party compiler vendor).

...you know, somehow I just can't shake the "weird" impression
that you are making a point about feasibility here.  Assessing
costs as "reasonable" and "unreasonable" neatly fits my overall
impression of what one means by "feasibility."  Does the word
mean something different on your side of the puddle?


This is getting out of hand.  You (and anyone else for that
matter) are welcome to have the last word.  I will write up
something about CASE tools under a separate subject heading as
promised, but I think I am done with this topic.


-- Roger Glover


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%