ZIRUS & Tunes
Sat, 4 Jan 1997 04:39:17 +0100 (MET)
> we have read your home pages about TUNES project. Your idea is beautiful.
Thanks a lot!
> For long time we have being developed
> an Integrated Software Environment (ZIRUS)
> as a new platform for software development and implementation.
> We consider our ideas are closed to your project.
The subject of your message was about collaboration.
I'd be glad to collaborate in any appropriate way.
Maybe ZIRUS can serve as a basis for Tunes development.
Is any source available for some basic ZIRUS software?
> We send you our draft about ZIRUS.
I read it. Seems interesting indeed. Send me more about it!
> We'd like to refer to your publications about TUNES in our papers.
> Could you e-mail us about your basic publications and more closed
Feel free to refer to what I published!
The problem is that what is on the WWW is all that is published :( :( :(
But if you'd like me to expand specifically on some subject,
tell me so I write an article about it:
it'd be very kind of you to guide me
in what parts of the Tunes project need be explained better...
Merry Christmas and a Happy New Year!
> The conception of ZIRUS is:
> 1. Representation of all system elements on logical level
> that is the base for external (for users) and internal (for
> a hardware platform) projections of these elements.
Ahem. IANSWYM (I am not sure what you mean).
> 2. [SEGMENTS]
> 3. The objects are represented as a set of SEGMETs describing
> both data structures and methods.
Yeah, this is a good idea, and that's also how the lower-level modules
of Tunes should do it; ZIRUS might be an excellent start for the
lower-level parts of Tunes.
However, higher-level modules would be more abstract,
allowing reflectively defined representations to be used.
A same logical high-level object would not need be represented by
a segment; it could be represented by a linked list of segments;
by stuff outside of the computer RAM
(accessible by disk, network, or any other I/O), etc.
This should really stay abstract.
I can imagine that the system could automatically determine
and dynamically modify the low-level representations for a
same high-level object, so as to dynamically optimize
various phases of computations done on the object.
Actually, such techniques have been successfully used before,
though not on the scale I dream for them...
> 4. Logic of program moduls are described by objects of
> specific structure with translation and implementation methods.
Do you mean your system is reflective w/ a standard low-level
> 5. Including in knowledge base logic-functional links
> allows to influence upon a process of program creation and implementation.
Do you mean you have a semi-automatic meta-programming system?
> 6. Evolutionary interrelated development of the conception,
> software environment and applications by a mobile team.
Do you mean you have a dynamically reflective system?
> To the end of making the ZIRUS environment internally full
> a language OLFIS has been developed and included as the next
What does "internally full" mean?
Perhaps standalone reflective?
> - functional programming (programming at the expence of
> introducing and decoding definitions at different conditions);
I know what I learnt as being functional programming,
but IANSWYM with your comment...
> - description of logic in the form of functionally-bounded
> modules (structural elements of the language);
What is functionally-bounded?
> - possibility of 1 : n structuring transformations: from
> one external module's representation to a set of internal
> representations, and vice versa, from one internal to a set of
> different external representations;
Like my really abstract objects, ain't it?
Or perhaps you allow only use of representations
that are founded wrt low-level memory chunks...
> - simulation of both external and internal module
> representations in the form of diverse-type segs;
Ahem. Another kind of reflectivity again?
> - adjustability of language syntax with the aid of special
> OLFIS dictionaries;
Good. Just how adjustable is this.
How does it compare to Scheme macros,
or to Coq grammars?
> - module's internal code includes different elements
> defining the internal logic of the module (lists of
> parameters, sequences, constants, functional and seg terms,
> etc.) and contains information links with the other modules to
> be retrieved and the data structures.
You mean accessible as first-class data?
> - possibility of constructing the event-type control with
> the use of processing the modified data;
I don't understand.
> PROCESSING LOGIC-FUNCTIONAL LINKS (LFLs)
> AND BASIC SCHEME OF PARALLEL PROCESSING
Ahem. What is an logic-functional link?
Can you give a few simple examples?
You say they can be selected.
Is it statically or dynamically?
>From a statically determined list,
or a dynamically modifiable list?
What is a fail LFL?
What when such a failure would make dependent computations
to yield incorrect results?
You say A and E quantifiers can be used.
Can arbitrary mathematical/logical statements be expressed?
Doesn't that make it undecidable to check the specs?
> Existential and universal quantifiers are specified as
> operators in the external structure of modules and may be used
> for describing complex LFLs.
But how are they checked?
Are there/will there be reflective proof tactics?
> OLFIS allows one to describe the logic of execution, which
> may be used for parallelizing large programs and represents a
> set of independent processes (main modules of OLFIS stored in
> the module knowledge base). [...]
I can't seem to understand what kind of parallel computation ZIRUS models.
How does it compare to say pi-calculus,
or any other well known (or traditional) parallel computation system?
PS: I fear your english is not always perfectly clear,
and sometimes I'm not sure what you mean,
though what I guess looks promising...
Surely I do sometimes suffer from similar problems :( :( :(
== Fare' -- firstname.lastname@example.org -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
TUNES is a Useful, Not Expedient System