Re: Running a preprocessor from GPS?

["Randy Brukardt" <randy@rrsoftware.com>]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:014427b1-ff7a-4a69-82e6-0330af77ed96@googlegroups.com...
> On Tuesday, July 28, 2015 at 11:12:54 PM UTC+2, Randy Brukardt wrote:
>> "EGarrulo" wrote in message
>> >boilerplate code, and this is one such case.  Let's add the lack of a
>> >facility like "printf",
>>
>> Not strongly typed.
>
> What do you mean?  Common Lisp has FORMAT and it is as strongly typed as 
> they can be.

In Ada terms, typing is something done at compile-time. Ada does not have 
runtime typing (one could imagine tag checks to be runtime typing, but 
that's a check in Ada, not related to typing).

>> >along with a generic type system that can't perform basic type 
>> >inference,
>>
>> Would have to weaken the type system.
>
> Do you mean that the compiler is not able to infer the type referenced by 
> the access type in
> Ada.Unchecked_Deallocation` because that would weaken the type system?

That's not type inference by my understanding of the term. That's just a 
lack of default parameters for generic types (something that I proposed back 
in the Ada 2005, but died mainly because of a lack of appropriate syntax). 
Nothing would be inferred, any more than the number of lines output by 
New_Line is inferred.

Anyway, I can't recall any time in my entire history of Ada (goes back to 
1979) where anyone voiced the opinion that the redundancy in 
Unchecked_Deallocation is a real problem. You're at least 35 years too late 
with that opinion, as Ada.Unchecked_Deallocation goes back to Ada 80 and 
probably before that. There's no chance in heck that it would be changed 
now.

And on the list of annoyances in Ada, this is *waaayyyy* down the list. #1 
for most people is the visibility of operators. Another thing that it is way 
too late to fix (and lots of effort has been expended in trying to find a 
compatible fix).

>> > and I am beginning to understand why engineers opposed the adoption of 
>> > Ada
>> > by the US Department of Defense.
>>
>> Ada is not for people that want to write quick sloppy code (and then 
>> debug
>> it for months).
>
> Wanting to write sloppy code and wanting to write only what is necessary 
> are
> two different attitudes, don't you agree?

What *you* think is unnecessary might be very valuable in someone else's 
context. And they'd view it as "sloppy".

>> Besides, the C++ generics that you are implicitly referring
>> to didn't exist until long after Ada was designed. And they do things 
>> which
>> would destroy the Ada contract model of generics (in C++, generics are
>> glorified macros).
>
> Ada generics are fine -- I see no difference in expressiveness versus C++, 
> really -- but
> the standard library doesn't seem to make the most of them.
>
> Generics *are* glorified macros anyway, in a sense.

This is an especial sore point with me!

Formally in the Ada RM they are, which causes all manner of nonsense effects 
which then get erased by special rules. Stupid.

For Janus/Ada at least, there is nothing macro-like about them: the code 
(including the elaboration code for the specification) is fully shared, and 
it's the processed declarations that are duplicated for an instantiation, 
the source code is not involved in any way.

The language should have been defined describing the entities as being 
duplicated, not the source, since that's what happens anyway (binding 
happens when the generic is compiled, so in no sense are you duplicating 
identifiers).

C++, OTOH, is almost purely a syntax duplication; binding occurs in the 
instance, not in the original generic declaration. So the effect is very 
different, especially in terms of debuggability (one can reason about Ada 
generics because the properties of everything other than the generic formals 
are the same for all instances, and the properties of the formals are quite 
constrained; that really doesn't work in C++).

                                  Randy.