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: Dmitry A. Kazakov on 18 Jan 2010 13:08 On Mon, 18 Jan 2010 18:17:20 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov schrieb: > >> There is a common ancestor for both types. What you probably had in mind >> was a conversion is between types from independent hierarchies rooted on >> different hosts. That normally should not be needed. > > Well, I learned from the discussion that independent roots of > blobs' types it is a quite common case. No. It is rather like Node A: Numeric_Type <-- A_Integer_Type || Node B: Numeric_Type <-- B_Integer_Type (implementation) B_Integer_Type is an invisible ad-hoc implementation of A_Integer_Type. Node B uses the object from A as Numeric_Type'Class known to both nodes. If some type is unknown to B, there is no way to write a program in terms of this type. If you had a program for some unrelated type, you could not convert any object to this type. It would be a type error. An ability for example to convert Float to Integer is based on their relationship, each can be considered a subtype of another. This relationship is given, known on each node. It is possible to introduce ad-hoc subtypes, but then it is the programmer's responsibility to provide conversions, because there is no way to deduce them. This is the reason why a powerful type system is needed. You will need to describe richer relationships between types than contemporary OOPL can. Without these relationships the system would become unusable or else degrade to the low-level read/write interfaces. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Shark8 on 19 Jan 2010 13:58 > > 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? (:-)) So, what's wrong with it being used as a data-carrier? Like I mentioned before, it would be a nice uniform (and incidentally hardware-independent) data-carrier. It's not unfeasible to assume that it would make for some good low-bandwidth remote-UI as well, as opposed to X where the whole display is sent at every update (like a mouse-move/cursor-redraw update). And that it would be "unusable for humans" is a bit of a red-herring; X's data-link is even MORE unusable for humans and yet it is a fairly popular method for remote-desktop. > >> 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. What do you think of [Delphi-style] properties then? Basically they're an specification of some [virtual] field of an object [with indicators of it being readable and/or writable] that may either be renaming some internal field OR the appropriate getter/setter for a field in the implementation. I rather like the idea because it doesn't pollute the object-space with so many [publicly visible] getter/setter methods. Just to make sure there's no misunderstanding of what I'm referring to, here's the Delphi code for some person: Type TPerson = class private FFName, FMName, FLName : ShortString; {Internal Fields for first, middle, and last names.} FAge : Byte; Function FullName: String; Procedure Set_FName( Value: ShortString ); {Setter for fires name.} Procedure Set_FLame( Value: ShortString ); public Name : String read FullName; {Military Format; ex: Smith, John Q. } First_Name : ShortString read FFName write Set_FName; {Setter disallows zero-length first names.} Middle_Name : ShortString read FMName write FMName; {Zero- length middle names are allowed. } Last_Name : ShortString read FLName write Set_LName; {Setter disallows zero-length last names. } Age : Byte write FAge; {Write-only for this application/object...} end; {TPerson} IMPLEMENTATION Procedure TPerson.Set_FName( Value: ShortString ); begin IF Length(Value) > 0 THEN FFName:= Value; end; Procedure TPerson.Set_FLame( Value: ShortString ); begin IF Length(Value) > 0 THEN FLName:= Value; end; Function FullName: String; Middle_Initial : Character:= #000; {Null initial-value} begin IF Length(FMName) > 0 THEN Middle_Initial:= FMName[1]; {Get First Character.} FullName:= Last_Name + ', ' + First_Name + ' ' + Middle_Initial end;
From: Shark8 on 19 Jan 2010 14:07 On Jan 14, 12:04 pm, tmo...(a)acm.org wrote: > > > 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? That's incorrect, insofar as the hardware [your monitor] is concerned your computer's desktop is EXACTLY like a piece of paper, or rather multiple ones drawn and shown to you. For example VCR tapes run at 25 FPS, this is exactly the same as taking some twenty-five drawn frames and showing them over one second. PostScript is perfectly suitable for drawing such a frame. In fact, if you program things as being based off of vectors and shadings {something PS is GOOD at} then it's conceivable that your desktop could be independent [some caveats on low-resolutions, obviously] of resolution/color-depth keeping things relatively uniform. Just like you can use a PS file to print a good-looking big poster and use the same file to print an [equivalent] 8.5x11 poster/thumbnail.
From: Dmitry A. Kazakov on 19 Jan 2010 14:43 On Tue, 19 Jan 2010 10:58:23 -0800 (PST), Shark8 wrote: >>> 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? (:-)) > > So, what's wrong with it being used as a data-carrier? Nothing, except that there could be better ones and it is uninteresting for the programmer even to know what is actually used as the carrier. >>>> 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. > > What do you think of [Delphi-style] properties then? Basically they're > an specification of some [virtual] field of an object [with indicators > of it being readable and/or writable] that may either be renaming some > internal field OR the appropriate getter/setter for a field in the > implementation. I rather like the idea because it doesn't pollute the > object-space with so many [publicly visible] getter/setter methods. This is OK, but unrelated to MI. It about separation of implementation and specification, which was not accomplished in Ada with respect to fields. Operations of accessing members should be a primitive. What is visible as a field should be possible to implement either as a physical field or as getter/setter operations. MI is independent on this. It is about membership in more than one disjoint classes. Interface is poor-man's MI, restricted so some artificially chosen cases, which still do not save from either of non-existent MI problems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Shark8 on 19 Jan 2010 16:09
> > Aren't associations rather trivial if we derive all files from some > > base tagged-type and use the tag as the type-identifier? > > Only for -to one. But how about -to many and -to one or many or .... > > For me associations are also almost always bidirectional. > > So just a simple tag reference may not be enough and standardised ways > to navigate would be great. Good catch. There are several case that we need to be aware of: programs/operations that can take such a file as input, that produces such as output, AND the DEFAULT[s]. This could be done with a registry [database, relational] that tracks the associations. |