Oops

[Fare Rideau]

Dear Tunesers,
   this is a public reply to some of Alaric's (entirely quoted) remarks
in an otherwise private message...

>>: Fare
>: Alaric

[About lossage due to buggy procmailrc]
>> A good lesson for Tunes:
>> have a proof that mail handling won't lose information.
>> And handle semantics-based messages, instead of trying to guess
>> semantics from regexen on syntax.
>
> This is more of a technology thing than a science thing,
> if you see what I mean,
>
Well, this is a place where technology fails to take
the simplest conclusions of science:
** guessing semantics from syntax is an AI-complete problem **.
Hence any well-thought protocol must have ways around the problem,
instead of forcing users to clumsily define complex unenforceable protocols
(which only most advanced users can afford to do).
   Not that it can perfectly be done by having layers above e-mail:
SMTP allows only poor ways to encode data, but until we can have
a backbone of permanently available stable Tunes servers,
it is the only reliable universal messaging system we have.
   MIME tries to extend e-mail with a bit of semantics,
but it is doomed to fail because it was built on top of
a least-common-denominator set of assumptions,
whereas current OSes completely lack the infrastructure needed
by modular design, not to speak about higher-order modular design
-- see the hbaker's fine summary of our plea, for systems that be
the closure of implemented features, not their disjoint union --
yet another terrible consequence of the low-level C lunacy.
    Extensible yet secure semantics involve registries.
Not a central proprietary registry, but distributed free registries.
This is just not possible with today's low-level proprietary black-box
software industry.

> but I've been thinking about medium-level messaging protocols for networks.
I once thought about such thing, but rejected the idea.
Again, I'm not for a clear distinction of arbitrary levels, but
for the integration of the whole software system into a reflective framework.
Messaging is just one among this set of abstract features
the reflective closure of which constitutes what the system makes available.
Which does not mean that in this closure, some combinations be not
distinguished as "standard" or "default" for the purpose of easy
negociation of communication context.

> Email is human readable and barely machine readable,
> yet UDP packets are quite the opposite...
> there is a use, I think, for a "programmer-level" messaging
> protocol, the use of which is comparable to using a distributed
> CLI of some kind.
Remember, Alaric: "The map is not the land".
The object is not its representation.
If we define a semantics-based protocol, there can very well be
different yet isomorphic *syntaxes* for it.
Machines would use the more compact, easier to mechanically analyze one,
or even a compiled representation,
whereas humans would use a human-readable one, also compiled,
but with redundancies and ellipses optimized for human-understanding instead.

> Say you can send arbitary Scheme objects, you
> could implement device control like so:
> 
> Message sent to a scrolling LED display -
> (set-message! "Hello, world")
>
> Devices could also generate messages, which would be relatively
> human readable for debugging, yet low level enough to be efficient
> to parse and compact to transmit or store.
>
Surely, one of the possible representations for messages should be
human-readable, yet simple enough to be implemented in debuggers
for embedded systems (and/or the fallback debugger for an OS such as Tunes).
SEXP are indeed an excellent candidate, being a good compromise
between machine- and human- readability. I'm all in for SEXP as
a standard fall-back unambiguous universal representation.
However, there is no reason to uselessly waste resources on all devices
by using it as an ubiquituous low-level protocol.
   Perhaps you'd like your CPU to talk in Scheme with the memory
or I/O subsystem, and Superduperfastwwwwiiiiddddeee-SCSI-36 disks
to directly interpret SEXP. Personally I feel that'd be a terrible waste.
I mightn't look like so, but I don't disdain performance.

> They could be used as an improvement on UNIX logging daemons -
> have a process that logs all messages it receives.
>
Once we accept the fact that high-level semantics are not incompatible
with performant and compact low-level representations, I fully agree.

> You could also implement a version
> of the process that used snazzy pattern recognition to detect
> macroscopic trends and take corrective action... if the rate of
> generation of potential-error warnings from a machine rises,
> request an overhaul...
>
Sure. I've already said how MACISTE could detect that it's
high-level reasoning on a problem didn't yield enough new interesting
information, and trigger the compilation of subproblems
into specialized low-level programs (i.e. the usual kind
of programs people write, but optimized to take into account
all the information gathered by the high-level reasoning on
the particular subproblem).
Similar techniques can be used to dynamically trigger GC,
file compression, file-system reorganization, distribution of
objects over the network, etc.

> Something like email would be implemented over the medium
> level protocol. Send a message to a user object:
>
> (youve-got-email! <from address> <subject> <body>)
>
I hope my above remarks could convince you of my point of view
on the subject.

PS: suggestions about how to integrate the above remarks in the WWW pages
welcome...

Soft Music.

== 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 ==