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

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Fri, 23 Jan 2004 12:16:20 -0500, "Warren W. Gay VE3WWG"
<warren@ve3wwg.tk> wrote:

>Dmitry A. Kazakov wrote:
>> On Fri, 23 Jan 2004 12:24:31 GMT, Marin David Condic
>> <nobody@noplace.com> wrote:
>> 
>>>That's why much as I might find some kind of preprocessing distasteful 
>>>and certainly don't want to watch it degenerate into the unholy mess 
>>>that you have with C, I think we need *some* mechanism for conditional 
>>>compilation.
>>>
>>>Those who argue that it should all be isolated with different package 
>>>bodies have to address the fact that a) this is often difficult or 
>>>impossible
>...
>>>and b) it implies some kind of configuration management or 
>>>build utilities that are totally outside the scope of the language and 
>>>may not exist.
>> 
>> But the language defines the notion of a library. If we could extend
>> it in a way allowing selection of a child units path during
>> compilation, then I believe, it could be 80% of the issue.
>
>Whether the problem is 50% or 20% is not the issue. The problem is
>that even if I have a 2% problem, it is a _royal_pain_(TM). If you
>have to support different implementation defined pragmas, if you have
>to support optional record components (in bindings to OS services
>or to different C libraries like readline), then whether the
>problem is big or small, it is unsolved if it ain't 100% solved.

Mmm, you know, we are happily working with a finite subset of rational
numbers, which represent 0% of all reals.

>>>I'd like to be able to hand off a collection of source code and say 
>>>"This is the main program - just compile it from there on your 
>>>machine..." If it involves different bodies, I've got to provide you 
>>>with detailed build instructions and can't assume you've got the same 
>>>tools as I do. All that gets fixed automagically if I could put some 
>>>conditional compilation statements into the code that indicate which way 
>>>to go based on some kind of directive to the compiler. (I don't trust 
>>>something in the package System to be sufficient - that at best can only 
>>>tell you about the compiler, but not necessarily about the external 
>>>platform and its potential variations.)
>> 
>> If we could limit variations to compilation units, I think we could,
>> then there might be a better way than preprocessing.
>
>As soon as you start splitting code into different parallel "files",
>you are denormalizing and decentralizing your code. This is
>maintenance hell.  If you find a bug in one of these "portability"
>unique files, then you have to edit several files to effect the
>same fix. It also much more difficult to view the impact to
>other "platforms" for such a fix.

No, this is why instead of loose conditional withs, I would like to
see abstract packages defining an interface for a path to implement.
Then a portable program will be developed in terms of that abstract
package interface. This would be, so to speak, a "package-wide"
program. Fixing a bug there will do it for all paths. A bug fixed in a
path (implementation) will by no means affect other paths.

Already in Ada one could write:

generic
   type File is limited private;
   with procedure Read (...) is <>;
   with procedure Write (...) is <>;
   ---
package Abstract_OS_Interface is
  -- Nothing here
end Abstract_OS_Interface;

Then:

with Abstract_OS_Interface;
package UNIX is
   type File is ...;
   procedure Read (...);
   procedure Write (...);
   package Interface is new Abstract_OS_Interface (File);
end UNIX;

with Abstract_OS_Interface;
package Win32 is
   type File is ...;
   procedure Read (...);
   procedure Write (...);
   package Interface is new Abstract_OS_Interface (File);
end Win32;

Now what I need is just to conditionally with/use *.Interface and,
importantly, to have a way to ensure that nothing else from the
enclosing package be visible.

The technique above works fine with subroutines having defaults. But
it becomes awkward with types and values. Worse is that one cannot
hide implementations in private:

package Win32 is
   type File is limited private;
   procedure Read (...);
   procedure Write (...);
   package Interface is new Abstract_OS_Interface (File);
      -- Error, a premature use of File!
private
   type File is limited record
      ... -- Do want them see it
   end record;
end Win32;

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de