TUNES UI

[Francois-Rene Rideau]

(In a private mail),
Chris wrote:
>      I have a half-completed e-mail about the UI that I might be able to 
> send out tonight.  Has a half-direction to go in, although it won't be 
> the most conclusive.  Also could update the mail archive, although that 
> is less motivating, seeing how it looks like that might have to all be 
> re-done sometime in the future.
   You might as well use hypermail to generate files, or just include
them as text files...



>      I don't seem to be understanding active annotations either,
   Ok. That's the problem indeed. The idea is that you dynamically modify
the language's behavior by annotating objects with other objects that should
be evaluated at the same time. security is preserved, logical constraints
are preserved, by usually requiring annotations to only involve objects that
will evolve independently from the annotated objects, thus not interfering
with the annotated objects' semantics. Now, the annotations may introduce
*new* constraints that may be proved or enforced, so they really enrich
the semantics.
   For the UI, you may annotate events with behavior, (or behavior with events,
through a converse annotation), you annotate raw information with higher-level
data, with comments, etc. Active annotation means that annotations may be
automatically evaluated with the annotated object. When an event arises, the
event object is evaluated, and all the behavioral annotations too (in parallel,
but they may synchronize with each other if they want).
   Annotations can be used for
* debugging ( when reaching this point, do output this value, or stop, etc),
* accounting (log all such operations),
* profiling (count how many times/how much time is spent in this loop, etc),
* maintaining indexes in a database (on each operation, update the new index)
* more generally, extending data structures (when doing operations,
 also treat the new fields).
* commenting (add user-readable comments)
* optimizing (tell the computer how it may do it more efficiently under
 particular conditions)
* user-interface (how to choose an object satisfying constraints - default:
 user interaction).
* natural language (add new semantics for existing words in some contexts)



> and am also having trouble understanding how you can write code before a HLL
> syntax exists.
   Explore new and old syntaxes: try to express your ideas the most simply
you can, and see what language you obtain; try multiple syntaxes, with
simplicity in mind, which includes simplicity of the core language,
easiness of human understanding of what the computer will do, and of
proof that a program is correct. e.g. "do what I want" is a nice program
in a "natural language" interpreter; now you can't trust the computer to
know "what you want", so you can't prove anything about it.



> I would like to help with the syntax, I believe, but we 
> need a bit more clarification here.
   Yes I know. Many languages already exist, so how choose the most
orthogonal possible syntax, to serve as a core for the language ?
I'd suggest something like LISP, BETA, SELF, Dylan or CECIL. Why not use
one of these as a basis to modify/change ? Well, I'm not sure myself.
Actually, I need to study much more existing languages if I am to take
them into account ): ): ):.



>      Finally, I know I've probably asked this enough times to be really 
> anoying, but any suggestions you have about what GUI I might be wanting 
> to learn for UI experiements would be most welcome.
   I've not been very happy with my GUI experiments (too much low-level
hassle), and have stopped doing such things. If you want to write low-level
primitives (which I don't recommend), you might try SVGAlib; or else,
you should try X programming under linux, not directly in C, but through
tools well integrated into a language, like tcl/tk, python/STDWIN, icon/*,
BETA/*, SELF/*, LISP/CLOS/*, SCheme/*, etc.

Hints:
"http://acacia.ens.fr:8080/home/rideau/Tunes/Review/Languages"
"http://remarque.berkeley.edu/~muir/free-compilers/" (not very up to date)
the FAQs from comp.compilers, comp.lang.lisp, comp.lang.*, etc

   At the same time, you'd review the UI stuff and the language. Send
feedback to the Review subproject (already a lots of pointers from there -
send me more).



> I might still
> remember something about mac programming, but I'd rather not touch that
> machine, as it uses a  16 mhz 68020, and just isn't fast at all.
   Moreover, it'll be very difficult to transform such a mac into a
decent development platform (as it's 68020, linux won't even work on it,
unless you can have this MMU chip AND linux is ported to it): You could
try programming in MOPS/Yerk (an OO Forth system integrated to the Mac
environment).



> Does this mean we'll have to get a 
> basic TUNES kernel off the ground before we can really do any work on the 
> visual side of the UI?
   No. Ideas and code are already valid or invalid before you implement them.
Just it's more difficult to check before than after ;-). You can already
invent your ideas, try to write code for it in a hypothetical language that
you'd like to use; then refine your ideas by thinking about how the mechanisms
the system/language can be implemented with. You must do that anyway before
actually implementing, even if the underlying platform is available.



> (Is anyone working on a kernel now, by the way?  
> Sounded like you had some boot code, but what does that involve?  Is our 
> first version depending on the BIOS, like MOOSE was?  Anything else you'd 
> like to answer?  =)
   I'm working on a "kernel" for the i386 right now. Currently it's just
a translation of my MOOSE bootstrap code; but I've downloaded lots of
other protected mode kernels so I can complete that soon. Afterwards, I'll
inspect garbage collecting.
   I'm constantly documentating this stuff, so that anyone should understand
it. However, I'll *soon* reach the lack of decision in the LLL field
and the HLL syntax, so I'll have to improvise and explore...