Re: Progress on AdaOS

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

David Starner wrote:
> 
> On Fri, 31 Aug 2001 20:00:07 GMT, Darren New <dnew@san.rr.com> wrote:
> > Making a strict separation like that is exactly the kind of thing that
> > causes mental impedence mismatch. It's the same kind of reasoning that
> > says "let the language deal with processes, and save threading for a
> > library." :-)
> 
> It's also the same kind of reasoning that says "let the language deal with
> text, and save XML for a library." What should go into the OS or
> language, and what should be supplied seperately is debated fiercely, but
> something's are going to have to go out, and some in.

Right. As an aside, since XML is a serialization technique, I'd leave it
to the libraries implementing the data types.

Anyway, it *would* be libraries implementing the types of files. I'm
just suggesting that serialization isn't a necessary component of a
"file", any more than you need to explicitly load and store pages for
virtual memory in modern systems.

> > On the other hand, FORTH really *does* use *only* storage elements. That
> > means no directories and no files. Your disk really is an array of
> > storage elements. Directories are the responsibility of your code. Is
> > that really what you want in a kernel?
> 
> Not having directories in the kernel tends to mean that directories aren't
> implemented in any coherant standard way.

No more than a lack of image types in a kernel means that images aren't
implemented in a coherent standard ways. FORTH simply has library
routines to handle directories.

> There are coherant standard ways
> _that are followed consistently_ in how to store data to disk, without
> it being in the kernel.

I'm not sure what this is supposed to mean. 
 
> > And
> > thinking that knowing that the "type" of the data in the file is
> > image/gif is vital, but being willing to read the file to find out of
> > it's GIF87 or GIF89 is OK too doesn't make sense to me.
> 
> Because whether it's GIF87 or 89 is a mostly irrelevant fact, and there's
> zero chance of confusing the two once you know it's a GIF file. Some thing
> much more interesting is whether it's a picture of Robert Dewar or Tucker Taft,
> but that's something no one's talked about putting in the type.

Well, my basic point there was that if you're going to have "strongly
typed files", as suggested by the original web pages, then the ability
to treat an image file as raw bits is a bad thing. The suggestion is
that a files data type cannot change without a change in content, but
this is just wrong. Certainly I can change a file's type from raw text
to HTML on most modern systems (including the Mac) without changing the
content.
 
> > I think Ada is powerful enough to have such ideas integrated seemlessly.
> 
> See, Modula-3 did have such ideas seemlessly implemented. Which raises
> two points: one, it's evidence that there's no need to do it in the
> kernel, that it can be done in the language or libraries without kernel
> help.

Well, it depends on what ideas you mean, really.

> Second, where's Modula-3 today? (Last time I checked, with one
> maintained compiler, which is a hack on an old version of gcc, and a
> nearly dead newsgroup.) If this was so important why didn't it succeed,

I never said it was important. I simply said it might be a good idea to
think about it for an AdaOS. Personally, I don't know why someone would
think an AdaOS is important simply because it's written in Ada.

> or at least the ideas get put into languages that are used? ABC also
> had persistant variables; but when Guido von Rossum made Python with
> ABC in fond memory, he didn't include persistant variables.

I think that's generally because it's hard to do with modern operating
systems. But if you're rewriting the OS from scratch, why start with the
assumption "Nobody else has done this, so we shouldn't do it either."

Anyway, nuff said.

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