Clipboards + Meaning

[David E. Manifold]

On Wed, 10 Dec 1997, Thomas M. Farrelly wrote:

> And also, every format must be formally specified somewhere in the
> system, eighter statically or dynamically. As I understand, you want to
> specify formats/interfaces/semantic appearence dynamically, i.e. using
> dynamic linking and late typing, and so, you need to specify such a
> dynamic system, which in its turn will need to be statically specified.

Tunes not only has dynamic implementation, it has dynamic reflection.
There is an identifiable specification for the system, at any given time.
But dynamic reflection allows the system itself to be dynamically changed,
without outside or "static" reference.

You are not incorrect in saying some specifications are static.  But the
only static specifications are ones the user labels as such.  These static
objects are the ones the human likes to interface with, because they
provide the appearance of stability.  We try to keep these
human-interfaced objects as high level as possible.

> By static specification, I mean using constant relative addressing. For
> example, if I have a string of characters, a label, and a pointer to
> some object assosiated with the string, I could define my format like
> this:
> 
> 	byte	00	01	02	03	04	05	06	07
> 		\_____string pointer_____/      \_____object pointer ____/
> 
> Where the string pointer would have offset 00 and the object pointer
> would be 04.

In Tunes, we discourage you from putting such low-level requirements on
your objects.  It is better to let the system transform them dynamically,
for more efficient optimization and to allow effective distribution.

At any given moment the low-level representation may look like this, but
since the system changes so often, it would be unwise for you to demand it
stay that way.  A pointer could require a few more bits for a few minutes,
for example, so the system could make your object a little larger for a
short time.

The point is if you always refer to objects by their high-level meaning,
such as "label" and "object reference", your modules will be more useful.

> I could call this little format for 'a reference', for example, and use
> it to build a new dynamic format, like 'picture'.
> 
> picture
>   list of recerences
> 	bitmap, pointer_to_bitmap
> 	pallette, pointer_to_pallette
> 
> 'picture' is an example of a simple dynamic format. The reason it is
> dynamic, is that you consult the data for the path to further data, thus
> the paths through such structures may change dynamically. But there is
> no magic to this changability or adaptability. It is all accounted for
> on the lower abstraction levels ( or in your case, the meta-objects form
> here to n ).

Yes.  In Tunes we allow you to work with higher abstraction levels, and
provide incentives to avoid lower ones when possible.  One such incentive
is a dynamic compiler to translate to lower abstraction levels for you.
Another is the reuse and interoperability that higher abstraction levels
allow.

The path may also change at the very end, where byte order is defined.

David E. Manifold
tril@bespin.ml.org