comp.lang.ada
 help / color / mirror / Atom feed
From: Marin David Condic <mcondic.auntie.spam@acm.org>
Subject: Re: Gnat 3.13p: Command_Name RM A.15
Date: Thu, 18 Jan 2001 09:06:31 -0500
Date: 2001-01-18T14:08:21+00:00	[thread overview]
Message-ID: <3A66F866.AB3FD3A@acm.org> (raw)
In-Reply-To: 945nn4$76r$1@nnrp1.deja.com

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]
======================================================================





  reply	other threads:[~2001-01-18 14:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-16  6:12 Gnat 3.13p: Command_Name RM A.15 Christoph Grein
2001-01-16 14:22 ` Marin David Condic
2001-01-16 18:14   ` Jean-Pierre Rosen
2001-01-17 13:15     ` Marin David Condic
2001-01-17 19:12       ` Jean-Pierre Rosen
2001-01-18  3:28         ` Robert Dewar
2001-01-18 13:23           ` Marin David Condic
2001-01-18 15:15             ` Robert Dewar
2001-01-18 17:37           ` Jean-Pierre Rosen
2001-01-19 20:31             ` Florian Weimer
2001-01-18  3:25       ` Robert Dewar
2001-01-18 14:06         ` Marin David Condic [this message]
2001-01-17 19:17   ` Stephen Leake
2001-01-18  3:31     ` Robert Dewar
2001-01-18 14:13       ` Marin David Condic
2001-01-18 15:16     ` Robert Dewar
  -- strict thread matches above, loose matches on Subject: below --
2001-01-18  6:59 Christoph Grein
2001-01-18 12:38 ` Larry Kilgallen
2001-01-18 14:32   ` Marin David Condic
2001-01-18 14:54   ` Ted Dennison
2001-01-18 15:12 ` Robert Dewar
2001-01-18 12:10 Schroeer, Joachim Dr.
2001-01-18 12:19 ` Lutz Donnerhacke
2001-01-19  7:26 Christoph Grein
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox