Clipboards + Meaning

[Fare Rideau]

>: Matt

>    The following is an example of what I mean:
>
> 	I have an image that's used as a parameter by a filter.  Instead
> of giving it static data, I somehow establish that the source object
> (maybe another filter - say one that's dependent on a time-value it's
> given) is capable of providing data that the filter knows how to interpret
> as an image.
>
Transforming a single image and transforming lots of images in sequence
are different things, so you need specify them differently!
I don't see why you make a fuss out of this.

If you have a function myfilter that transforms type A (image) into type B
(display action), then you can use it to express a reactive object that
accepts input of type A and sends output of type B to channel O.
In terms of some pi-calculus derivative, that'd be something like
	export input(I),output(O) from
		indefinitely (I=>myfilter=>O)

> Then, the time that's passed to the source changes, and it
> needs to re-evaluate itself... or maybe IT's source changed.  It should
> spawn a chain of re-evaluation that triggers all its dependents to
> re-evaluate themselves.
>
Beware! Synchronizing with evolving objects is conceptually very different
from processing streams of objects. In the latter case, the objects
from the streams are conceptually different and unrelated. In the former,
they are different versions of a "same" object, or more exactly,
from a *same* *project*. [Note: it seems that MS research people took a
similar path with "intentions"].

I believe the system should have a very deep understanding of what a
project is: a series of different objects that should be unified and
converged toward embodying a seemingly identical ideal goal.
Of course, projects may be implemented as streams of versions
(not quite simple linear streams, tho, as concurrent versions may diverge,
and the projects may be split or merged; not even a monotonous accumulation
of information, as semantical changes may occur and bugs be corrected away).
Still, there is more to it than a mere "stream". At least versions are
tightly related one to the other (few identifiable diff-erences and lots
of mappings are generally found between consecutive versions), and meant
to converge toward a "same" idea.

So, yes, there should be ways to semi-automatically synchronize objects
from a same project that has declared constraints that a modification
broke (e.g. constraint A is a picture, B is the same as a filtered A).
Constraints may be more complicated, and the priorities between various
constraints may change over time. The observable semantics of the object
does not lie in the way the constraints are enforced, but in the set
of constraints to be enforced. Hence, the way mustn't be required of
settled by the specification.

[Example for math people: in a problem of elementary geometry,
you'd like to make a drawing of the geometrical configuration;
on this drawing, you'll want see what happens if you move point A
while point B stays still; then you'll want to see what happens
if you move point B while A stays still; yet, there may be
constraints that make A and B moving in non-independent ways;
hence, the preserving the constraint between A and B will require
different tactics according to which of A or B you move.
Similar examples happen when experimenting with electrical circuitry,
etc; this is a well-known problem in constraint-solving programs,
and in logical-programming]


> 	I suppose I'm sort of pre-disposed to think about objects *doing*
> things, though.  What interests me are extensible, distributed systems
> that are able to tune themselves for efficiency.
>
I usually restrict the use of the term "object" to well-identifiable,
constant things, and "project" to moving targets. Of course, what's a project
in a context may become an object in some meta-context.
I don't see any problem with objects doing well-identified things,
but as soon as it's no more well-identified, then I see a project.
For instance, the *implementation of a given object*, that has
well-defined observable semantics, is itself a project, that
moves, and is constantly tuned for more efficiency, and not fixed in any way
(besides the fact that it must actually implement the object's declared
semantics). Objects don't tune *themselves*. Meta-objects (their
implementation) are being tuned by meta-meta-objects, etc.
Identifying distinct concepts is an important requirement in
the design of a system.


> I'm also interested in
> elegant, abstract interfaces that promote a simplified model for relating
> objects and controlling data-flow in basically any way that makes sense.
>
Then you want a constraint-solving system. I believe there's a chapter
about constraint-based programming in SICP. The theory of CLP
(Constraint Logic Programming) is also a very active field of
computer science these days.

[Organization of pictures]
>   Actually, I mean organization as in 1D array, 2D array, etc.  IMO, one
> ought to be able to feed a widget that outputs a 2D array of units that
> can convert themselves into scalar values of a finite range into an image
> filter.  The image filter only requires that its input are units that can
> be converted into linear values of a finite range, and are arranged in a
> 2D array.  I agree that the number of bits, etc. is merely a detail, and
> one that should be handled or exposed to the lll and the compiler.
>
Then what you mean is the ability to talk about a picture as an array
of pixel. Indeed, this is *one* of the key aspects of pictures,
and it should be possible to move between this aspect and other ones
(like, fourier-transforms of pictures, or vector-based pictures,
or pictures as a snapshot from an animation, or whatever).
That's the whole point of Tunes is that a same object can be
consistently accessed through multiple overlapping aspects
(I believe this is related to Kiczales' AOP at Xerox PARC,
though I never could see in depth what interesting things they did).


>   I have an object called a unit.
Beware! In functional programming languages, type "unit" is generally
reserved to a particular type with only one inhabitant, the null tuple ().
(See ML, Haskell, Clean, etc). I guess you mean "some arbitrary type" here.
Or perhaps you're speaking from an inheritance point of view (yuck)
whereby all types can be considered as inheriting from type "unit".
I'm not sure you want me to get started about inheritance being trash,
but then see the Glossary article about inheritance being but a tiny crippled
subset of what type-abstraction and subtyping can bring.
[Well, for a language that does things right, see OCaml].


== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System.               | 75019 PARIS     FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==