Writing an Operating System in Ada
in [ADA]
|
Prev: GNAT requires body of generic unit to be present at build?
Next: ASISEyes : show you the ASIS interpretation of an Ada source
From: Shark8 on 14 Jan 2010 13:01 > >> 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? > > Because there should be a honest MI and no interfaces. But Ada doesn't support honest MI. How do you propose to work-around/ implement that? Furthermore, what sort of system would you use to solve the diamond problem? Given two types, say a Clothing.Button and a UI.Button why shouldn't a clothing manufacturer be able to have a hybrid object implementing both contracts that would allow a customer to [for example] design the button they want on their clothing. (The specialized buttons for military dress-uniforms, say.) > You do not need explicitly named contracts in a language like Ada. The > contract of a type is the type itself. Agreed, you could define all the operations of both inherited types, have them as mix-in components, and handle things that way. That method however excludes the option of saying something like "if Hybrid in Clothing.Button" and "if hybrid in UI.Button" at the same time (you could inherit from one and then be able to use one of the above, true). > Ada has type declarations, public and private. Everything visible related to the type is the contract of. > Period. I agree that everything visible is the [ultimate] contract of the type. However I don't see why having an interface is any different than having as an inheritance-base a fully abstract object. Can you explain how you see it as such then? > Rather than *in advance* trying to declare all possible interfaces. It is > awful and leads to an explosion of meaningless declarations like: > > type T_Interface is interface ... ; -- Just in case we would need it! > procedure Foo (X : T_Interface) is abstract; > type T is new T_Interface with ...; -- No we starting to work > overriding procedure Foo (X : T); > > That is a mess and a maintenance disaster. That sounds like a bad idea, true. But isn't it also an exercise in misdesign to throw in "just in case we need it" haphazardly? > > 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? > > Sure. Translated to OO: FS is a specialized persistent container library. Excellent. Why then would it be a bad idea to support FS-in-the- abstract considering that currently [virtually] everyone's data is in one instance or another of this "specialized persistent container library"? It would make things easier from the migration-to standpoint. True we wold have to have a method of determining the type of some file in the absence of type-data storage, but we would have to have such in any communication with some system which didn't use types. (*cough* UNIX *cough*) > >>>> Without MI, MD, tagged tasks, there is no chance to get > >>>> it right. Couldn't we emulate tagged tasks [to some degree] by having a "Tag" entry with an output parameter giving the tag? This also brings to mind: it could be _very_ useful if libraries & programs were objects-in-the-abstract (like a task type perhaps). > >>> 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? > > Right, but in an OO system you would barely need PostScript. I doubt > anybody would like to program in PostScript, so what is left? Poor as a > data carrier, unusable for humans. Doesn't it remind something? XML? (:-)) Exactly. For visual data to the screen and printer it would make a good unified format. We don't have to actually have people programming in PostScript, just have [UI] objects know how to output it and [display] objects know how to render it... which is EXACTLY the class a PostScript printer falls into.
From: tmoran on 14 Jan 2010 13:57 > > What remote object? I just plugged in my USB stick or spun the DVD in > > the drive. > > You said you wanted to move an object. Files are rather special objects in that one often drastically changes the abstraction level at which they are viewed. Is a movie on a DVD an object? How about the .vob files that contain the actual video? If you want to do a virus scan on a .vob file, it's not a video file - it's a series of bytes.
From: tmoran on 14 Jan 2010 13:57 > Yes I do. IIRC, the project failed because they completely missed the > point. The processor was intended to be able to check the types of data > at run-time, something that the compiler had already done. Not all code is generated by Ada compilers. A secure processor could help defend against virus infections.
From: tmoran on 14 Jan 2010 14:04 > > Right, but in an OO system you would barely need PostScript. I doubt > > anybody would like to program in PostScript, so what is left? Poor as a > > data carrier, unusable for humans. Doesn't it remind something? XML? (:-)= > ) > > Exactly. For visual data to the screen and printer it would make a > good unified format. We don't have to actually have people programming > in PostScript, just have [UI] objects know how to output it and > [display] objects know how to render it... which is EXACTLY the class > a PostScript printer falls into. The desktop on my computer rarely looks similar to a piece of paper on my real desk. I doubt Postscript is an equally good description language for both. Didn't the Next computer use Postscript? And do current Macs?
From: Dmitry A. Kazakov on 14 Jan 2010 14:19
On Thu, 14 Jan 2010 18:57:24 +0000 (UTC), tmoran(a)acm.org wrote: >>> What remote object? I just plugged in my USB stick or spun the DVD in >>> the drive. >> >> You said you wanted to move an object. > Files are rather special objects in that one often drastically changes > the abstraction level at which they are viewed. Is a movie on a DVD an > object? Yes > How about the .vob files that contain the actual video? No files > If you > want to do a virus scan on a .vob file, it's not a video file - it's > a series of bytes. I don't need to scan for viruses an object which single operation is play (takes the device context as the second parameter). Virus is a problem caused by lack of typing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |