[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: File formats
- To: Tuomas Lukka <lukka@xxxxxxxxxx>
- Subject: Re: File formats
- From: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Date: Mon, 18 Sep 2000 20:56:42 +0200
- Cc: zzdev@xxxxxxxxxx
- References: <Pine.HPP.3.96.1000908152028.7892D-100000@xxxxxxxxxxxxxx>
> > - A possible compression algorithm would be to store the code of the ZZ
> > system in the space -- esp. after bootstrapping -- so that we really
> > *know* what this call did at this time.
> Hmmm.. an interesting idea. But you need an abstract representation, since
> you want to be able to use it on different platforms. But the abstract is
> one step behind the not-abstract. Could it really work?
I don't think it needs to be compatible: I only think of it as a
compression algorithm. When you wrap up part of a space so that you can
use it outside your system, you can be concrete and store the actual
> > - We would then write "deterministic calls" to the file as one single
> > record. "Deterministic calls" are calls which do the same every time
> > they are executed in the same zz space ("read the file tree into a zz
> > structure" would, for example, not be a deterministic call).
> Sorry, I don't follow you here.
The idea is that a system is deterministic iff its development over time
is always the same from any given situation, regardless of the system's
context; which implies that when you know one state of the system, you
can compute all which follow later.
A deterministic call, then, is a call which, whenever executed in the
same zz space, does the same (because for the time the call is executed,
the zz space as a system is deterministic: the static zz universe gets
dynamics, "laws of physics," which change it predictably). These calls
we store as a whole, only giving the params to pass to the call.
A call like "read the file tree," on the other hand, is not
deterministic, because what it does depends on the context, the
environment of the zz space at the time of the call. We therefore, if we
want to ensure consistency, have to store what the call actually *did*,
instead of just storing that we called that function.
Anyway, I'm not sure how effective this kind of compression is; at the
moment we can't do it anyway, so let's forget about it. *g* Maybe after
bootstrapping we can make something out of it.