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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e5eb8ca5dcea2827 X-Google-Attributes: gid103376,public From: mgk25@cl.cam.ac.uk (Markus Kuhn) Subject: Re: Ada OO Mechanism Date: 1999/06/08 Message-ID: <7jit97$f1b$1@pegasus.csx.cam.ac.uk>#1/1 X-Deja-AN: 487018470 References: <7i05aq$rgl$1@news.orbitworld.net> <7i17gj$1u1k@news2.newsguy.com> <7icgkg$k4q$1@nnrp1.deja.com> <3749E9EC.2842436A@aasaa.ofe.org> <7id2eo$fag@drn.newsguy.com> <3749FF7D.F17CE16A@aasaa.ofe.org> <374AC676.F7AE0772@lmco.com> <7ieuja$5v9@news1.newsguy.com> <7ifd6l$bmf@sjx-ixn1.ix.netcom.com> <7ihf6i$4hv@dfw-ixnews10.ix.netcom.com> <7jhon4$6a2$1@nnrp1.deja.com> Organization: U of Cambridge Computer Lab, UK Newsgroups: comp.lang.ada Date: 1999-06-08T00:00:00+00:00 List-Id: Robert Dewar writes: |> In article , |> Hyman Rosen wrote: |> > From a little further fooling around, followed by a trip to the Ada RM, |> > I see that objects of class-wide type can not be record components, which |> > I guess makes sense, but it doesn't seem very orthogonal to me. |> |> There is another language that you might see here in which |> String variables are generally permitted, and in that language |> you would also expect to find X'Class record components (as |> well as automatic storage management, and a generally rather |> different semantic level). This is exactly an example of what makes Ada so fascinating but also so challenging to thoroughly understand for a beginner. We have on one side simple low-level languages such as C, where the memory representation of objects is fairly completely visible to the programmer and where it is easy to realize what is going on behind the scenes. On the other hand, we have very high level languages with garbage collection such as Lisp, Scheme, Perl, Python, to some degree also Java. They hide completely from the programmer issues such as memory management and memory layout, they provide a very simple form of orthogonality (everything can contain anything), but they are because of these properties unsuitable for high-performance, low-level, real-time, and safety-critical programming. Ada goes a very rarely seen path in between these clearly separated communities. On one side it is a low-level language such as C that gives the programmer tight control over various representation issues and results in high-performance code. On the other hand it has features such as unconstrained arrays and functions that return variable-length objects that resemble closely more powerful features of real high-level languages such as Scheme and Python, but that are still implementable without the need of a garbage collector or a byte-code interpreter. Experienced programmers know a lot about how languages like C and Scheme work below the hood, but since Ada is somewhere in between, this can at first be rather confusing. Unfortunatelly, none of the textbooks about Ada talk enough about how these features (especially variable-length arrays, types with discriminators, subtypes, etc.) that are not seen much in other languages are usually implemented by compilers. I hope that one day, somebody will write an Ada textbook, that does not just state the various rules of the lannguage (which can be very difficult to remember), but that explains features such as types with discriminators and fucntions returning variable-length arrays based on examples how common compilers such as GNAT implement these. Then the restrictions of these mechanisms will become obvious and have not to be remembered as a seemingly non-orthogonal set of rules. A good paper on how GNAT implements all the features of Ada that are not obvious for a C programmer would also be a very important teaching tool in this respect. Is there anything comparable already available? Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: