[unios] Semantic-based linking

Tril dem@tunes.org
Thu, 24 Dec 1998 20:25:44 -0800 (PST)


From: Tril <dem@tunes.org>


> If you implement something that is useful in more than one app, you can
> let everybody that codes for the OS take advantage of it... yes, DLL's 
> do that too, but by using interfaces, others can even find the new 
> possibilities by simply looking at what the objects can do (the 
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> supported interfaces and their functions), and use them directly throu
> the scripting language. If the new features conforms to standard
> interfaces, other applications will know how to use them, without
> upgrades.

I'm glad someone else sees the importance of this.  Easier said than done,
though.  In order to use a function based on what it does, you have to
have a high level description of what it does.  

So for instance, the assignment operator has to have, as part of its type
(you called it "interface"), something that says "if you assign a value to
this variable, and then access its value before assigning it another one,
it will be the same value you put in"  (in mathematical terms, you reified
[made explicit] the concept of state).  Then someone needing an assignment
operator can request one by referring to the explicit definition of the
behavior of objects that use assignment and preserve state. 

This kind of "function lookup by meaning" (I call it semantic-based
linking, because semantics is meaning) is far better than what most
languages use today, linking by name.  Names are:  

1. Language (i.e. English) specific 
2. Not precise specifiers of meaning, even to humans, that is, why use
"print" in C and "write" in Pascal?  "write" in C is a disk operation, and
"print" in DOS is a printer operation.  "write" in Win31 is a text editor.
3. Meaningless to computers
4. Hard to remember when writing code
5. Hard to understand when reading code

What are the requirements to get semantic-based linking?  Basically, the
entire function's source must be abstracted and put in its interface!
"What!!!" you say.  I mean an abstract representation of behavior,
independent of implementation.  I call this 'specification.' It is the
meaning of a program (function) separate from a particular method of doing
it.  So for instance, the idea of a sort function, the fact that its input
is unsorted data and its output is sorted data.  Not whether it uses
bubble sort or shell sort or quick sort; those are implementation details.
But you need some way to describe what unsorted data is, and what sorted
data is (this is done by using LOGIC! Go learn it.  Too few Computer
Scientists do). That is the semantics of the function. SYNTAX is the bare
form of the function, the fact that it inputs a set of data and outputs
another set of data.  Too long has TYPE gone without inclusion of
SEMANTICS.

So in TUNES:
* functions and function calls don't need names, but they need
specifications
* the system knows the difference between a function named print that
writes to the screen, and a print that writes to the printer
* the system knows the equivalence of a function named print that writes
to the screen, and a function named write that writes to the screen

I hope UniOS as well.

David Manifold <dem@tunes.org>
This message is placed in the public domain.


------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios