We're using the wrong name
One of the great joys in working with Ada is strong typing and wha t we call data abstraction. We create user-defined types such as DAY OF WEEK , because now we can spell out the values we mean such as MONDAY, BLUE, SECRET , ROUTINE, etc. Now as our code becomes much more readable for everyone (particularly the program author), we are less apt to make logic and codin g errors, and the compiler will rather firmly notify us if we attempt to mi x anything of type APPLES with something of type ORANGES. But do we want t o call this activity "data abstraction"? One definition my dictionary gives o f abstraction is : "Thought of or stated without reference to a specifi c instance". Of course our English language is very ambiguous, but after reading this definition five or six times, I think it pretty well describes wha t we are trying to do with types in Ada : we have specific instances of value s such as BLUE, RED, GREEN, etc ., and we abstract the common property of al l these specific values into a thing we call "type COLOR". Very good. But wait a minute. What we are doing in Ada with typing is to avoi d using numeric codes for non-numeric things, such as 1, 2, 3 for red, amber , When we do this kind of thing by creating type COLOR, or type SECURITY CLASSIFICATION , we are not performing an abstraction on the integers, we are doin g just the opposite! If "data abstraction" is truly what you want, I'll giv e you data abstraction, it is a higher abstraction on any enumeration type you might want to make : subtype ABSTRACT TYPE is INTEGER ; Here we abstract the values of DAY OF WEEK, COLOR, or whatever, int o a common type which turns out to be the integers. Type COLOR is indeed a n abstraction of the values BLUE, RED, GREEN, but using type COLOR and it s values is not an abstraction over using integer codes .