Language change proposal

[Richard A. O'Keefe]

"Robert Virding" <robert.virding@REDACTED> wrote:
	But I still say the preprocessor should never have been added.
	Richard where is the Ada reasoning about a preprocessor
	described?  If I had been able to come up with Richard O'Keefe's
	Abstract Data Types this would have been a much better solution.

The requirement was stated in Steelman 2C.
(http://www.adahome.com/History/Steelman/steelman.htm#2)
    2C. Syntactic Extensions.  The user shall not be able to modify
    the source language syntax.  In particular, the user shall not be
    able to introduce new precedence rules or to define new syntactic
    forms.

Basically, they didn't want an extensible language (like Algol 68 or CGOL,
which let you introduce new operators, or like Pop with its templates
which I actually found very nice to use).  If we are going to talk about
return on investment, that's precisely what this is all about.  They wanted
to make sure that there were no unnecessary barriers to building tools that
could analyse Ada source code, and that every maintainer would be reading
the same language.

I find the fact that I can't build an Erlang analysis tool without
having to emulate all that preprocessor fertiliser incredibly sad;
put the preprocessor and records together, and you've roughly doubled
the size of a simple tool.  Yes, I know it's easy if you do it in Erlang
using the appropriate existing module.  But that simply emphasises how hard
it is to do it any _other_ way.

>From http://www.faqs.org/faqs/computer-lang/Ada/programming/part3/
question 8.7:

.7: Does Ada have macros?

   No, neither Ada 83 nor Ada 95 do. There was a Steelman requirement
   that the language developed NOT have a macro capability. This was a
   well thought-out requirement. What you see in a piece of Ada code is
   what you get (within a debugger for example). This does not hold true
   for macro languages.

   General text-substitution macros like those in the C preprocessor are
   thought to be too unsafe. For example, a macro can refer to a variable
   X and depending where the macro is expanded X may or may not be
   visible. Ada programs are supposed to be readable and in many cases C
   macros are the main culprits in producing unreadable C programs.

   Compile time macro facilities tend to be dreadfully over- and misused,
   resulting in horrible maintenance problems. Furthermore, there is a
   tendency to use macros to patch up glaring omissions in the language.
   For example, C has no named constants, a very bad omission, but
   #define is used to patch over this gap.

   In C, three "legitimate" uses of macros are for defining compile-time
   constants, types, and inline functions. Ada has all three of these
   facilities, without macros.

   If one wants macros to handle conditional compilation, the better way
   to achieve the equivalent is in most instances to isolate the system
   dependent parts and then put them in separate units with multiple
   system-specific implementations.

Because Erlang has pattern matching, inline functions are not quite good
enough to handle compile-time constants.  That's what Abstract Patterns
were invented for.  Cross-module inlining would be made possible by the
-import_early directive I once described.

	This is why you need guardians so that it will be clear and
	consistent.  As I have said before one of our, the original
	implementors, main faults was not actually explaining and
	writing down our basic concepts.  To us they were so clear they
	need no explanantion.  Of course sometimes we weren't in
	agreement as to the concepts.  :-)

It's surely not too late to write them down now.