From: Dmitry A. Kazakov on
On Fri, 30 Jul 2010 05:31:41 -0700 (PDT), Maciej Sobczak wrote:

> On 30 Lip, 11:09, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>
>>>> What are you trying to say by this?
>>
>>> That it does not matter what was the suitability of the back-end
>>> tools, as there is no obligation (as far as the standard is concerned)
>>> to use the existing tools. If you are not obliged to use existing
>>> tools, you are not constrained by their (lack of) suitability.
>>
>> This is obviously wrong. It is like to say that you are not constrained to
>> fly to the Moon even if there is no rocket available.
>
> This is obviously wrong. The language standard is not concerned with
> what is available, but with what will be developed. Existing practice
> can of course provide the valuable guideline as well as feasibility
> data, but is but no means formally constraining.
> You can standardize flights to the Moon even if there is no rocket.
> Rockets will be built according to what the standard says.

Can I buy a ticket?

>>>> You mean shared Ada generic bodies? Yes they require much less late binding
>>>> than C++ templates would,
>>
>>> Can you elaborate on this, please?
>>
>> Compiled generic bodies, at least in Ada 83, can be parametrized using
>> linker expressions.
>
> 1. What are linker expressions?

Formulae used to define symbols.

> Why they cannot be used with C++?

They are used with C++, but not to instantiate templates.

> 2. How does this affect the amount of late binding and why is there
> less of it than with C++ templates?

Because Ada generics were intentionally designed to support sharing and
thus not to become a burden for linkers and loaders of existing OSes. C++
templates were never intended for this.

>>>> 1. My example of shared macros was MACRO-11.
>>
>>> I thought we were talking about C++. Or Ada.
>>
>> We were about macros.
>
> No, we were talking about going to the Moon.
>
> Your tendency to pull the subject in every possible direction just to
> keep the discussion going is nothing new here.
> *I* was talking about C++ templates and in that context your claims
> were wrong.

You didn't show that.

> During the discussion I have referred to the C++ standard,
> whereas you have failed to substantiate your claims in any way other
> than with unrelated stories.
>
>> (Especially because C++ templates are macros (:-))
>
> Handwaving. We are close to EOF.

Talking about discussion methods, I did explain what macros and templates
have in common. All your responses so far did not go beyond "has nothing to
do".

>>>> 2. The standard does not put any requirements on how the compiler actually
>>>> works.
>>
>>> Bingo. So why do you put claims that are based on the suitability of
>>> some tools?
>>
>> Because any implementation must use these tools.
>
> Implementation must use *some* tools. It might bring its own.

Show me a C++ compiler coming with another OS, loader, linker.

>> 1) C++ tells something about templates
>> 2) C++ is silent about some other things about templates
>> 3) 1 makes something allowed by 2 difficult
>
> And we're still nowhere close to the conclusion on sharing generic
> bodies across instantiations.

We are done with debunking your claim about alleged contradiction.

> (we got, however, closer to the Moon in the meantime)
>
>> Where is a contradiction?
>
> 1. "the back-end tools down to the linker and loader were unsuitable"
> 2. "The standard does not put any requirements on how the compiler
> actually
> works."
>
> The two above are exact citations.

See above.

> Frankly, I'm both tired and bored of this discussion. Can we stop?

Sure.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Randy Brukardt on
"Peter C. Chapin" <pcc482719(a)gmail.com> wrote in message
news:4c4f5c28$0$2375$4d3efbfe(a)news.sover.net...
....
> Thanks for all the replies to my question. I want to emphasize that my
> interest is not so much in what is done by current compilers but rather
> what is allowed by the standard. Is the standard (even the latest
> standard) written in such a way as to make a shared implementation of
> generic bodies possible? It sounds like the answer is yes.

I have been very vigilant to preserve the ability for generic sharing in the
Ada Standard. (It's something that would be very easy to lose because of
some obscure combination of features.) I can't say for sure that I have kept
every such case out of the Standard, but there is agreement that at least
limited sharing (when the parameters are "similar enough") ought to be a
permitted implementation. "Universal sharing" (where there only one body for
each generic), as used in Janus/Ada, is more controversal (but is still
allowed by Ada 2005).

Randy.


From: Randy Brukardt on
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message
news:94v29hel87y$.8jvqfyw964yt.dlg(a)40tude.net...
....
>> Can you elaborate on this, please?
>
> Compiled generic bodies, at least in Ada 83, can be parametrized using
> linker expressions. I didn't looked into Ada 95 tagged types derived
> within
> the body from a formal generic parameter, you better as Randy for details.

Deriving from a formal tagged type is illegal in generic bodies (always has
been), see 3.9.1(4/2). This rule has less to do with generic sharing than
with inheritance of abstract operations (Ada wants the bodies of instances
to be always legal no matter what the actual parameters of the instance
are). But it is convinient for generic sharing. (Derivation in the
specification of a generic unit can be treated like an implicit formal
parameter.)

Randy.


From: Randy Brukardt on
"Maciej Sobczak" <see.my.homepage(a)gmail.com> wrote in message
news:14342188-c6f4-4b60-9284-8eff4f3f9ecd(a)k19g2000yqc.googlegroups.com...
....
> 2. How does this affect the amount of late binding and why is there
> less of it than with C++ templates?

You need to read about the Ada contract model for generics. (Off-hand, I
can't think of a good reference, however.) Part of the Ada contract model is
that there cannot be an error caused by the actual parameters of an instance
in an instance body. Tucker Taft liked to describe the model as
"assume-the-best" in the specification and "assume-the-worst" in the generic
body. Thus there are a lot of things that are illegal in a generic body in
Ada simply because they *could* be illegal in some instance of that generic.
C++ has no such counterpart (indeed, I recall reading that Stoustrup [sp]
explicitly eliminated it from C++ templates because it was too complex).

In addition, binding of names in the generic body always takes place at the
point of the compilation of that body. That means that most operations at
determined at that point, facilitating sharing. (This also causes the
sometimes bug of "reemergence" in generics, where a hidden predefined
operator is used instead of the user-defined one for the actual type.) C++
uses a more macro approach to template expansion.

Randy.

P.S. When Dmitry talks about "macros", he means the general concept of macro
processing. You seem to think he's talking about C macros, which is a
specific instance of macro processing. It is pretty likely that some form of
macro processing will be used to implement templates (and Ada generics in
most compilers), but that has nothing whatsoever to do with the C
preprocessor.




From: Robert A Duff on
"Randy Brukardt" <randy(a)rrsoftware.com> writes:

> I have been very vigilant to preserve the ability for generic sharing in the
> Ada Standard. (It's something that would be very easy to lose because of
> some obscure combination of features.) I can't say for sure that I have kept
> every such case out of the Standard, but there is agreement that at least
> limited sharing (when the parameters are "similar enough") ought to be a
> permitted implementation. "Universal sharing" (where there only one body for
> each generic), as used in Janus/Ada, is more controversal (but is still
> allowed by Ada 2005).

Like Randy, I am in favor of retaining the ability to share generic body
code (universal or otherwise) in Ada. I am not in favor of trying
to make universal sharing efficient at run time -- that's not
possible. It's a trade-off -- it may make compile time faster,
at the expense of run time.

It is not feasible to share generic spec code.

- Bob