Semantic-based linking

[David Jeske]

On Tue, Jan 01, 1980 at 12:49:38AM -0800, Tril wrote:
> On Sat, 26 Dec 1998, Anders Petersson wrote:
> 
> > I do, however, think the idea you presented is interesting. But I don't
> > understand how you actually refer to a function without a name. Would a
> > function name be constructed out of a description of the function, using
> > strong syntax rules?

> > I think a practical example of how this would work would help me understand
> > how it can be accomplished.

I'd like to provide a practical example. In today's class based
languages, string names for classes are used. However, source code has
to be rewritten when collisions occur. In addition, most class based
languages don't deal with replacing base-class implementation very
well. More modern class based systems have seen problems with class
name collisions and have started to use 'namespaces' to prevent these
collisions. 

The idea of 'semantic-based linking' is admitting that any 'names' are
prone to collision because they are only rigid in the context of the
program author's head. We can have 'common names' for functionality or
objects, but at some time two people are going to implement different
things and accidentally use the same 'common names'. To avoid this, we
allow the programmer to write code in terms of the 'common names' he
is using at the time. However, the program is stored in such a way to
refer to the unique implementation, not the common-name. 

Microsoft's COM admitted that the best way to avoid these collisions
is to just guarnatee each object/interface in the world gets a unique
ID. So each inteface in COM is given a 'GUID' (globally unique
identifier) which is based on the DCE RPC UUID standard. It's
basically a way for anyone in the world/universe to generate an "id
number" which has a very high probability of being unique.

In terms of standard C-development, if you were to write a program
based on standard libc, you might adopt the standard "libc common
naming" for your source code. Any use of 'write()' would be accessing
the libc version. However, if some other library you were using (say a
printer library) also had a "write()" function, you could bind it into
your environment with a name other than it's common name. The system
would remember that the program had references to the unique GUIDs
which represented the libc "write()" and the printer lib "write()",
and they would be distinct.

If at runtime, it couldn't find the printer library "write" function,
it would know it's unique identifier in the world. The system could
ask some server for a description of the function, and perhaps
download an implementation compatible with your system right then and
there. Or perhaps present the user with a list of implementation to
pick from.

Make sense?

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net