Julián Albo said:
Yes, it's easy to imagine silly ways to compute things. But is also
possible to invent ways practical and better than current.
Perhaps silly, but I find that such ideas expose aspects of what we really
mean by code execution, etc. Often there are patterns working at very
different scales of time and space which we give different names, but when
we look closely, they are actually manifestations of the same underlying
example.
I think that depends of the meaning assigned to the word 'linking'.
Perhaps in our imagined new computer or development tool there is nothing
called 'linker', but we can stablish that some part of the process of
creation of a executable will be considered the linking phase in order to
match the conceptual process expected by the standard.
Actually, the Standard doesn't require that step to actually take place, so
long as the observable results are as if the steps had taken place.
I think that the intent is not to have essential meaning, leaving the door
open to any new technique that can be introduced.
I believe that is the current intent. I don't know if it was as important
in the minds of the original authors of the paragraph.
If nobody has developped
a definition abstract enough to allow any conceivable and potentially
useful technique the better solution is to leave it whithout a rigorous
definition.
It's one thing to change the wording of the Standard, which I have not
proposed. It's quite another thing to attempt understanding what it really
implies.
"All external object and function references are resolved."
This is what the standard says about objects:
"An object is a region of storage. [Note: A function is not an object,
regardless of whether or not it occupies storage in the way that objects
do. ] An object is created by a definition (basic.def), by a new-expression
(expr.new) or by the implementation (class.temporary) when needed. The
properties of an object are determined when the object is created. An
object can have a name (clause basic). An object has a storage duration
(basic.stc) which influences its lifetime (basic.life). An object has a
type (basic.types)."
So what does "external object reference" actually mean? It doesn't seem
meaningful to talk about the object existing before the program is
executed. I'll have to think about what might constitute an external
object in this context. The part about it being resolved seems easier to
understand. It means determining where the object is defined in some other
library, object file, or similar.
"Library components are linked to satisfy external references to functions
and objects not defined in the current translation."
Would there be a case where an object is not named, but it still needs its
reference to be resolved? IOW, are all of these declarations for which
definition are not provided in the current translation unit?
"All such translator output is collected into a program image which contains
information needed for execution in its execution environment."
That part seems fairly straight forward to me right now.
To me it seem illadvised to completely ignore the relationship between
language facilities, and object file structure. I understand the
motivation for wanting to avoid over specifying details. OTOH, if there
really is an underlying structure that will be common to all systems, and
language constructs can facilitate better use of that structure, it would
be a mistake not incorporate them into the language.