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: Maciej Sobczak on 14 Jan 2010 16:50 On 14 Sty, 11:28, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > But I do not see how the OO approach would solve that problem. Plug > > the OO-aware drive from the OO-aware system from Microsoft into your > > OO-aware system of choice and you will be in the same mess. > > Sure. But your argument was that a file system would handle it better. It > does not. The file system handles the data exchange between systems that were written with different paradigms in mind. Your objects would be transportable only between OO systems. That would be a huge portability limitation for me. In this context, the advantage of the file system is that it does not impose any assumptions about the OS itself. That's why my USB stick works everywhere. > What is the opposite paradigm? I don't care much about OO, I do about ADT. > The real alternatives are typed vs untyped. I think we have been using the > latter for too long and it won't stand up safety and quality requirements > of future omnipresent computing. I'm afraid that the omnipresent computing will bring us omnipresent untypedness - or at least this is the current trend, if popularity of programming languages is to be taken as any indication... -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada
From: Randy Brukardt on 14 Jan 2010 20:24 "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:1fhgwtz4ezt52.zvep41elk4lq.dlg(a)40tude.net... > On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote: .... >>> You have to be able to derive from a task, that is what active objects >>> are. >>> BTW, you already can do this in Ada 2005. It has task interfaces, but >>> this >>> inheritance is limited to have the depth of 1. >> >> I remember reading that now... but is an inheritance level of 1 good >> enough? > > No, it is not. The bottom level is an interface, a quite useless thing > because it does not provide implementation. The next level is a concrete > implementation. The train stops there. You're confusing inheritance of interfaces with inheritance of implementation. One of the most important parts of Ada is that it tries to strongly separate interfaces and implementation. [I know you know this difference, but are purposely ignoring it.] You can have as much inheritance of interfaces as you want (as you showed in your read/write example). Ada doesn't allow inheritance of implementation for synchronized objects, for the very good reason that no one knows how to make inheritance rules that doesn't violate the exclusion and ordering rules. We tried for a quite a while to make a version of inheritable protected types, but it always led to deadlocks, race conditions, or loss of exclusion. (Java has this problem in spades.) We looked at some ideas for very limited inheritance, but it would have been quite complex. We didn't think anyone would understand the rules (they surely were not intuitive). By not allowing inheritance at all, we keep all of the mutual exclusion in a single object where analysing it for problems is at least possible. Since subprogram calls are possible for the sequential code, it doesn't necessarily have to be duplicated (although most of the synchronized interface objects that we see are quite simple, as anything complex is pretty much a lost cause at the start). Someday the state of the art might change; by not doing anything in Ada 2005 we left open the possibility for doing it right (whatever that turns out to mean) in the future; had we done a lousy job in 2005, we couldn't have replaced it in the future without breaking a lot of existing code (which we won't do). Randy.
From: Dmitry A. Kazakov on 15 Jan 2010 03:37 On Thu, 14 Jan 2010 13:50:56 -0800 (PST), Maciej Sobczak wrote: > On 14 Sty, 11:28, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > >>> But I do not see how the OO approach would solve that problem. Plug >>> the OO-aware drive from the OO-aware system from Microsoft into your >>> OO-aware system of choice and you will be in the same mess. >> >> Sure. But your argument was that a file system would handle it better. It >> does not. > > The file system handles the data exchange between systems that were > written with different paradigms in mind. > Your objects would be transportable only between OO systems. That > would be a huge portability limitation for me. You can always serialize object. Call it a blob. The problem is what do you do with the blob beyond undoubtedly enjoyable moving it for one memory stick to another. Because your file system has completely nothing to do with the contents, there is neither any gain nor any loss. > In this context, the advantage of the file system is that it does not > impose any assumptions about the OS itself. How so? It requires the file system to be implemented on each OS you wanted to attach the device to. > That's why my USB stick > works everywhere. No. It does not under MS-DOS. Did you try to write a movie file on a stick? (FAT has limitations on the file size). >> What is the opposite paradigm? I don't care much about OO, I do about ADT. >> The real alternatives are typed vs untyped. I think we have been using the >> latter for too long and it won't stand up safety and quality requirements >> of future omnipresent computing. > > I'm afraid that the omnipresent computing will bring us omnipresent > untypedness - or at least this is the current trend, if popularity of > programming languages is to be taken as any indication... Is there an increase in the number of commercial projects done in those languages? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 15 Jan 2010 03:59 On Thu, 14 Jan 2010 19:24:41 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message > news:1fhgwtz4ezt52.zvep41elk4lq.dlg(a)40tude.net... >> On Thu, 14 Jan 2010 13:07:08 -0800 (PST), Shark8 wrote: > ... >>>> You have to be able to derive from a task, that is what active objects are. >>>> BTW, you already can do this in Ada 2005. It has task interfaces, but this >>>> inheritance is limited to have the depth of 1. >>> >>> I remember reading that now... but is an inheritance level of 1 good >>> enough? >> >> No, it is not. The bottom level is an interface, a quite useless thing >> because it does not provide implementation. The next level is a concrete >> implementation. The train stops there. > > You're confusing inheritance of interfaces with inheritance of > implementation. One of the most important parts of Ada is that it tries to > strongly separate interfaces and implementation. [I know you know this > difference, but are purposely ignoring it.] I don't ignore it, I point out that interface inheritance requires no interfaces (nor even abstract types). There is no problem to inherit the interface of a concrete type. Concerning separation of interface and implementation, I think that Ada 2005 interfaces in fact deviate from the model existing since Ada 83. In Ada 83-95 the separation was never based on types. The separation then was carried by packages. The programmer could choose between moving parts of the implementation into private parts or else into the body. Incomplete type declaration was the interface. It was simple, understandable, required no extra up front work. Compared to this interfaces are complex, verbose and superfluous. Yet they cannot replace the old model anyway, because there are things like constants and bodies which are not types, yet have implementations to separate. > Ada doesn't allow inheritance of implementation for synchronized objects, > for the very good reason that no one knows how to make inheritance rules > that doesn't violate the exclusion and ordering rules. We tried for a quite > a while to make a version of inheritable protected types, but it always led > to deadlocks, race conditions, or loss of exclusion. (Java has this problem > in spades.) Nobody says it will be simple... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Maciej Sobczak on 15 Jan 2010 16:05
On 15 Sty, 09:37, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > You can always serialize object. Call it a blob. That's exactly what I'm doing right now - and that's why I do not see any added value from pure-OO approach. > The problem is what do you do with the blob beyond undoubtedly enjoyable > moving it for one memory stick to another. Nothing, because as long as the blob is on the stick, there is nothing else I might want to do with it. The blob becomes useful only when it is loaded into memory. > Because your file system has completely nothing to do with the contents, > there is neither any gain nor any loss. The added value is that of name resolution. I can name my file (OK, blob) as "my_homework_program.adb" and this intermediary naming layer helps me with recognition of the content - otherwise I would have to deal with sector numbers. The added value is exactly the same as that of DNS, so that I do not have to type in the IP address of the newsgroup service that I'm using right now. The purpose of the file system is to bring understanding to the digital mess and the current file systems do their job pretty well. > > In this context, the advantage of the file system is that it does not > > impose any assumptions about the OS itself. > > How so? It requires the file system to be implemented on each OS you wanted > to attach the device to. And the fact that my USB stick works everywhere shows that this assumption is realistic. The assumption that the target OS is pure-OO would not be. > > That's why my USB stick > > works everywhere. > > No. It does not under MS-DOS. http://www.theinquirer.net/inquirer/news/1046069/yes-usb-drivers-dos http://www.bootdisk.com/usb.htm .... > Did you try to write a movie file on a stick? > (FAT has limitations on the file size). Which is completely unrelated to what we discuss. (and lots of useful movies are short) > > I'm afraid that the omnipresent computing will bring us omnipresent > > untypedness - or at least this is the current trend, if popularity of > > programming languages is to be taken as any indication... > > Is there an increase in the number of commercial projects done in those > languages? Are you sure you are still living in a world where "commercial" (whatever that means) is equivalent to "leading"? -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada |