TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Classic View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: "Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
From: "Coniam, Todd (MSgt)" <[log in to unmask]>
Date: Tue, 1 Dec 1998 15:45:36 -0600
Reply-To: "Coniam, Todd (MSgt)" <[log in to unmask]>
Parts/Attachments: text/plain (36 lines)
These configuration pragmas sound interesting,
but they address configuration management issues
that are easily taken care of by subdirectories
and makefiles.

As Tucker has said in various ways before, there
has to be a limit to what is part of the language.
When we add too much, we start taking away from the
rest.

There are already 38 pragmas as it is...


                              Wm. Todd Coniam, MSgt, USAF
                              Chief, Air Traffic Control Automation


        -----Original Message-----
        From:   Mike Brenner [SMTP:[log in to unmask]]
        Sent:   Tuesday, December 01, 1998 14:04
        To:     [log in to unmask]
        Subject:        RE> help with Stdcall convention (pragma
Argument_Define)

        Tucker responds that one possibility for solving the non-portability
        of the pragma stdcall under some operating systems is

           > a general capability to define a renaming for pragma arguments

        Such a pragma would also solve the problem of making portable
software
        that can switch package bodies for different operating systems or
        hardwares. A pragma USE_PACKAGE BODY ("APPLE.ADB") could be
        ARGUMENT_DEFINEd to later be "NT.ADB" or "MIPS.ADB" or
"SILICON_GRAPHICS.ADB".

ATOM RSS1 RSS2