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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,dea2d62ab1462538 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!h9g2000yqa.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Writing an Operating System in Ada Date: Wed, 13 Jan 2010 14:50:50 -0800 (PST) Organization: http://groups.google.com Message-ID: References: <8e9bc311-7540-40a1-b19e-49e93648c25c@s31g2000yqs.googlegroups.com> <9oyblld05omh$.1dzhmyoseeb7x$.dlg@40tude.net> <414945fd-8ed5-4f42-a237-0685602332b3@f5g2000yqh.googlegroups.com> NNTP-Posting-Host: 75.161.14.239 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1263423050 4510 127.0.0.1 (13 Jan 2010 22:50:50 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 13 Jan 2010 22:50:50 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: h9g2000yqa.googlegroups.com; posting-host=75.161.14.239; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 4.0.20506),gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:8737 Date: 2010-01-13T14:50:50-08:00 List-Id: > > If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005 > > interfaces handle that pretty well. > > There shall be no interfaces at all. Ada 95 had everything needed, i.e. > abstract types. Introducing interfaces in Ada 2005 was a huge mistake. Why do you say that? I see them as just being a contract for functions/ procedures that some object must provide, and in that sense there is no reason why an actual object-class cannot agree to one or more of these 'contracts'. One nice thing Delphi did was to allow an interface to be implemented by a field of the class, they called this "interface delegation" and looked something like this: Type TExample = Class(TObject, IDelegated) private DelegationField : TSomeDelegatedObject; public property Delagator : TSomeDelegatedObject read DelegationField write DelegationField implements IDelegated; end; //Example I suppose you could call it 'subcontracting'. > >> Marshaling? In terms of ADT it is assignment. Create a local object of the > >> type. Assign the remote object to it. Done. > > >> Provided you have the assignment defined. > > > What happens when the network is disrupted in the middle of an > > assignment though? > > An exception Good point. > (in Ada it is Program_Error, which must be changed. This is one of Ada's > problems, which make it less suitable for designing an OO OS. > Initialization, Finalization and Assignment do not roll back) > > > Is the assignment atomic? > > In the same way Adjust is. > > > If it's a large store of > > data is it resumable, or does having a large file on a flaky server > > doom you to never being able to retrieve the data? > > If you have no CPU fan, can you run the computer? These are silly > questions. There are certain preconditions for certain services to work. > You cannot access remote objects when the network is down. So what? That depends if the hardware requires it, older system boards didn't have the power-supply coupled to the fan. And there are plenty of [small] system-boards that don't have fans, like the HC11 I played with. So, I suppose the best answer would be: "It's a matter of design." > > >>> Did I mention that you might want to move you whole hard drive to > >>> another machine as well? :-) > > >> Did you try? What happens with a NTFS drive in a Linux system? Can you > >> mount it as an ext4? > > > Ah, here you're confusing "is a" and "has a" because the drive itself > > is NOT a file_system, but it may have one [or a part of one]. You can > > think of the file system as a format-for-the-data. So, like some > > people have done with compression/encryption and made an abstract base > > to derive from we can do the same with file-systems. > > I don't see how this is related to the point. Both NTFS and ext4 are file > systems, which by no way helped to access one where only another is > supported. The same is true for any type of the objects. In order to move a > piece of memory containing an object from one system to another, the > representation of the object there must be understood. > > >> This is not a question of objects or raw blocks. If the OS recognizes the > >> pluggable component, there is no problem, > > > Nope. The OS can detect a perfect & compatible drive and yet be > > mystified by its contents because it doesn't understand how to read > > it. > > What was recognized then? The physical drive itself.... it has to be recognized in order to get the "do you want to format?"-style message in the first place. > > > If the drive is a dictionary, the entries are the particular files/ > > directories/objects thereon, but it is pretty useless to give someone > > a dictionary in a language they can't read. > > No, it only means that the object called dictionary is supported and other > objects called articles are not. The same error was made by the relational > data bases, they understand the structure of relations (relational > algebra), but do not do the elements of the tuples. I think we have a failure-to-communicate here. I agree that relational algebra [blindly] works on tuples w/o knowing about the contents... that is in a sort of abstract fashion. If we use metaphor/allegory for the data-system [hard-drive, FS, data] would you agree that it could be likened to the following? The hard-drive is like unto a library containing books. The books of that library are like unto the data/files. The FS is like unto the indexing system (alphabetically by title, alphabetically by author, dewy-decimal, etc) coupled with the methodology for storing the 'books' (are they in boxes, on shelves, in a pile, etc). Can we both agree on this? > >> Note that the file system itself is built on a layer of blocks and sectors. > >> So if your argument worked, there would be no need for a file system. We > >> would still read sectors and count drive heads... > > > Oh please don't say that the best way to reference disk-data is by > > (sector, block) direct access... I'd prefer to have my hardware a > > little more intelligent than that, and have my CPU available for > > things other than calculating location-offsets. > > It is the hardware to determine how low the abstraction can be. No lower > than 0. The upper bound does not exist. If the argument is that no > abstraction is needed, here is the device controller for you. Enjoy it. > Otherwise, one have to argue why read/write is high enough and "read text > buffer line" is too high. Obviously both are not. I think I see what you're saying here, but abstraction _is_ one of the "big ideas" in computer science. If we're speaking of the hardware- interfaces we can see that there are some decided advantages to abstraction, take SCSI for example: SCSI devices transfer data on a higher-level than IDE by way of the SCSI-commands & the SCSI-protocol (which allows the host to reorder requests for optimal service). The only reason you need drivers for a SCSI card is so that SCSI-host and the OS can communicate. This is done in a manner very similar to Ada's spec/implementation divide. In our data-system/library example this would be like a professor telling TA "go get me such-and-such book". (The CPU playing the role of the professor & the SCSI-hose as the TA.) Perhaps the problem of miscommunication from earlier was due to misconstruing what I was trying to say regarding a "file-system- object" and its role; the role I'm thinking of is that of, in the aforementioned metaphor, would be the librarian... that is someone who knows how to read index-by-title/author/decimal (FAT32/ext4/Reiser/ etc) AND knows how to map that index into actual location (shelf/box/ etc). > >>> There is a reason why none of the pure-OO-OS-let's-do-it-correctly > >>> ever really took off. > > >> Yes. There are many reasons. For all there is no consistently designed > >> OOPL, Ada included. > > > Ada is one of the most consistently designed languages I've come > > across {LISP is another}, so if your argument is valid it should be > > more doable in such language[s] than in other languages. > > Agreed. > > >> Without MI, MD, tagged tasks, there is no chance to get > >> it right. > > > > If MD is multiple dispatch then we're talking about something that > > simply explodes combinatorically-speaking: Say we have a multi- > > dispatch procedure with two dispatching parameters [Letter and > > Number], ok? Now, if we have two versions of each of those in the > > classes we get something like: > > (A,1) > > (A,2) > > (B,1) > > (B,2) > > Yes. Let you have printer devices and shapes. This is a classical example > of MD. Yes, it explodes. That is the law of nature. There is nothing to do > about it, with MD support or without it, you have these combinations, you > have to handle them. MD does not solve this, it merely provides an > infrastructure helping you to solve this. No more, no less. Ah, I think I was confusing the problem with that infrastructure then... But that does remind me, I was thinking it would be good to have PostScript as the display for the OS, unifying the visual display that way it would eliminate the need for printer drivers (assuming they're postscript printers) as well as providing a true WYSIWYG for print- preview (MS's print preview can be a bit... inaccurate), right?