Re: Progress on AdaOS

[Darren New <dnew@san.rr.com>]

David Starner wrote:
> On Wed, 29 Aug 2001 16:42:55 GMT, Darren New <dnew@san.rr.com> wrote:
> > Why is strong typing good in a programming language and bad in
> > persistant data?
> 
> Because I don't usually end up trying to debug persistant data
> several months later, searching for one small minor bug.

But you debug the programs that generate it. I'd guess half of
accounting involved debugging persistant data. :-)

> > OK, so you're only solving half the problem here. The content-type on
> > the file isn't sufficient to figure out what you can do with the file
> > without reading the data. Why bother with it at all?
> 
> Most problems are unsolvable in the general form. It's basically an
> extension of the Halting problem. We can't completely optimize code,
> but we can try our best.

But that answer doesn't address the question. Why bother with data
typing that's insufficient to tell you how to work with the data? What's
the benefit of tagging data as COBOL source or Postscript at the file
system level if you can look at the data in the file and get a more
robust answer?

> >> What happens
> >> if you change it from Ada to Chill?
> >
> > Then you have to figure out how to serialize it or figure out how to
> > translate it without serializing it. Always coding every single program
> > to the worst-case conditions is going to lead to all kinds of problems.
> 
> Is changing the language on a project really that rare? Deciding you
> can't do it in JavaScript, and go with Java or Ada? Find that you
> need to support Linux, so you change in from VBScript to JavaScript?

Firstly, there's two assumptions I'm making. One, that a new OS written
in Ada would use Ada as its primary programming language, taking full
advantage of everything Ada has to offer. There's not a whole lot of
point that I can see in building, as a hobby, an AdaOS that compiles and
runs POSIX C programs right off the bat. Naturally, if you want to stay
compatible with all the assumptions that a C program written for UNIX
makes, you're going to wind up reinventing UNIX, and why bother with
that?

Secondly, I'm assuming that it's OK (because of the first assumption) to
change fundamental conceptual organizations. For example, it is possible
in the OS I'm thinking about to run a program indefinitely. Note, not
until you turn the power off. Not until you upgrade the OS code. Not
until you buy a new computer. Indefinitely. Forever. As long as you want
to keep porting the OS. Given this assumption, why bother serializing
your data every time you use it? If an image "file" was represented as a
collection of routines to get the width, height, and pixel data from an
image, why would you even care what the internal structure is?
Especially if there was also a function you could call that says "give
me back a JPEG (JFIF) stream representing the image" *and* a routine
that says "give me back a GIF stream representing the image"?

> >> How does the editor know what type
> >> to create?
> >
> > You tell it. Same as now.
> 
> So you can create new types on the fly?

Sure. That's kind of inherent in any file system, yes? I'm pretty sure I
can store Ada-95 sources on a FAT12 file system. How does *your* editor
know whether you're working with an Ada-95 source file or a COBOL source
file? You tell it, or you tell it how to distinguish between the two
based on contents or file name.
 
> >> However, the internal format for Emacs has been known to change
> >> between versions. It's hard to keep internal structures the same; much
> >> easier to conform to a consistent external standard.
> >
> > Errr, and the point is?
> 
> The point is that if you dump the internal structures for version a,
> and try to load it with version b, it won't work.

See assumption 2 above. You don't "dump" internal structures. 

> If you save a file
> as ISO-8859-1 plain text, and try to load with a different version,
> it will, even if b is a lot earlier than a.

Err, no, not really. If you save a Ada95 program in ISO-8859-1 and try
to compile it with an Ada83 compiler, it's not going to properly
recreate the internal structures.

You may be so used to serializing data and making sure you get *that*
part very correct that you don't realize just how much everyday effort
goes into such. Think about (say) your mail client. How much effort goes
into it parsing the MIME messages every single time you look at it? Of
course, if you want to switch to another mail client, you pick "export
mailbox as MH-format" or some such, then suck it into another client.
But how often do you really do this?

> >> Also, I've worked with programs that used a database and those that use
> >> plain text files, and the latter seem more reliable.
> >
> > Sure thing. Tell this to the folks running the airline reservation
> > programs.
> 
> Why do I care about the airline reservation programs? Maybe if I was
> dealing with the volume and amount of data they do, and I had the money
> to shell out for a decent database and the people to keep it working,
> I might.

My point was that saying a text-format database is more robust than a
more sophisticated database is kind of pointless. It's certainly not
more robust when you have the needs of a customer something like the
airline reservation industry. I'm honestly not sure what your point was
in talking about the database stuff to start with. I'm not saying you
should serialize binary data with the OS. I'm saying you shouldn't need
to serialize things at all. 

In other words, why should a file be an array of stream elements? Why
shouldn't the concept of "file" be an instantiation of a generic
shared_passive library unit?

> This has been a lot less productive than it could have been. I have been
> reading what you've been writing. This just happens to be so far out of
> my experiance that I'm not getting what you're saying.

My apologies. It takes a number of examples to see where the benefits
can be. I'm not even sure that EROS is the best example. Another good
example is Hermes, as described in "Hermes, a Language for Distributed
Computing." (Which is unfortunately out of print.)

> Part of the
> problem is I've been falling into an argumentative mode; but it would
> have been real helpful if you explained things up front - gave a
> definition of file from the start, for example, or maybe some
> references, web or book.

The reference to the EROS project earlier in the thread is a good place
to start thinking about this.
http://www.eros-os.org/essays/capintro.html
For example, in EROS, files don't have names. You get a (weak) pointer
to a file when you create it. You give that pointer to whoever else you
want to have that file. Since your program never has to exit, you never
have to worry about losing the pointer.

I thought I'd given some decent examples of other ways to make files,
such as
> Imagine an OS where "files" are actually protected objects, fully typed,
> that outlive your program's execution. Directories are simply persistant
> protected objects that act as arrays mapping strings to these "files".

The idea was that you would declare a library as pragma shared_passive,
and you could access the data structures managed by that library when
you started up your program (or a different program) again. 

I thought I had also mentioned the idea of a persistant storage_pool,
whereby you could name a storage pool, allocate things in it, exit,
start a different program naming the same storage pool, and access the
things previously allocated.

-- 
Darren New 
San Diego, CA, USA (PST). Cryptokeys on demand.