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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1dd28d5040ded1f8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-17 01:33:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!130.133.1.3!fu-berlin.de!uni-berlin.de!pec-71-49.tnt4.hh2.uunet.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Announce: Grace project site operational Date: Fri, 17 May 2002 10:35:01 +0200 Message-ID: References: <4519e058.0205140718.3ddb1b2a@posting.google.com> <3CE15D0A.3050100@mail.com> <2s44eu0fm4g6606h9p4stb1b5oc0nmg5u8@4ax.com> <3CE2A946.5030808@mail.com> <3CE40B8E.70102@mail.com> NNTP-Posting-Host: pec-71-49.tnt4.hh2.uunet.de (149.225.71.49) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1021624402 23357947 149.225.71.49 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:24251 Date: 2002-05-17T10:35:01+02:00 List-Id: On Thu, 16 May 2002 15:42:06 -0400, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> In short, generics are macros. > >In exactly the same sense that FOR loops are GOTOs. In which sense? For and goto are language constructs. Generics are rather meta-language (preprocessor's language) constructs. The idea of a generic is: let's substitute A for X and see if the compiler will eat that. Macros substitute arbitrary strings. C++ templates substitute arbitrary types. Ada is much better in that respect, but is still bad. If you consider Ada generics from ADT point of view, i.e. how actual paramters match formal ones, you will note that it is strong typed, but has no user-defined types (of formal generic parameters) at all. All types are built-in: (<>), range <>, digits <>, etc. C++ templates are simply untyped, substitute'n'pray. >> Generics are bad for units because they enforce dimensioned > > values be of unrelated types. > >Why is that bad? Because dimensioned values are not unrelated. Their types are siblings, having a common supertype, and very often we need objects of that supertype. > > For instance, a discriminant-based variant: >> type Measure (SI : Unit := Unitless) is record >> Gain : Number; >> end record; > >In all Ada versions that anyone here has ever mentioned, >this drags along a discriminant as part of the object, Yes it is an unfortunate feature of Ada [C++ is not better], which tries to treat subtypes as things having same representation. Once language designers drop this IMO unnecessary limitation, they will say, that an unconstrainted subtype of Measure shall keep the discriminant, while a constrained one shall not. Same with tags, class-wide objects have one, specific ones do not. End of story. >making it bigger. That's no problem, your macro expansions (:-)) will probably eat even more. The real problem is that it is slower. My implementation of measurement units is approximately 4 times slower as compared with pure floating-point arithmetic. (:-() >> X := Y; -- Constraint_Error >> >> A decent Ada compiler should give you warning at compile time. > >In the type-based version, it *must* fail at compile time. Just set warnings = errors in your IDE. >> How do you write a Put for dimensioned values? It shall be class-wide >> = work on all unit [sub]types. Do you want to make it generic and >> instantiate each time? > >Yes, I would make it generic and instantiate each time. How big will be your application, if all possible subroutines dealing with units will be instantiated? >In C++, of course, the instantiation would be done for me. >Here's what it would look like for a simple gram-centimeter-second >system. All of the 'if' tests in the code below are static at >compile time, so they will not consume any runtime. It will consume memory at run time. Your system will be too big. You will be unable to put the things into a library, because, well, generics are macros. You will be unable to write some applications at all. Consider a unit-aware calculator. How to implement it with generics? >> There is a roller dynamometer. > >Shrug. Yes, if you really have a system where everything is >completely dynamic, then a type-based solution will be difficult >or perhaps impossible to use. On the other hand, I'm guessing >that most people's sensors stay put and measure one thing. Yes, but a sensor is usually attached to the system via an A/D converter, which are expensive. So customers routinely reuse their converters by re-attaching different sensors to the system: today a temperature sensor, tomorrow a pressure sensor, etc. But the main problem is virtual instuments. Should we instantiate all of them for all necessary units, the system would probably require a cluster of supercomputers. (:-)) The moral of the story is that no real system uses 100% static or 100% dynamic checks. It is 20/80 or 80/20 depending on the application. Therefore an ultimative solution shall effectively support both. Generics cannot help us in that, they are doomed to be static. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de