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=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f954bcd9ffa6c26c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-18 06:10:02 PST Path: supernews.google.com!sn-xit-03!supernews.com!nntp.cs.ubc.ca!newsfeed.direct.ca!look.ca!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: Marin David Condic Newsgroups: comp.lang.ada Subject: Re: Gnat 3.13p: Command_Name RM A.15 Date: Thu, 18 Jan 2001 09:06:31 -0500 Organization: MindSpring Enterprises Message-ID: <3A66F866.AB3FD3A@acm.org> References: <200101160612.HAA06787@bulgaria.otn.eurocopter.de> <3A64593A.380F3228@mindspring.com> <94244d$ir2$1@wanadoo.fr> <3A659B05.4FA24A08@mindspring.com> <945nn4$76r$1@nnrp1.deja.com> NNTP-Posting-Host: d1.56.b8.d5 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Server-Date: 18 Jan 2001 14:08:21 GMT X-Mailer: Mozilla 4.07 [en] (WinNT; I) Xref: supernews.google.com comp.lang.ada:4152 Date: 2001-01-18T14:08:21+00:00 List-Id: Robert Dewar wrote: > I> I suppose it could be possible that the compiler vendors > > could agree on some set of enumerals and keep the list > > updated as new targets > > Totally infeasible, this would require ALL vendors to change > ALL compilers if any vendor added a new target. You can't be > serious! Remember that the enumeration type has to list ALL > possibilities. > Well, within the confines of a given vendor's domain, there are a limited set of targets, right? I'd not look at it as unworkable for that vendor to enumerate all the targets they support. Theoretically, all the combinations of host/target could be a massive number - but that's only math. In reality it is a fairly small number. By extrapolation, there are not really that many major players in the Ada compiler market. Many of their host/target implementations overlap. We are talking about, oh, say 100 or so possible enumerals? (In a practical sense, probably a lot less) And consider that vendors are not coming out with new hosts/targets every day, so there is a fair amount of stability here. So if the vendors *wanted* to cooperate on this, I just don't see it as impossible or even prohibitively expensive. They aren't required to do this, but if they perceived some value in doing so, I just don't see it as so big a problem that it couldn't be worked out. For example, if Aonix added two new machines to the list of supported platforms & made that available in some way, ACT could decide to accept the addition, reject it, or sit on it until a later date when it was convenient to add it. Nobody can force a vendor to make an update they don't want to make, right? > > > That naturally reduces product distinction and starts moving > > compilers more towards commodities, but there are > > probably enough ways of distinguishing compilers that such an > > interoperability feature wouldn't harm the business. > > Interoperability never harms business, you are looking for a > conspiracy theory here, when the fact of the matter is that > the design of System_Name is technically flawed beyond repair. Paranoia is just a kind of awareness. And awareness is just a form of love. :-) Actually, it would be an anti-conspiracy, or possibly "Free Enterprise", but that's a side bar. I was only looking at the fact that in most businesses, there is a disadvantage to turning products into commodities. It reduces profit margin. I don't think that fact is disputed by any economists. (There are exceptions - the most often cited case is the casinos in Las Vegas back around the 60's) To some extent, creating interoperability means shifting the product towards being a commodity. Not being locked in to one vendor means the consumer has more choices and can abandon one vendor for another more easily, thus increasing competition and reducing prices. Not a bad thing depending on which side of the table you are sitting on. Cooperating on System_Name is a small thing, so I don't think it impacts that situation much - as I observed. Obviously, you are free to do whatever you think is right in the process of implementing your compiler. If you think that the enumeration scheme is totally unworkable, that's your judgement call to make. I'm of the opinion that even though there are better schemes and it would be nice if the standard allowed for that, that this is what we have and making it work to some extent is not hopelessly impossible. How would you feel about simply adding a string constant to the package System? That could probably be done rather easily. System_Name remains as is, but fades away in importance. A constant of the form: Host_Target : constant String := "Alpha_VMS Alpha_VMS" ; would probably sufice. Then the end user could parse the string for two identifiers that tell him what he needs to know. It's downside is that the end user doesn't necessarily know what other possibilities exist, but in practical usage, it probably doesn't matter much. Could that be added to the standard to make life easier for everyone? MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ======================================================================