From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-30 09:38:07 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!border1.nntp.aus1.giganews.com!nntp.giganews.com!news-east.rr.com!cyclone.kc.rr.com!news.kc.rr.com!news-west.rr.com!lsnws01.we.mediaone.net!typhoon.san.rr.com.POSTED!not-for-mail Message-ID: <3B8E6BDB.16D26AE8@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Progress on AdaOS References: <9IFe7.12813$6R6.1221214@news1.cableinet.net> <9lghqu$ac6$1@nh.pace.co.uk> <3B7C3293.76F49097@home.com> <9lhefg$lgd$1@nh.pace.co.uk> <3B7D47F1.25D6FC78@boeing.com> <5ee5b646.0108171856.18631c4c@posting.google.com> <3B7F624B.7294D24F@acm.org> <9lr6je$5hj$1@nh.pace.co.uk> <9ltoi7$4is$1@nh.pace.co.uk> <3B82789B.8D195045@home.com> <9ltuo8$70n$1@nh.pace.co.uk> <3B829450.879B0396@home.com> <9mdh4e$q3v$1@nh.pace.co.uk> <9me03r$c302@news.cis.okstate.edu> <3B8AB6C8.910130C8@san.rr.com> <9metfo$aai2@news.cis.okstate.edu> <3B8BC332.214F95CA@san.rr.com> <9mhmlg$9aa1@news.cis.okstate.edu> <3B8D1B8F.9BDEDC38@san.rr.com> <9mkm5m$aai1@news.cis.okstate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 30 Aug 2001 16:37:47 GMT NNTP-Posting-Host: 24.165.20.229 X-Complaints-To: abuse@rr.com X-Trace: typhoon.san.rr.com 999189467 24.165.20.229 (Thu, 30 Aug 2001 09:37:47 PDT) NNTP-Posting-Date: Thu, 30 Aug 2001 09:37:47 PDT Xref: archiver1.google.com comp.lang.ada:12596 Date: 2001-08-30T16:37:47+00:00 List-Id: David Starner wrote: > On Wed, 29 Aug 2001 16:42:55 GMT, Darren New 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.