Re: Standard Ada Preprocessor (Was: why ada is so unpopular ?)

["Robert I. Eachus" <rieachus@comcast.net>]

Warren W. Gay VE3WWG wrote:
> Robert I. Eachus wrote:

>> Hmmm.  I won't say that this is not a potentially killer problem.  
>> Just that the issue has nothing to do with configuration clauses.
> 
> 
> That statement is rather strong. This kind of thing is
> handled in the C/C++ world all the time as a configuration
> item. Now we could argue whether it should or not, but
> I don't want to beat on that dead horse here.
> 
>> First let me deal with the different size issue... 

> This does work I suppose, if you add the different pragma Imports
> to do the mappings between C_Routine and Different_C_Routine to
> the same C function xyz().

Yep, I left that part out as obvious.  I still think we are violently 
agreeing.  I have no objection to using a preprocessor with Ada when 
needed, and I expect that good compilers will provide one.

> But this type of a solution can explode
> if the variations to the different versions of OS kernels is
> added. Linux for example has gone through many revisions, and
> so IMO, it is much simpler to define pid_t as a particular type,
> once and for all, once you know what it should be. If you
> had to code for these variances everywhere a pid_t was
> involved, it would be much more ugly than the
> conditional compiled solution.
> 
> But, that is _opinion_, and I expect that we'll disagree
> about that.

No, if it makes sense to export pid_t as an abstract data type, then do 
it, and the Linux version dependencies are all in that package.  If you 
only use pid_t in one or two places, then that is a waste of effort. 
Each time we work on a project, both you and I will make hundreds of 
such decisions.  I don't think it is right to force anyone to do 
something in only one "Ada approved" way.

>> Why all the dire words up above?  We used to call it "version skew."  
>> If your project depends on components and tools from more than three 
>> vendors or from the same vendor with different update schedules, you 
>> can have the problem that there may never be a consistant set of all 
>> three that works together.  That is a problem outside the ability of 
>> anyone here to fix.  All you can do is to choose the components that 
>> your project DEPENDs on, and keep that list small.
>  
> But this was my original point: if this is done successfully in C/C++
> every day, then why can we not provide the same capability
> (albiet in a better way) to compete at this same level?
> Because of the conditional compilation bias, people want
> to explain away the need for it.

I have seen many projects killed by version skew.  I could go so far as 
to say it is the number one killer of all projects, and all open source 
projects.  As you depend on more external applications/systems the 
number of potential version skew problems goes up as N(N-1)/2.  If your 
code only depends on say, GNAT, no version skew.  (Or from another 
project's point of view, one opportunity for version skew, since your 
project may not work with all versions of GNAT.

But when you have a system that depends on the OS, the compiler, a 
graphics package, a database, and a browser, N is five.  The number of 
potential mismatches is 10.  That can be dealt with in an embedded 
development project--choose a set of versions that work together and 
never change any of them.  But for an open source project you can't do that.

And that is why bringing other standards into the language and compiler 
is a win.  Every standard that becomes explicitly part of the language 
or implicitly through support by most compilers means that the compiler 
developers deal with the version skew, and you don't have to.

> Anyway, I have said my piece on this subject. I have
> no energy to flog this dead horse even more. I already
> know what I have to do ;-)

Same here.  I can't slay the version skew monster, but I can try to 
minimize the number of cases it comes up.  Where we differ is on which 
is the best way to do that.  I want to bring as many "standard" 
interfaces inside the Ada boundary as possible, you want to standardize 
the preprocessor.  As I have said before, I have no objection to that, 
as long as you don't expect the ARG to do it.

Expecting WG9 to do it is another issue, and I don't have a strong 
opinion on that, other than a PRG or whatever should be created instead 
of assigning the problem to the ARG.  Remember that in several cases 
issues have been treated exactly this way, only to eventually end up in 
the Ada standard.  For example, there was an awful lot of work done by 
the NUMWG and the NRG on math packages for Ada.  I participated a small 
bit mostly as a liason with the ARG to explain why some particular 
proposals caused other issues in the language.  Other such groups 
include the CRG (character sets) and the work done on information 
systems that eventually ended up as Annex F and decimal types.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush