Modularity (was: INT: Project Alive !)

[Francois-Rene Rideau]

> Hello TUNESfolk --
   Yo !

> 	A good many of you out there are sounding rather dead.
   Yeah, sounds deadly silent. But not completely dead, at least as for me.
I've been writing that OTOP thingy, and maintaining my personal version of
the project.


> 	I've decided, at least for the moment, to take up initiative of 
> the Interfaces project again.  In celebration, I've updated the 
> Interfaces page (now found at
> http://simba.lakeside.sea.wa.us/~chrisha/interfaces/) to contain a bit 
> more summarizing, removed some outdated stuff, and added a page of
> UI-related links across the net.  Nothing terribly new, really, but a 
> positive change....
   Congratulations ! I'll have a look right after christmas.


> 	As far as making some progress here, I'll bring up something Fare 
> (or someone) said a while back: that Tunes should be for all kinds of 
> computation, from report writing to games to scientific simulations to 
> www serving, and that Tunes objects are the basis of everything.  This 
> sounds good in theory, but it poses a slight problem for any interface 
> semantics.

> 	How can the same API support well both a beautiful 
> report-writing module, or, for that matter, most modules pertaining to 
> manipulating 2D surfaces for printing, and a rapid-fire, 3D action game with
> full-screen graphics?
   Depends on what you call "the same". Basically, though everything could
come packaged as a "one" Tunes system/API, completely different packages,
partly sharing common interfaces, could be provided from completely
different sources for completely different targets.

> What if a deaf person didn't have a
> full-screen, to see this game's graphics or the report-writing
> module?  We've agreed, in the past, that (s)he shouldn't be locked
> out of Tunes.
   No-one should be *dynamically* locked out of Tunes; that is, everything
should be kept as modular and fine-grained as can be, so that customizing
for one's systems should be only a matter of writing a limited set of
"drivers" (which to me applies to very high-level code as well as low-level
hardware access stuff) that'd automatically work on any software.
For example, someone using a very rare foreign language and alphabet should
only have to define how to input/output his language for every software to be
able to do so, and sorting databases in that language shouldn't be more
difficult than that.
   However, this in no case means we'll have a huge-grained ADA-like do-it-all
library meant to include every single case anyone may need. Because this
is just impossible. There will always be people *statically* locked out of
   Tunes (currently, that's everyone, btw, but a few people in their dreams).
This is precisely the philosophy of Tunes: develop a new dynamic
for computing and get rid of existing software sclerosis.


> 	Perhaps it would be helpful to look at the difference in the nature of
> these game-like, scientific, and text-oriented modules, and see under what
> sort of UI they could best be represented.  What, if anything, is common
> between these things from which we could derive some basic Interface semantics?
> Surely these different sorts of things must not be totally dissimilar....
   Sure what is common should be implemented and be made common. But let's
not refrain different software from having different interfaces. Let's
provide fine-grained modularity so that everything fits as well as it can.
text-oriented stuff will rely on text-related modules, etc. Do not put every
thing in the same huge-grained X-like bloated server.


> 	Maybe we should also look at what sorts of software might
> be written for Tunes.  Though we agree that most anything should be possible
> under Tunes, a program such as MS Word would probably be a bad candidate
> for such a fine-graned, persistant system.  A better choice would
> probably be something like the small text/graphics components of an OO
> system like opendoc (relavant links on the new pages), only perhaps with
> still smaller modules.
   It would be nice to have a good MS-Word replacement someday (some kind of
interactive TeX or TeX-like thing with automatic incremental compilation to
WYSIWYG). But this is not a priority. Number one priority would be a robust
extensible structure editor featuring good extensible text handling
primitives, that could be first implemented over a text-mode interface.
Of course, we need a secure persistent object store with import/export
from/to standard text files to rely upon.


> 	Are games such as doom, that are essentially their own OS, have a 
> place in Tunes?
   Yes, they are. I wouldn't like to reboot, put my files in danger, and
cease to share my computer resources (and benefit from other computers'
resources) "just" to play a game. Tunes is for *all* kind of computations.

> Certainly some games would help out the system's
> popularity.  But is consuming the whole machine encouraged?
   Certainly not "encouraged" as even real-time does not mean that the whole
machine is required. I'd like usual event warnings (alarm, mail, etc) to
still be available while I'm playing, and such things not preventing other
people with more serious tasks (in human sense, not trashix meaning) to
access objects whose only current copy is on my computer. However, using
most or exceptionally all of the computer should be made easy, particularly
as Tunes should target compile embedded systems easily, for instance.

> Should we
> provide some sort of fast, semi-portable gaming primitives? 
   Yes and no. Yes, this is definitely a good long-term idea. No, it is not
needed soon or deep in the system. It should be fairly easy (though long)
to write (or semi-automatically translate from existing code) once a more
"serious" development system is available. Now, this shouldn't prevent anyone
to work on that before the rest of the system is done, if one really likes it.

> Should these
> have nothing in common with the graphics primitives that a simple
> picture-drawing module might use?
   These should be the *same* primitives, or rather, they should share the
very same specifications. However, they'd have completely different
implementation tactics. How I see things, the HLL separates completely
specifications (that go far beyond usual list-of-typed-named-object-member,
but allow full logical semantic description, including time/space/network/*
resource constraints) from implementation (which, but for the lower "layers"
of Tunes, will be mega-implementations, descriptions of implementation
tricks, possibly multiple and mutually exclusive hints for an automatic
logic-programming-based prover/compiler/specializer), yet the interface
would allow to codevelop them, and the user could edit related specs and
impls of "same" objects in the same "window" or whatever 'the system would
automatically dispatch each annotation data to the proper "file" according
to its formal or unformal "type").
   As for efficiency (someone talked about the "overhead" of fine-grain),
please do remember that Tunes will provide a lot of automatic
specialization/inlining/optimizing, so that there is not the overhead of
statically compiled and dynamically dispatched objects that unclean language
semantics and stupid linking traditions forces C/C++ compilers to adopt.
Thus, if you define objects bitwise, you needn't access a dispatch table
each time you read or write every single bit; rather, the whole stuff is
compiled together to very efficient code (more than anything conveivable
with available compiler technology where you just can't express tricks,
least you lose a lot of time hand-compiling it in a particular case,
and lose all the other automatic optimizations done automatically by the
compiler).


> 	Answers, comments and more questions are welcome....
One: may all you have a merry chris-tmas !