Running a preprocessor from GPS?

Running a preprocessor from GPS?

[EGarrulo]

I would like to add logging statements to my units.  By using GNATColl.Traces, I could add lines like this one:

if Active (Me) then
   Trace (Me, "Performing Step " & Step(...));
end if;

However, this is too verbose.  I could write all the three statements onto a single line, but that wouldn't be able to use the "Pretty Print" function of GPS.  Therefore, I must find a way to use a preprocessor macro -- instead -- that lets me write a statement like this one:

   TRACE (Me, "Performing Step " & Step(...));

Now, it seems to me that `gnatprep`  only lets you define symbol macros, not function macros, therefore `gnatprep` cannot be used here.  Is this correct?  If it is, then I must use another processor (like `m4`, for example).  But, how can I integrate an external preprocessor in GPS so that `Build` and `Build All` will perform macro expansion before compilation?  Thank you.

Re: Running a preprocessor from GPS?

[David Botton]

>> But, how can I integrate an external preprocessor in GPS so that `Build` and `Build All` will perform macro expansion before compilation?  Thank you.

Write a makefile, I've not found that any large complex system can use only GPR files so by extension GPS an IDE that uses them.

David Botton

Re: Running a preprocessor from GPS?

[EGarrulo]

On Monday, July 27, 2015 at 6:47:54 PM UTC+2, David Botton wrote:
> >> But, how can I integrate an external preprocessor in GPS so that `Build` and `Build All` will perform macro expansion before compilation?  Thank you.
> 
> Write a makefile, I've not found that any large complex system can use only GPR files so by extension GPS an IDE that uses them.

The problem is that I don't know how I could code with GPS while using a file with a different extension, because I will have to use a different extension for Ada source files, right?  I mean: since I will using an external preprocessor, I will not be editing to edit an *.adb file directly, but instead I will be editing an "input file" that will be converted to the *.adb that `gnatmake` will compile in the end.  Therefore I will have no code completion, and clicking on compilation errors will bring me to a different file.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:e610ca1e-4df6-4fbb-b3a1-ac35694d9072@googlegroups.com...
>I would like to add logging statements to my units.  By using 
>GNATColl.Traces, I could add lines like this one:
>
>if Active (Me) then
>   Trace (Me, "Performing Step " & Step(...));
>end if;
>
>However, this is too verbose.

Why? That's how it's done in Ada. The Janus/Ada compiler has literally 
thousands of trace messages like the above (we have a fancy menu system to 
turn them on and off on the fly in test versions of the compiler), and I 
don't think that they have much impact on readability.

Besides, if you're going to be writing Ada, you're going to be writing code 
that's more verbose (in many ways) than C-family languages. It might take 
some getting used to, but there is no time better than the present to 
getting used to that.

                                        Randy.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/27/2015 01:26 PM, Randy Brukardt wrote:
> "EGarrulo" <egarrulo@gmail.com> wrote in message 
> news:e610ca1e-4df6-4fbb-b3a1-ac35694d9072@googlegroups.com...
>> I would like to add logging statements to my units.  By using 
>> GNATColl.Traces, I could add lines like this one:
>>
>> if Active (Me) then
>>   Trace (Me, "Performing Step " & Step(...));
>> end if;
>>
>> However, this is too verbose.
> 
> Why? That's how it's done in Ada. The Janus/Ada compiler has literally 
> thousands of trace messages like the above (we have a fancy menu system to 
> turn them on and off on the fly in test versions of the compiler), and I 
> don't think that they have much impact on readability.
> 
> Besides, if you're going to be writing Ada, you're going to be writing code 
> that's more verbose (in many ways) than C-family languages. It might take 
> some getting used to, but there is no time better than the present to 
> getting used to that.

Also, if the OP really thinks he has to replace those 3 lines with 1 line, he
can define

procedure Checked_Trace (Me : in Whatever; Message : in String);

to do so.

-- 
Jeff Carter
"Why don't you bore a hole in yourself and let the sap run out?"
Horse Feathers
49

Re: Running a preprocessor from GPS?

[EGarrulo]

On Monday, July 27, 2015 at 11:14:35 PM UTC+2, Jeffrey R. Carter wrote:
> Also, if the OP really thinks he has to replace those 3 lines with 1 line, he
> can define
> 
> procedure Checked_Trace (Me : in Whatever; Message : in String);
> 
> to do so.

Thanks for the suggestion.  Actually, I had thought about this solution, but since messages are likely to be formatted, if they won't be logged then the time spent to format them will be wasted along with memory allocations.  But it seems that there are no simple alternatives.

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> On Monday, July 27, 2015 at 11:14:35 PM UTC+2, Jeffrey R. Carter wrote:
>> Also, if the OP really thinks he has to replace those 3 lines with 1
>> line, he can define
>> 
>> procedure Checked_Trace (Me : in Whatever; Message : in String);
>> 
>> to do so.
>
> Thanks for the suggestion.  Actually, I had thought about this
> solution, but since messages are likely to be formatted, if they won't
> be logged then the time spent to format them will be wasted along with
> memory allocations.  But it seems that there are no simple
> alternatives.

GNAT has pragma Debug[1] for this purpose.

I never found much use for it, because it is enabled by -gnata, which is
the same switch used to control assertions. There are, I suspect, more
fine-grained methods of control now[2], but I've not needed to get to grips
with configuration pragmas.

[1] https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Debug.html
[2] https://gcc.gnu.org/onlinedocs/gnat_rm/Pragma-Check_005fPolicy.html

Re: Running a preprocessor from GPS?

[Brian Drummond]

On Mon, 27 Jul 2015 07:28:33 -0700, EGarrulo wrote:

> I would like to add logging statements to my units.  By using
> GNATColl.Traces, I could add lines like this one:
> 
> if Active (Me) then
>    Trace (Me, "Performing Step " & Step(...));
> end if;
> 
> However, this is too verbose.  

Wrap the test and the string formatting into a procedure. You'll probably 
need a family of such procedures for different formats - keep them in a 
package.

Write a second package body, where every procedure implementation is 
simply "null;" and build with whichever package body is appropriate.

-- Brian

Re: Running a preprocessor from GPS?

[EGarrulo]

On Monday, July 27, 2015 at 10:26:39 PM UTC+2, Randy Brukardt wrote:
> Besides, if you're going to be writing Ada, you're going to be writing code 
> that's more verbose (in many ways) than C-family languages. It might take 
> some getting used to, but there is no time better than the present to 
> getting used to that.

I don't mind verbosity when it serves a purpose, but I have little tolerance for boilerplate code, and this is one such case.  Let's add the lack of a facility like "printf", along with a generic type system that can't perform basic type inference, and I am beginning to understand why engineers opposed the adoption of Ada by the US Department of Defense.  Requiring programmers to state their intentions explicitly is beneficial, but requiring programmers to "spoon-feed" the compiler and/or write bloated code is not.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Tuesday, July 28, 2015 at 12:30:18 PM UTC+2, Brian Drummond wrote:
> Wrap the test and the string formatting into a procedure. You'll probably 
> need a family of such procedures for different formats - keep them in a 
> package.
> 
> Write a second package body, where every procedure implementation is 
> simply "null;" and build with whichever package body is appropriate.

Thanks but this wouldn't work in my case because I want logging code to stay, while being able to enable or disable it -- and with different levels -- at runtime.

Re: Running a preprocessor from GPS?

[Björn Lundin]

On 2015-07-27 16:28, EGarrulo wrote:
> I would like to add logging statements to my units.  By using GNATColl.Traces, I could add lines like this one:
> 
> if Active (Me) then
>    Trace (Me, "Performing Step " & Step(...));
> end if;
> 
> However, this is too verbose.  I could write all the three statements onto a single line, 
<but that wouldn't be able to use the "Pretty Print" function of GPS.
> Therefore, I must find a way to use a preprocessor macro -- instead -- that lets me write a statement like this one:
> 
>    TRACE (Me, "Performing Step " & Step(...));
> 

Why not encapsulate the Trace procedure ?

procedure Trace_If_Active(Me: Some_Type; What: String ) is
begin
  if Active (Me) then
    Trace (Me, What);
  end if;
end Trace_If_Active;

Trace_If_Active (Me, "Performing Step " & Step(...));




-- 
--
Björn

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Tue, 28 Jul 2015 13:43:44 +0200, Björn Lundin wrote:

> Why not encapsulate the Trace procedure ?
> 
> procedure Trace_If_Active(Me: Some_Type; What: String ) is
> begin
>   if Active (Me) then
>     Trace (Me, What);
>   end if;
> end Trace_If_Active;
> 
> Trace_If_Active (Me, "Performing Step " & Step(...));

Because *What* must be evaluated lazily, which is not possible in Ada. That
is why the only way to do it is, IMO, as Randy had suggested:

   if Is_On (Trace_Topic) then
      Trace (Trace_Topic, <complicated expression>);
   end if;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[EGarrulo]

On Tuesday, July 28, 2015 at 1:51:45 PM UTC+2, Dmitry A. Kazakov wrote:
> Because *What* must be evaluated lazily, which is not possible in Ada. That
> is why the only way to do it is, IMO, as Randy had suggested:
> 
>    if Is_On (Trace_Topic) then
>       Trace (Trace_Topic, <complicated expression>);
>    end if;

But this means a 2/1 ratio of noise to signal.  The other way to accomplish this would be by means of a preprocessor, hence my question about how to integrate a preprocessor in the Ada build chain.

Re: Running a preprocessor from GPS?

[Björn Lundin]

On 2015-07-28 13:51, Dmitry A. Kazakov wrote:

> Because *What* must be evaluated lazily, which is not possible in Ada. That
> is why the only way to do it is, IMO, as Randy had suggested:
> 

Ah, ok.
-- 
--
Björn

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Tue, 28 Jul 2015 05:06:29 -0700 (PDT), EGarrulo wrote:

> On Tuesday, July 28, 2015 at 1:51:45 PM UTC+2, Dmitry A. Kazakov wrote:
>> Because *What* must be evaluated lazily, which is not possible in Ada. That
>> is why the only way to do it is, IMO, as Randy had suggested:
>> 
>>    if Is_On (Trace_Topic) then
>>       Trace (Trace_Topic, <complicated expression>);
>>    end if;
> 
> But this means a 2/1 ratio of noise to signal.

Actually it is 3/0 vs. 1/0. Since both are infinities there is no much
difference. Furthermore the trace expressions, in the real life, take more
than one line anyway.

> The other way to
> accomplish this would be by means of a preprocessor, hence my question
> about how to integrate a preprocessor in the Ada build chain.

Preprocessor is never a way.

You can inline the suggested wrapper and hope that the compiler indeed does
inlining than effectively will make it lazily evaluated.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[G.B.]

On 28.07.15 14:06, EGarrulo wrote:
> On Tuesday, July 28, 2015 at 1:51:45 PM UTC+2, Dmitry A. Kazakov wrote:
>> Because *What* must be evaluated lazily, which is not possible in Ada. That
>> is why the only way to do it is, IMO, as Randy had suggested:
>>
>>     if Is_On (Trace_Topic) then
>>        Trace (Trace_Topic, <complicated expression>);
>>     end if;
>
> But this means a 2/1 ratio of noise to signal.  The other way to accomplish this would be by means of a preprocessor, hence my question about how to integrate a preprocessor in the Ada build chain.

Another option is to use a folding editor that
hides things you do not currently wish to see.
It's like running a preprocessor all the time.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Tuesday, July 28, 2015 at 2:54:50 PM UTC+2, Dmitry A. Kazakov wrote:
> On Tue, 28 Jul 2015 05:06:29 -0700 (PDT), EGarrulo wrote:
> > But this means a 2/1 ratio of noise to signal.
> 
> Actually it is 3/0 vs. 1/0.

Why?  If there are 2 lines of noise for each line of signal, then the
ratio is 2/1, isn't it?

> Preprocessor is never a way.

Indeed it shouldn't.  A preprocessor is a workaround for the limitations
of a programming language.  Ideally, you shouldn't need a preprocessor,
but -- alas -- how many languages make a preprocessor redundant?

> You can inline the suggested wrapper and hope that the compiler indeed does
> inlining than effectively will make it lazily evaluated.

I can't understand what you mean here.  Would you please explain
further?  Thank you.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Tuesday, July 28, 2015 at 3:06:29 PM UTC+2, G.B. wrote:
> Another option is to use a folding editor that
> hides things you do not currently wish to see.
> It's like running a preprocessor all the time.

But in this case, the meaningful line is the nested one.  I don't know any
folding editor that supports hiding the outer level of a nested
block.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Tuesday, July 28, 2015 at 3:18:06 PM UTC+2, EGarrulo wrote:
> On Tuesday, July 28, 2015 at 2:54:50 PM UTC+2, Dmitry A. Kazakov wrote:
> > Preprocessor is never a way.
> 
> Indeed it shouldn't.  A preprocessor is a workaround for the limitations
> of a programming language.  Ideally, you shouldn't need a preprocessor,
> but -- alas -- how many languages make a preprocessor redundant?

In this case, a deficiency of Ada is that Ada doesn't allow you to
evaluate an expression lazily.  Let's imagine that Ada had a `lazy`
keyword to evaluate an expression lazily.  Then I could have written:

    Trace (Me, lazy "Performing Step " & Step(...));

without any need for a preprocessor.

Re: Running a preprocessor from GPS?

[Bob Duff]

EGarrulo <egarrulo@gmail.com> writes:

> In this case, a deficiency of Ada is that Ada doesn't allow you to
> evaluate an expression lazily.  Let's imagine that Ada had a `lazy`
> keyword to evaluate an expression lazily.  Then I could have written:
>
>     Trace (Me, lazy "Performing Step " & Step(...));
>
> without any need for a preprocessor.

That's "lambda".  It is indeed a good idea.

- Bob

Re: Running a preprocessor from GPS?

[G.B.]

On 28.07.15 15:49, EGarrulo wrote:

> In this case, a deficiency of Ada is that Ada doesn't allow you to
> evaluate an expression lazily.  Let's imagine that Ada had a `lazy`
> keyword to evaluate an expression lazily.  Then I could have written:
>
>      Trace (Me, lazy "Performing Step " & Step(...));
>
> without any need for a preprocessor.

A poor man's solution could establish a Boolean context
and then (i.e., after declaring DBG : Boolean)

   DBG := Trace(Me) and then Log("performing Step " & Step(42));


(where the Log function, if called, has the side effect of
printing its parameter.)

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Tue, 28 Jul 2015 06:18:05 -0700 (PDT), EGarrulo wrote:

> On Tuesday, July 28, 2015 at 2:54:50 PM UTC+2, Dmitry A. Kazakov wrote:
>> On Tue, 28 Jul 2015 05:06:29 -0700 (PDT), EGarrulo wrote:
>>> But this means a 2/1 ratio of noise to signal.
>> 
>> Actually it is 3/0 vs. 1/0.
> 
> Why?  If there are 2 lines of noise for each line of signal, then the
> ratio is 2/1, isn't it?

No. Call to Trace is noise, because Trace has no functional semantics.

>> You can inline the suggested wrapper and hope that the compiler indeed does
>> inlining than effectively will make it lazily evaluated.
> 
> I can't understand what you mean here.  Would you please explain
> further?  Thank you.

Inlining is like macro expansion. An expanded body is expected to have no
parameter evaluation overhead (for the parameters used only under if).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:40d6112b-4b6e-45bd-9d50-2cbf5b773d70@googlegroups.com...
> On Tuesday, July 28, 2015 at 3:06:29 PM UTC+2, G.B. wrote:
>> Another option is to use a folding editor that
>> hides things you do not currently wish to see.
>> It's like running a preprocessor all the time.
>
> But in this case, the meaningful line is the nested one.  I don't know any
> folding editor that supports hiding the outer level of a nested
> block.

No,  there is no meaningful line here. As Dmitry said, there is no semantic 
value to the trace line, so if you are working on the core code, the entire 
trace is noise (and might as well be hidden). And if you are working on the 
tracing, the "if" and "end if" provide a delimiter of where it starts and 
ends (in our uses, the tracing typically is 3-5 lines).

In any case, this is the *least* of the verbosities of using Ada. If you 
can't handle this, I suspect you can't handle good Ada code, either. Perhaps 
you're in the wrong place? (Not that I want to drive away possible Ada 
converts, but someone who does not see the value of the more verbose Ada 
syntax and semantics is not likely to be happy using Ada.)

                                 Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:2df4698f-4c8e-457c-822d-209cb2f8ab5e@googlegroups.com...
>On Monday, July 27, 2015 at 10:26:39 PM UTC+2, Randy Brukardt wrote:
>> Besides, if you're going to be writing Ada, you're going to be writing 
>> code
>> that's more verbose (in many ways) than C-family languages. It might take
>> some getting used to, but there is no time better than the present to
>> getting used to that.
>
>I don't mind verbosity when it serves a purpose, but I have little 
>tolerance for
>boilerplate code, and this is one such case.  Let's add the lack of a 
>facility like "printf",

Not strongly typed.

>along with a generic type system that can't perform basic type inference,

Would have to weaken the type system.

> 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). 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).

>  Requiring programmers to state their intentions explicitly is beneficial, 
> but
> requiring programmers to "spoon-feed" the compiler and/or write bloated 
> code is not.

"Real Ada Programmers" don't even use the shortcuts built-into Ada:
    (1) Real Ada Programmers don't use "use clauses" - objects are named by 
their expanded names;
    (2) Real Ada Programmers don't use anonymous access types or anonymous 
array types;
    (3) Real Ada Programmers don't use positional calls;
    (4) Real Ada Programmers don't use Ada 2012 conditional expressions 
(unless they need the expression to be static).
And so on.

[I'm being a bit tongue-in-cheek here. I don't quite qualify as a "Real Ada 
Programmer" under this definition, as I'll use targeted "use type" clauses 
for operators, and "use clauses" for some language-defined packages (like 
Text_IO), and for a project-specific core type package (there are several of 
these in Janus/Ada). And I definitely use positional calls 'cause I'm too 
lazy to find and write out the parameter names. But I'm surely pretty close 
to the spirit here.]

Most Ada programmers quickly find the value of the verbosity, because it 
means that the compiler can catch a lot of errors before anyone has to spend 
time debugging. But I can see that it is a hard sell, because as with many 
of the real advantages of Ada, it's not really apparent until you've used 
the language a while and realized that it detected things that you normally 
would have had to find some other way (typically, hours in a hot debugger or 
lengthy trace log).

My recommendation (as always) is to do things "the Ada way" and you'll find 
that it starts to make sense after a while. It's especially true about 
worrying about perceived "verbosity" or micro-performance (the cost of 
evaluating unused trace messages). Those things are really premature 
optimization -- a trap that we all fall into from time-to-time, but a trap 
nevertheless. They end up having no impact on the quality of the resulting 
application, and take up valuable time that could have been better used 
doing something that does impact the quality of the application.

                                      Randy.

Re: Running a preprocessor from GPS?

[EGarrulo]

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.

> >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?

> > 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?

> 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.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Tuesday, July 28, 2015 at 10:55:33 PM UTC+2, Randy Brukardt wrote:
> "EGarrulo" wrote in message 
> > But in this case, the meaningful line is the nested one.  I don't know any
> > folding editor that supports hiding the outer level of a nested
> > block.
> 
> No,  there is no meaningful line here. As Dmitry said, there is no semantic 
> value to the trace line, so if you are working on the core code, the entire 
> trace is noise (and might as well be hidden).

Trace lines can work as comments, therefore they can be very meaningful.

> In any case, this is the *least* of the verbosities of using Ada. If you 
> can't handle this, I suspect you can't handle good Ada code, either. Perhaps 
> you're in the wrong place? (Not that I want to drive away possible Ada 
> converts, but someone who does not see the value of the more verbose Ada 
> syntax and semantics is not likely to be happy using Ada.)

I don't see Ada as verbose (except for labeled "end" clauses).  Ada uses words instead of punctuation and -- by doing so -- it echoes the way I would read the code anyway.  It also requires you to be always explicit (and that is a good thing).  But here we are not talking about verbosity, we are talking about preventing the programmer from expressing his intentions clearly.  Lazy evaluation -- which can be mimicked with a macro in simpler cases -- is not some exotic feature, is it?

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 12:11:29 AM UTC+2, EGarrulo wrote:
> 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.

I forgot to say that I have discovered that "printf" can be implemented in Ada by using an operator to feed arguments to an object.  That seems a good solution.

Re: Running a preprocessor from GPS?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>     (4) Real Ada Programmers don't use Ada 2012 conditional expressions 
> (unless they need the expression to be static).

Why not, specially?

I haven't used them often, but don't see the problem with

      return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
                                then xTaskGetTickCountFromISR
                                else xTaskGetTickCount));

Re: Running a preprocessor from GPS?

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

On Tue, 28 Jul 2015, EGarrulo wrote:

> On Tuesday, July 28, 2015 at 2:54:50 PM UTC+2, Dmitry A. Kazakov wrote:
>
>> You can inline the suggested wrapper and hope that the compiler indeed does
>> inlining than effectively will make it lazily evaluated.
>
> I can't understand what you mean here.  Would you please explain
> further?  Thank you.

I am not Dmitry, but here is what I frequently do (I actually have a 
package Debug for that). The declaration is as follows:

procedure Trace(Do_It: Boolean; Message: String) with Inline;

The implementation is

procedure Trace(Do_It: Boolean; Message: String) is
begin
   if Do_It then
       Ada.Text_IO.Put_Line(Trace_File, Message);
   end if;
end Trace;

In your program, you just write

Me_Active: Constant Boolean := True;
   -- change this to False if you don't want to trace Me.

Debug.Trace(Me_Active, "Performing Step " & Step(Me));

Now the compiler (well, gnat -- I have no clue what other compilers will 
do) will first inline the code inside Debug.Trace and, if Active_Me is 
False, and the function Step has no side effects, the compiler will 
eliminate the dead code -- at least, if you switch on the optimization.

Actually, this is *not* lazy evaluation: If Step has side effects, Ada 
requires to evaluate it, even if Me_Active is False. A lazy language would 
not evaluate Step. But in the given case, who would want to call some 
function Step with side effects?


--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Wed, 29 Jul 2015 07:46:17 +0100, Simon Wright wrote:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
> 
>>     (4) Real Ada Programmers don't use Ada 2012 conditional expressions 
>> (unless they need the expression to be static).
> 
> Why not, specially?
> 
> I haven't used them often, but don't see the problem with
> 
>       return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>                                 then xTaskGetTickCountFromISR
>                                 else xTaskGetTickCount));

Eh, don't I miss a smiley?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 9:24:20 AM UTC+2, Stefan...@uni-weimar.de wrote:
> On Tue, 28 Jul 2015, EGarrulo wrote:
> 
> > On Tuesday, July 28, 2015 at 2:54:50 PM UTC+2, Dmitry A. Kazakov wrote:
> >
> >> You can inline the suggested wrapper and hope that the compiler indeed does
> >> inlining than effectively will make it lazily evaluated.
> >
> > I can't understand what you mean here.  Would you please explain
> > further?  Thank you.
> 
> I am not Dmitry, but here is what I frequently do (I actually have a 
> package Debug for that). The declaration is as follows:
> 
> procedure Trace(Do_It: Boolean; Message: String) with Inline;
> 
> The implementation is
> 
> procedure Trace(Do_It: Boolean; Message: String) is
> begin
>    if Do_It then
>        Ada.Text_IO.Put_Line(Trace_File, Message);
>    end if;
> end Trace;
> 
> In your program, you just write
> 
> Me_Active: Constant Boolean := True;
>    -- change this to False if you don't want to trace Me.
> 
> Debug.Trace(Me_Active, "Performing Step " & Step(Me));
> 
> Now the compiler (well, gnat -- I have no clue what other compilers will 
> do) will first inline the code inside Debug.Trace and, if Active_Me is 
> False, and the function Step has no side effects, the compiler will 
> eliminate the dead code -- at least, if you switch on the optimization.
> 
> Actually, this is *not* lazy evaluation: If Step has side effects, Ada 
> requires to evaluate it, even if Me_Active is False. A lazy language would 
> not evaluate Step. But in the given case, who would want to call some 
> function Step with side effects?

Thanks.  However, my understanding is that the inlining is unpredictable.  According to the RM 6.3.2 (emphasis mine):

"**For each call**, an implementation is free to follow or to ignore the recommendation determined by the Inline aspect. "

Re: Running a preprocessor from GPS?

[G.B.]

On 29.07.15 00:41, EGarrulo wrote:
> On Wednesday, July 29, 2015 at 12:11:29 AM UTC+2, EGarrulo wrote:
>> 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.
>
> I forgot to say that I have discovered that "printf" can be implemented in Ada by using an operator to feed arguments to an object.  That seems a good solution.

If you can wait another week or so, I'm trying to
finish something that is minimal in a sense. Right
now, there are packages for logging that are like
Java's (Stephane Carrez, AWA), or Log4Ada, ...
These are made for log files, specifically, less so
for quick debugging. But then, it's Ada, so pragma
Debug is for quick jobs.

Re: Running a preprocessor from GPS?

[Brian Drummond]

On Tue, 28 Jul 2015 04:39:45 -0700, EGarrulo wrote:

> On Tuesday, July 28, 2015 at 12:30:18 PM UTC+2, Brian Drummond wrote:
>> Wrap the test and the string formatting into a procedure. You'll
>> probably need a family of such procedures for different formats - keep
>> them in a package.
>> 
>> Write a second package body, where every procedure implementation is
>> simply "null;" and build with whichever package body is appropriate.
> 
> Thanks but this wouldn't work in my case because I want logging code to
> stay, while being able to enable or disable it -- and with different
> levels -- at runtime.

In which case you don't need the second (null) package body. Instead, the 
package exports means to control logging level.

-- Brian

Re: Running a preprocessor from GPS?

[Brian Drummond]

On Tue, 28 Jul 2015 04:39:45 -0700, EGarrulo wrote:

> On Tuesday, July 28, 2015 at 12:30:18 PM UTC+2, Brian Drummond wrote:
>> Wrap the test and the string formatting into a procedure. You'll
>> probably need a family of such procedures for different formats - keep
>> them in a package.
>> 
>> Write a second package body, where every procedure implementation is
>> simply "null;" and build with whichever package body is appropriate.
> 
> Thanks but this wouldn't work in my case because I want logging code to
> stay, while being able to enable or disable it -- and with different
> levels -- at runtime.

waitaminit ... if you use a preprocessor, the logging code DOESN'T stay 
and isn't controllable at runtime.

I think you misunderstood, maybe I need to be more verbose...

By "Wrap the test and the string formatting into a procedure."

I meant
-----------------------------------------
   procedure Trace_If_Active(Me: Some_Type; 
                             Message : String; 
                             Data : Natural;
                             Message2 : String := "") is 
   begin
      if Active (Me) then
         Trace (Me, Message & Natural'Image(Data) & Message2);
      end if;
   end Trace_If_Active;
-----------------------------------------
which allows runtime control through the value of Me.

This ensures the string formatting is conditional on the test.
The drawback is that you need an ad-hoc set of these procedures for 
different output formats, though default arguments for "Message2" keep 
the noise down a bit. Because they are relegated to a package they don't 
add clutter to the codebase (and may be re-usable across projects).

The second (null) package body, selected at build time, simply replaces 
the preprocessing, I never intended it to replace the runtime control 
aspects. 

-- Brian

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 12:31:25 PM UTC+2, Brian Drummond wrote:
> waitaminit ... if you use a preprocessor, the logging code DOESN'T stay 
> and isn't controllable at runtime.

But I would use a preprocessor to expand code unconditionally.  If using the C preprocessor, it would be something like this:

#define TRACE(level,message)          \
            if Active (Level) then    \
               Trace(Level, Message); \
            end if;

Note: for simplicity, I haven't addressed the problem of evaluating `Level` twice.

Re: Running a preprocessor from GPS?

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 1182 bytes --]

On Wed, 29 Jul 2015, EGarrulo wrote:

> Thanks.  However, my understanding is that the inlining is 
> unpredictable.  According to the RM 6.3.2 (emphasis mine):
>
> "**For each call**, an implementation is free to follow or to ignore the 
> recommendation determined by the Inline aspect. "

Well, yes! There are plenty of stupid things an Ada compiler can do, 
without formally violating the standard. Such as raising Storage_Error, 
when adding two integers.

But usually, the maintainers of Ada compilers try to avoid stupid 
behavior. A compiler is not required to support inlining and dead code 
elimination -- and I seem to recall that gnat needs to be "pushed" doing 
that by turning on optimization (at least -O1). But when a compiler does 
inlining and dead code elimination at all, I would be shocked if it would 
not actually inline and eliminate where this is obvioulsly applicable, as 
in the Debug.Trace example.

--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/29/2015 10:30 AM, Stefan.Lucks@uni-weimar.de wrote:
> 
> But usually, the maintainers of Ada compilers try to avoid stupid behavior. A
> compiler is not required to support inlining and dead code elimination -- and I
> seem to recall that gnat needs to be "pushed" doing that by turning on
> optimization (at least -O1). But when a compiler does inlining and dead code
> elimination at all, I would be shocked if it would not actually inline and
> eliminate where this is obvioulsly applicable, as in the Debug.Trace example.

A compiler that doesn't consistently inline trivial subprograms like the example
when asked to probably wouldn't get many users. GNAT is usually pretty good
about inlining if you give it the -gnatn option. It also has a non-standard
pragma Inline_Always, which inlines even if the -gnatn option isn't used.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Running a preprocessor from GPS?

[gautier_niouzes]

Le mercredi 29 juillet 2015 14:00:31 UTC+2, EGarrulo a écrit :
> But I would use a preprocessor to expand code unconditionally.  If using the C preprocessor, it would be something like this:
> 
> #define TRACE(level,message)          \
>             if Active (Level) then    \
>                Trace(Level, Message); \
>             end if;
> 
> Note: for simplicity, I haven't addressed the problem of evaluating `Level` twice.

You can do it in Ada with inlined functions.
If level is constant the unnecessary code will be removed as well.
No need of a preprocessor (there at least) !
NB: usually I have a simpler logic for these things as well:

  type Trace_level is (trace_level_1, trace_level_2, trace_level_3);

  trace: constant: Trace_level:= trace_level_2;

somewhere in the code:

  if trace_level >= trace_level_2 then ...

That's it !

Enjoy
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:lywpxjxxza.fsf@pushface.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>     (4) Real Ada Programmers don't use Ada 2012 conditional expressions
>> (unless they need the expression to be static).
>
> Why not, specially?
>
> I haven't used them often, but don't see the problem with
>
>      return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>                                then xTaskGetTickCountFromISR
>                                else xTaskGetTickCount));

Verbosity, for one. Second, the hiding of the control structure. In general, 
it's better to write the control structure out in a subprogram body, it's a 
lot more readable.

Note that I'm not (quite) a real Ada programmer by my somewhat 
tongue-in-cheek definition -- I'll write whatever is easiest for local code 
(so long as it's implemented in Janus/Ada, so that rules out conditional 
expressions for the moment).

Of course, the development roadmap for Janus/Ada will lead one to using a 
lot of conditional expressions, as it ought to be able to inline expression 
functions (Janus/Ada currently has no inlining). That will encourage code to 
be written using expression functions, and of course the "body" of an 
expression function is an expression, thus only conditional expressions can 
be used. So I'll probably end up getting farther from my ideal based on 
that.

                                       Randy.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/29/2015 12:57 PM, Randy Brukardt wrote:
> "Simon Wright" <simon@pushface.org> wrote in message 
>>
>> I haven't used them often, but don't see the problem with
>>
>>      return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>>                                then xTaskGetTickCountFromISR
>>                                else xTaskGetTickCount));
> 
> Verbosity, for one. Second, the hiding of the control structure. In general, 
> it's better to write the control structure out in a subprogram body, it's a 
> lot more readable.

One of the few arguments I've heard for conditional expressions that might make
sense is that

X := (if Y then 2 else 0);

makes it clear that the purpose of the "if" is to choose the value of X, while in

if Y then
   X := 2;
else
   X := 0;
end if;

that purpose is less apparent.

I'm not sure I buy it. In general, I think such expressions make as much sense
as assignment being an expression.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:0b9d9227-61d8-4d55-9e6b-aa31180a2e6e@googlegroups.com...
On Tuesday, July 28, 2015 at 10:55:33 PM UTC+2, Randy Brukardt wrote:
>  Lazy evaluation -- which can be mimicked with a macro in simpler cases --  
> is not some exotic feature, is it?

It would be in a language that compiles to native code (I don't think either 
C or C++ don't have it). The implementation would have to be something like 
an implicit subprogram that is passed instead of the actual parameter value; 
that would definitely impact the code size and probably would slow down the 
execution as well. (Note that it is not possible to do lazy evaluation on a 
call-by-call basis, as it would necessarily change the code in the body --  
and no one would want lazy evaluation to be the default for all bodies.)

As I used to say during the Ada 9x process -- "everything is implementable; 
the question is really whether it is implementable efficiently (code size, 
code space, compiler effort)".

                       Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"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.

Re: Running a preprocessor from GPS?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:lywpxjxxza.fsf@pushface.org...
>> I haven't used them often, but don't see the problem with
>>
>>      return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>>                                then xTaskGetTickCountFromISR
>>                                else xTaskGetTickCount));
>
> Verbosity, for one. Second, the hiding of the control structure. In
> general, it's better to write the control structure out in a
> subprogram body, it's a lot more readable.

I dunno. The version below is quite verbose, and verges on being less
readable. But this is a style issue, I think.

      if System.FreeRTOS.Tasks.In_ISR then
         return Tick * Time_Base (xTaskGetTickCountFromISR);
      else
         return Tick * Time_Base (xTaskGetTickCount);
      end if;

Re: Running a preprocessor from GPS?

[Randy Brukardt]

Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mpb73u$3qn$2@dont-email.me...
...
> A compiler that doesn't consistently inline trivial subprograms like the 
> example
> when asked to probably wouldn't get many users. GNAT is usually pretty 
> good
> about inlining if you give it the -gnatn option. It also has a 
> non-standard
> pragma Inline_Always, which inlines even if the -gnatn option isn't used.

Janus/Ada doesn't support Inline at all. Whether or not that is a 
counter-example I'll leave to your imagination.

[Why didn't we support Inline? Because it added compilation dependencies, 
and with compilations taking 5 minutes a unit on early PCs, we didn't 
support any additional compilation dependencies -- we wanted code to be 
changable without hours of compilation. That was the original reason why we 
implemented generics using code sharing, too. That led to a compiler 
architecture which has no way to create a body dependency (outside of one's 
own spec).

Besides, a compiler has a better idea of what can and should be inlined than 
a programmer. It's completely silly to have to specify something that should 
be done always if possible. To me, it would make more sense to specify the 
amount of code expansion allowed (on a range of none to unlimited) and let 
the compiler do the best job possible within those constraints. But sadly, 
that's too weird for most.]

                        Randy.



                             Randy.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 10:32:16 PM UTC+2, Randy Brukardt wrote:
> "EGarrulo" wrote in message 
> >> 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).

But is this a valid excuse?  Aren't programming languages supposed to
let programmers write useful programs?  Programmers shouldn't be
looking for clever ways to accomplish basic tasks.  Neither should they
write verbose code to accomplish those basic tasks.  If a programming
language doesn't let programmers print formatted output easily, then it
is deficient and it must be fixed, because printing formatted output is
a basic task.

If Ada offered runtime typing by means of a type `Any`, then `Printf`
could be trivially written as:

   type Printf_Arguments is array (Positive range <>) of Any;
   
   procedure Printf (Format : String; Arguments : Printf_Arguments);

> > 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".

Exactly.  That is why I wonder why I can't write a call to `Trace`
as a one-liner.  Doing so would be very valuable to me.

> > 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.

What do you mean?  Conceptually, generics are macros.  If a compiler
is clever enough to reuse a common implementation, then kudos to the
writers of that compiler, but such behaviour shouldn't be a 
requirement, I think.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 10:09:31 PM UTC+2, Randy Brukardt wrote:
> (Note that it is not possible to do lazy evaluation on a 
> call-by-call basis, as it would necessarily change the code in the body --  
> and no one would want lazy evaluation to be the default for all bodies.)

The compiler could replicate the original procedure -- or function --
and adapt it to take an implicit function.  But doing so would impact code
size.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 10:32:16 PM UTC+2, Randy Brukardt wrote:
> 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).

For me, right now, the #1 annoyance -- which could easily become a deal-breaker -- is that Ada requires manual memory management.  For a
language that qualify itself as safe, this is contradictory (outside
embedded development).  Other modern languages either offer garbage
collection, or smart pointers in the standard library.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/29/2015 03:32 PM, EGarrulo wrote:
> 
> If Ada offered runtime typing by means of a type `Any`, then `Printf`
> could be trivially written as:
> 
>    type Printf_Arguments is array (Positive range <>) of Any;
>    
>    procedure Printf (Format : String; Arguments : Printf_Arguments);

Luckily nothing this horrible will ever make it into Ada.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 1:51:50 AM UTC+2, Jeffrey R. Carter wrote:
> On 07/29/2015 03:32 PM, EGarrulo wrote:
> > 
> > If Ada offered runtime typing by means of a type `Any`, then `Printf`
> > could be trivially written as:
> > 
> >    type Printf_Arguments is array (Positive range <>) of Any;
> >    
> >    procedure Printf (Format : String; Arguments : Printf_Arguments);
> 
> Luckily nothing this horrible will ever make it into Ada.

Who knows?  But since the realm of Ada is limited to embedded
development, it makes sense that flexible formatted output will never
be a priority.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/29/2015 04:45 PM, EGarrulo wrote:
> 
> For me, right now, the #1 annoyance -- which could easily become a deal-breaker -- is that Ada requires manual memory management.  For a
> language that qualify itself as safe, this is contradictory (outside
> embedded development).  Other modern languages either offer garbage
> collection, or smart pointers in the standard library.

Unless you're implementing a dynamic data structure, it's highly unlikely that
you need to use access types at all.

-- 
Jeff Carter
"Whatever it is, I'm against it."
Horse Feathers
46

Re: Running a preprocessor from GPS?

[Niklas Holsti]

On 15-07-30 03:10 , EGarrulo wrote:
> On Thursday, July 30, 2015 at 1:51:50 AM UTC+2, Jeffrey R. Carter wrote:
>> On 07/29/2015 03:32 PM, EGarrulo wrote:
>>>
>>> If Ada offered runtime typing by means of a type `Any`, then `Printf`
>>> could be trivially written as:
>>>
>>>     type Printf_Arguments is array (Positive range <>) of Any;
>>>
>>>     procedure Printf (Format : String; Arguments : Printf_Arguments);
>>
>> Luckily nothing this horrible will ever make it into Ada.

I agree with Jeffrey.

> Who knows?  But since the realm of Ada is limited to embedded
> development,

It isn't.

> it makes sense that flexible formatted output will never
> be a priority.

Having used both, in my opinion the Ada way is more flexible than the C 
printf approach. As long as all variables are explicitly typed "int" or 
"char" or "long", etc, as in classical C programming style, printf works 
tolerably; as soon as one introduces some kind of type abstraction such 
as "typedef ... apple_count_t", constructing the right format-string 
becomes awful, especially if portability is a goal. Look at the standard 
header <inttypes.h> in C99; to make a portable format string for 
apple_count_t, one would also to define a specific format macro (perhaps 
named PRI_APPLE_COUNT) and perhaps another macro for scanf, and use this 
macro within the format string.

Not to mention the maintenance problems in keeping the format string and 
the argument list consistent, even if C compilers nowadays have special 
compile-time checks for this.

The only improvement in the basic Ada output facilities that I wish for 
is a standardisation of the GNAT 'Img attribute and extension of this 
attribute to cover record and array types. That would occasionally be 
useful for quick-and-dirty outputs like tracing outputs. On the other 
hand, tracing functions originally meant to be temporary often become 
permanent and then a quick-and-dirty formatting may not be enough. I 
usually write specific Image functions for my types anyway.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Wed, 29 Jul 2015 15:32:20 -0700 (PDT), EGarrulo wrote:

> If Ada offered runtime typing by means of a type `Any`, then `Printf`
> could be trivially written as:
> 
>    type Printf_Arguments is array (Positive range <>) of Any;
>    
>    procedure Printf (Format : String; Arguments : Printf_Arguments);

This is pretty much useless because Any has no operations. It should be:

   type Printable_Sequence is array (Positive range <>) of Printable'Class;

With Printable having the primitive operation Image.

In fact no run-time typing is required for dealing with that except three
things:

1. MI

2. Ad-hoc supertypes. Some existing types might have no Printable ancestor,
you will have to add it later.

3. Flattening arrays/record (that is if you wanted to drop brackets around
the array aggregate in the calls to Printf).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Georg Bauhaus]

On 30.07.15 00:32, EGarrulo wrote:
> If a programming
> language doesn't let programmers print formatted output easily, then it
> is deficient and it must be fixed, because printing formatted output is
> a basic task.

This seems a valid marketing argument, assuming that "easily" means
"conveniently quick and like with a format string".(*)

How useful would a language defined pragma be that does the job
of just dumping a text representation?

    pragma Dump (On|Off, name {, name });

where »name« stands for any entity from the current unit?

__
(*) Writing

   Put (Some_Float_Object);

is pretty easy to understand and write? Even if you write two Puts
on a line.

Re: Running a preprocessor from GPS?

[Björn Lundin]

On 2015-07-30 08:01, Niklas Holsti wrote:
> On 15-07-30 03:10 , EGarrulo wrote:
>> Who knows?  But since the realm of Ada is limited to embedded
>> development,
> 
> It isn't.

It is certainly not.
I've spent 18 years writing Ada in WMS/WCS systems -
Database intense system with 100+ concurrent users
Nothing embedded at all with them.


> The only improvement in the basic Ada output facilities that I wish for
> is a standardisation of the GNAT 'Img attribute and extension of this
> attribute to cover record and array types. That would occasionally be
> useful for quick-and-dirty outputs like tracing outputs.

This - I want dearly too

--
Björn

Re: Running a preprocessor from GPS?

[gautier_niouzes]

Le mercredi 29 juillet 2015 22:40:08 UTC+2, Randy Brukardt a écrit :

> Besides, a compiler has a better idea of what can and should be inlined than 
> a programmer.

About the "should", and assuming you want code optimization in time: do you know any compiler having a better idea than a programmer of what should be inlined?

_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Running a preprocessor from GPS?

[Jacob Sparre Andersen]

Simon Wright wrote:
>> Simon Wright wrote:

>>>      return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>>>                                then xTaskGetTickCountFromISR
>>>                                else xTaskGetTickCount));

> I dunno. The version below is quite verbose, and verges on being less
> readable. But this is a style issue, I think.
>
>       if System.FreeRTOS.Tasks.In_ISR then
>          return Tick * Time_Base (xTaskGetTickCountFromISR);
>       else
>          return Tick * Time_Base (xTaskGetTickCount);
>       end if;

I definitely find the latter more readable than the former (at least
without syntax highlighting).

Greetings,

Jacob
-- 
The so-called "desktop metaphor" of today's workstation
is instead an "airplane-seat" metaphor.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 9:31:36 AM UTC+2, björn lundin wrote:
> On 2015-07-30 08:01, Niklas Holsti wrote:
> > On 15-07-30 03:10 , EGarrulo wrote:
> >> Who knows?  But since the realm of Ada is limited to embedded
> >> development,
> > 
> > It isn't.
> 
> It is certainly not.
> I've spent 18 years writing Ada in WMS/WCS systems -
> Database intense system with 100+ concurrent users
> Nothing embedded at all with them.

That doesn't mean much.  Ada doesn't offer any facility for
automatic resource management, and that makes it unsuitable for
applications that go beyond constrained embedded development.  Who
wants to chase resource leaks in this day and age?  Not to mention
the crippled support for exceptions in Ada.

Re: Running a preprocessor from GPS?

[Jacob Sparre Andersen]

EGarrulo <egarrulo@gmail.com> writes:

> That doesn't mean much.  Ada doesn't offer any facility for automatic
> resource management, and that makes it unsuitable for applications
> that go beyond constrained embedded development.  Who wants to chase
> resource leaks in this day and age?  Not to mention the crippled
> support for exceptions in Ada.

It really sounds like you haven't taken the time to understand Ada.

Ada programmers hardly ever have to chase resource leaks.

If you attempt to write C++ or Python in Ada, you may end up in big
trouble, but if you use the language (instead of fighting it), you will
hardly ever have to worry about access types or memory management.

Greetings,

Jacob
-- 
LDraw.org Parts Tracker FAQ:
               http://www.ldraw.org/library/tracker/ref/faq/

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 2:25:39 AM UTC+2, Jeffrey R. Carter wrote:
> On 07/29/2015 04:45 PM, EGarrulo wrote:
> > 
> > For me, right now, the #1 annoyance -- which could easily become a deal-breaker -- is that Ada requires manual memory management.  For a
> > language that qualify itself as safe, this is contradictory (outside
> > embedded development).  Other modern languages either offer garbage
> > collection, or smart pointers in the standard library.
> 
> Unless you're implementing a dynamic data structure, it's highly unlikely that
> you need to use access types at all.

Resource management goes beyond dynamic data structures.  At least,
this has been my experience.

Re: Running a preprocessor from GPS?

[Georg Bauhaus]

On 30.07.15 10:03, EGarrulo wrote:
> On Thursday, July 30, 2015 at 9:31:36 AM UTC+2, björn lundin wrote:
>> On 2015-07-30 08:01, Niklas Holsti wrote:
>>> On 15-07-30 03:10 , EGarrulo wrote:
>>>> Who knows?  But since the realm of Ada is limited to embedded
>>>> development,
>>>
>>> It isn't.
>>
>> It is certainly not.
>> I've spent 18 years writing Ada in WMS/WCS systems -
>> Database intense system with 100+ concurrent users
>> Nothing embedded at all with them.
>
> That doesn't mean much.  Ada doesn't offer any facility for
> automatic resource management, and that makes it unsuitable for
> applications that go beyond constrained embedded development.  Who
> wants to chase resource leaks in this day and age?

Is this about GC only? Having had to fight GC in Java,
at a time when it was assumed that GC would magically have
no effect on the program, I'm not sure this isn't a bit
optimistic. But surely it is what one should say.

For completeness, management of resources other than
memory, if tied to GC, becomes uncontrolled happenstance.

There are others who think that the allocation management
of older Objective-C, say, was something they could well
live with (e.g. Hillegass, but maybe he is biased).
And now we got weak and strong properties and all kinds
of algorithmic shift around them. That seems to match what
Dmitry has been explaining about hard/soft references.
The next cry is certainly for automatic hardness management
of reference.

In Ada, use the stack, if possible!
In Ada 2005, use containers, if possible!

>  Not to mention
> the crippled support for exceptions in Ada.

Do you mean that exceptions of Ada cannot be used for indirecting
non-local control flow with the help of exception objects? I'm still
not sure anything but messages should go with exceptions: it is
too tempting for consultants to apply techniques of obfuscation
via exception classes. Even involuntarily!

Re: Running a preprocessor from GPS?

[Pascal Obry]

Le mercredi 29 juillet 2015 à 15:32 -0700, EGarrulo a écrit :
> But is this a valid excuse?  Aren't programming languages supposed to
> let programmers write useful programs? 

You mean useful and unsafe. No thanks.

Nobody should care about programmers' fingers! Verbosity is one of the
strength as it makes the code far more *readable*. And remember that a
piece of code is written once and read many times during the
application lifetime.

> If Ada offered runtime typing by means of a type `Any`, then `Printf`
> could be trivially written as:
> 
>    type Printf_Arguments is array (Positive range <>) of Any;
>    
>    procedure Printf (Format : String; Arguments : Printf_Arguments);

This can be accomplished by libraries, an example is
GNAT.Formatted_String. But there is other implementations around.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Running a preprocessor from GPS?

[Pascal Obry]

Le jeudi 30 juillet 2015 à 01:03 -0700, EGarrulo a écrit :
> That doesn't mean much.  Ada doesn't offer any facility for
> automatic resource management,

Wrong! Please learn Ada first or we are going to have a very lengthly
discussion.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 10:08:09 AM UTC+2, Jacob Sparre Andersen wrote:
> EGarrulo writes:
> 
> > That doesn't mean much.  Ada doesn't offer any facility for automatic
> > resource management, and that makes it unsuitable for applications
> > that go beyond constrained embedded development.  Who wants to chase
> > resource leaks in this day and age?  Not to mention the crippled
> > support for exceptions in Ada.
> 
> It really sounds like you haven't taken the time to understand Ada.

On the contrary: I have taken a lot of time to understand Ada (in
spite of scant documentation on why Ada does things the way it
does).

> Ada programmers hardly ever have to chase resource leaks.

Hence, where is the magic please?  So far, I know that programming
languages either offer garbage collection (and that works only for
memory), or some kind of reference-counting (and that works for
everything, but it requires some planning).
 
> If you attempt to write C++ or Python in Ada, you may end up in big
> trouble, but if you use the language (instead of fighting it), you will
> hardly ever have to worry about access types or memory management.

I have often heard this argument about a programming language.
Yet, ironically, hardly ever somebody explains how a programming
language is meant to be used.  You are always supposed to magically "get it".

The lesson of C++ is that memory is just one of the many possible
scarce resources.  What if you have a shared resource that must be
released as soon as possible?  Garbage collection will not help you
there.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 10:23:23 AM UTC+2, Georg Bauhaus wrote:
> On 30.07.15 10:03, EGarrulo wrote:
> > On Thursday, July 30, 2015 at 9:31:36 AM UTC+2, björn lundin wrote:
> >> On 2015-07-30 08:01, Niklas Holsti wrote:
> >>> On 15-07-30 03:10 , EGarrulo wrote:
> >>>> Who knows?  But since the realm of Ada is limited to embedded
> >>>> development,
> >>>
> >>> It isn't.
> >>
> >> It is certainly not.
> >> I've spent 18 years writing Ada in WMS/WCS systems -
> >> Database intense system with 100+ concurrent users
> >> Nothing embedded at all with them.
> >
> > That doesn't mean much.  Ada doesn't offer any facility for
> > automatic resource management, and that makes it unsuitable for
> > applications that go beyond constrained embedded development.  Who
> > wants to chase resource leaks in this day and age?
> 
> Is this about GC only? Having had to fight GC in Java,
> at a time when it was assumed that GC would magically have
> no effect on the program, I'm not sure this isn't a bit
> optimistic. But surely it is what one should say.
> 
> For completeness, management of resources other than
> memory, if tied to GC, becomes uncontrolled happenstance.
> 
> There are others who think that the allocation management
> of older Objective-C, say, was something they could well
> live with (e.g. Hillegass, but maybe he is biased).
> And now we got weak and strong properties and all kinds
> of algorithmic shift around them. That seems to match what
> Dmitry has been explaining about hard/soft references.
> The next cry is certainly for automatic hardness management
> of reference.
> 
> In Ada, use the stack, if possible!
> In Ada 2005, use containers, if possible!
> 
> >  Not to mention
> > the crippled support for exceptions in Ada.
> 
> Do you mean that exceptions of Ada cannot be used for indirecting
> non-local control flow with the help of exception objects? 

Exceptions in Ada cannot carry contextual information, nor they
can be chained (albeit you could hack them to do both).  Where
is the usefulness of knowing that something has gone awry,
without any context?  For example: "'File not found?' What file
was the program trying to open, and why?"  In embedded software,
it makes sense to avoid memory allocations while raising an
exception, but elsewhere?

> I'm still
> not sure anything but messages should go with exceptions: it is
> too tempting for consultants to apply techniques of obfuscation
> via exception classes. Even involuntarily!

Could you explain further, please?

Re: Running a preprocessor from GPS?

[Georg Bauhaus]

On 30.07.15 10:37, EGarrulo wrote:
> scant documentation

I guess refusing to read the Rationale (for all Ada, it is
continued with every edition) or one of the recommended resources
might be  a source of that view. Another recommended resource is
some of the GNAT.* packages, e.g. the Spitbol ones.

Did you find Riehle's Ada Distilled? It is among
http://www.adaic.org/learn/materials/

If that's not always a welcoming atmosphere, presenting everything
without implying effort, you might have a point. Some good bits
here, not structured yet, though:
http://www.adacore.com/adaanswers/gems/

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 10:23:23 AM UTC+2, Georg Bauhaus wrote:
> Is this about GC only? Having had to fight GC in Java,
> at a time when it was assumed that GC would magically have
> no effect on the program, I'm not sure this isn't a bit
> optimistic. But surely it is what one should say.

This is because you didn't use Java like it is meant to be used!
Hahaha! I am just (half) joking, after having replied to a
similar criticism just now.

> For completeness, management of resources other than
> memory, if tied to GC, becomes uncontrolled happenstance.

Of course.  But manual resource management is too error-prone to
leave it completely in the hands of programmers, at least all
the time.  It is too easy to push the complexity on the
programmer by providing "Unchecked" facilities and then forget
about it.

> In Ada, use the stack, if possible!
> In Ada 2005, use containers, if possible!

Otherwise use C++ and its "shared/weak pointer" support ;)

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 01:45:18 -0700 (PDT), EGarrulo wrote:

> Exceptions in Ada cannot carry contextual information,

Which is right and important, semantically. The context is dead, not
carrying corpses...

Ada's model (and of C++ as well) is leave first, handle later. An
alternative model in early languages, like in PL/1: handle, then return,
proved to be useless.

> Where
> is the usefulness of knowing that something has gone awry,
> without any context?

Of course there is a context, this is the context of the handler. See
above, it is an important semantic of the design. An exceptional state is
one that *cannot* be handled on the context it occurred. That is the whole
idea. If you could handle it, you would right at the point. Exception
propagation is looking for a context where you can handle the exception. 

Note also decoupling, an important thing from the SW design POV. Neither
context need not to know anything about the other.

> For example: "'File not found?' What file
> was the program trying to open, and why?"

Yes, how the OS (the exception context) is supposed to know this? The
handler's context knows it fine, because it is where file was attempted to
open.

> In embedded software,
> it makes sense to avoid memory allocations while raising an
> exception, but elsewhere?

Everywhere. It is about limiting the side effects of an action. Exceptions,
since more than frequently, are misused for dealing with bugs, are first
candidates to limit side effects as much as possible.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 10:27:09 +0200, Pascal Obry wrote:

> This can be accomplished by libraries, an example is
> GNAT.Formatted_String. But there is other implementations around.

Especially ones that use no formats. It is much more simpler to format
strings without formats, the approach I am using it for both Ada and C++.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Björn Lundin]

On 2015-07-30 10:03, EGarrulo wrote:
> On Thursday, July 30, 2015 at 9:31:36 AM UTC+2, björn lundin wrote:
>> On 2015-07-30 08:01, Niklas Holsti wrote:
>>> On 15-07-30 03:10 , EGarrulo wrote:
>>>> Who knows?  But since the realm of Ada is limited to embedded
>>>> development,
>>>
>>> It isn't.
>>
>> It is certainly not.
>> I've spent 18 years writing Ada in WMS/WCS systems -
>> Database intense system with 100+ concurrent users
>> Nothing embedded at all with them.
> 
> That doesn't mean much.  Ada doesn't offer any facility for
> automatic resource management, and that makes it unsuitable for
> applications that go beyond constrained embedded development. 

if you use 'new'.
We hardly do. Why would we ?
You define a type, and use variables of that type.
Extremely seldom pointer to that type.

variables of that type is put in containers.
No pointers.

The only time we use pointers is when interfacing to c-routines,
which are encapsulated in procedures - and leak-free.


> Who
> wants to chase resource leaks in this day and age?  Not to mention
> the crippled support for exceptions in Ada.

I guess what you don't know, you don't miss.
I have no real objections to todays exceptions,
so what do I miss ?

-- 
--
Björn

Re: Running a preprocessor from GPS?

[Pascal Obry]

Le jeudi 30 juillet 2015 à 12:01 +0200, Björn Lundin a écrit :
> if you use 'new'.
> We hardly do. Why would we ?

And even in this case you can still use a pool or sub-pool.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Running a preprocessor from GPS?

[gautier_niouzes]

Le jeudi 30 juillet 2015 10:03:15 UTC+2, EGarrulo a écrit :

> That doesn't mean much.  Ada doesn't offer any facility for
> automatic resource management, and that makes it unsuitable for
> applications that go beyond constrained embedded development.  Who
> wants to chase resource leaks in this day and age? 

Ouch - troll alarm there ?...
In case it's not: you've missed the controlled types. It works like a charm and statistically much better than GC, that appears to work in a random way... and sometimes not at all!... Just put a microphone in a room with C# developers shouting at memory leaks ;-) ...
BTW: in Ada you have a type system that let you do almost everything without heap allocation, it is helpful as well :-)
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Running a preprocessor from GPS?

[Niklas Holsti]

On 15-07-30 11:45 , EGarrulo wrote:
> On Thursday, July 30, 2015 at 10:23:23 AM UTC+2, Georg Bauhaus wrote:
>> On 30.07.15 10:03, EGarrulo wrote:
>>>   Not to mention
>>> the crippled support for exceptions in Ada.
>>
>> Do you mean that exceptions of Ada cannot be used for indirecting
>> non-local control flow with the help of exception objects?
>
> Exceptions in Ada cannot carry contextual information,   Where
> is the usefulness of knowing that something has gone awry,
> without any context?  For example: "'File not found?' What file
> was the program trying to open, and why?"

I suspect that you are conflating two possible uses of exception-handling:

1. To let the program detect and possibly recover automatically from 
run-time failures.

2. To inform the program's user about run-time failures so that the user 
can understand what went wrong and how to correct it.

Ada's exception facility was designed for (1), and is only indirectly 
useful for (2). The idea is that exceptions should be handled at a level 
that knows enough about the context to perform the recovery, or to 
describe the details of the failure to the user.

For example, the idiom for opening a file is:

    File_Name : String := ...

    begin

       Open (File, Name => File_Name, ...);

       -- Successful: do something with the File.

    exception when ... =>
       -- Here the handler knows which file we tried to open
       -- and can act accordingly.

    end;

This can be a bit cumbersome in case one needs to open several files in 
sequence, but then one must also consider if the program should (a) 
abort on the first missing file, or (b) attempt to open them all, so 
that it can give the user a complete list of missing files. Associating 
the name of the missing file with the exception occurrence would help 
with (a), but not really with the more user-friendly (b).

 > Exceptions in Ada cannot ... be chained

I'm not sure what you mean by "chained", but an Ada exception handler 
can either raise another exception, or re-raise the same exception, for 
handling at higher levels.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Running a preprocessor from GPS?

[Brian Drummond]

On Thu, 30 Jul 2015 10:23:25 +0200, Georg Bauhaus wrote:

> On 30.07.15 10:03, EGarrulo wrote:
>>
>> Ada doesn't offer any facility for automatic
>> resource management, and that makes it unsuitable for applications that
>> go beyond constrained embedded development.  Who wants to chase
>> resource leaks in this day and age?
> 
> Is this about GC only? 

No, since he widens the discussion beyond just memory as a resource, I 
suspect he means controlled types.

-- Brian

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 10:27:12 AM UTC+2, Pascal Obry wrote:
> Le mercredi 29 juillet 2015 à 15:32 -0700, EGarrulo a écrit :
> > But is this a valid excuse?  Aren't programming languages supposed to
> > let programmers write useful programs? 
> 
> You mean useful and unsafe. No thanks.

No, I mean useful and safe.  Yes, thanks ;)


> Nobody should care about programmers' fingers! Verbosity is one of the
> strength as it makes the code far more *readable*. And remember that a
> piece of code is written once and read many times during the
> application lifetime.

Exactly!  And:

   Printf ("Mr %Arg you have won %Arg dollars!\n", Surname, Amount);

is much more readable than:

   Put ("Mr ");
   Put (Surname);
   Put (" you have won ");
   Put (Amount);
   Put (" dollars!");
   New_Line;

Now, multiply this for all the times that your program needs
to print formatted text...  Not to mention that the order of the
arguments is hard-coded in the valid Ada snippet, whilst you could
need a different order to support formatted output in different
languages.

> 
> > If Ada offered runtime typing by means of a type `Any`, then `Printf`
> > could be trivially written as:
> > 
> >    type Printf_Arguments is array (Positive range <>) of Any;
> >    
> >    procedure Printf (Format : String; Arguments : Printf_Arguments);
> 
> This can be accomplished by libraries, an example is
> GNAT.Formatted_String. But there is other implementations around.

Then why are we discussing this?  The answer is that Ada does 
support formatted output.  It is strange that this doesn't come with the standard, but that is it.
the standard

Re: Running a preprocessor from GPS?

[EGarrulo]

> This can be accomplished by libraries, an example is
> GNAT.Formatted_String. But there is other implementations around.

By the way, the implementation of GNAT.Formatted_String is cryptic.
Isn't Ada code supposed to be readable?  I must be missing 
something.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 10:28:40 AM UTC+2, Pascal Obry wrote:
> Le jeudi 30 juillet 2015 à 01:03 -0700, EGarrulo a écrit :
> > That doesn't mean much.  Ada doesn't offer any facility for
> > automatic resource management,
> 
> Wrong! Please learn Ada first or we are going to have a very lengthly
> discussion.

No lenghty discussion!  I know that enough Ada to be dangerous ;)  Ada has controlled types and
finalization.  The problem is that the standard leaves the 
implementation of resource management as an exercise for the 
reader, when we know that there are many pitfalls in 
implementing resource management reliably.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 10:49:13 AM UTC+2, Georg Bauhaus wrote:
> On 30.07.15 10:37, EGarrulo wrote:
> > scant documentation
> 
> I guess refusing to read the Rationale (for all Ada, it is
> continued with every edition) or one of the recommended resources
> might be  a source of that view.

Not really.  I wanted to read the Rationale, but each Rationale
builds upon the previous, and reading all the rationales from
the start, while mentally discarding all the concept that were
superseded by new concepts for each new version, would have made
for a very lengthy reading session.  Now, I think that if a
language is conceptually sound, then it shouldn't take long
to explain its core concepts, don't you agree?  Everything
else should follow naturally, either as acknowledged best
practices or as ways to cope with the accidental complexity of
real-world solutions.

> Did you find Riehle's Ada Distilled? It is among
> http://www.adaic.org/learn/materials/

Yes, I did.  Although I am thankful for the effort that the 
author has made and its generosity in making his book freely
available, I found the explanations  somewhat obscure.  Of
course, the renowned "curse of knowledge" phenomenon is at work
here.

> If that's not always a welcoming atmosphere, presenting everything
> without implying effort, you might have a point. Some good bits
> here, not structured yet, though:
> http://www.adacore.com/adaanswers/gems/

Yes, the gems were helpful.  But -- as you acknowledge -- they
lack structure and it is difficult to get the big picture.

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 04:51:48 -0700 (PDT), EGarrulo wrote:

> Exactly!  And:
> 
>    Printf ("Mr %Arg you have won %Arg dollars!\n", Surname, Amount);
> 
> is much more readable than:

It is not readable and it is not formatting, just string concatentation.
 
>    Put ("Mr ");
>    Put (Surname);
>    Put (" you have won ");
>    Put (Amount);
>    Put (" dollars!");
>    New_Line;

Much better, though in such cases, which are not formatting, I rather do

Put_Line ("Mr " & Surname & " you have won " & Image(Amount) & "dollars!");
 
> Now, multiply this for all the times that your program needs
> to print formatted text...

Yes and a lot more because formatting involves fields, justification,
fonts, encodings, localization etc.

[ In real-life C++ it quickly becomes printf ("%s\n", Text) with all
formatting stuff done elsewhere. ]

The point is that for debug messages and other adhockery no full-blown
formatting is ever needed and Put_Line + Image is all anybody could ever
want. For text formatting proper printf is utterly useless.

> Not to mention that the order of the
> arguments is hard-coded in the valid Ada snippet, whilst you could
> need a different order to support formatted output in different
> languages.

And how is it different from printf, except that printf has a hard-coded
order used twice rather than once (once in the format and once in the
arguments), adding a nice source of run-time errors...

My favorite was under 68k UNIX Sys V. The C run-time sometimes modified the
format string while processing printf. In the end the format string was
supposed to be restored to its original state. Alas, the linker put the
format string into a read-only section...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Pascal Obry]

Le jeudi 30 juillet 2015 à 04:54 -0700, EGarrulo a écrit :
> By the way, the implementation of GNAT.Formatted_String is cryptic.
> Isn't Ada code supposed to be readable? 

> I must be missing something.

Yes, sure: Open Mind score below 0!

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 1:22:36 PM UTC+2, Niklas Holsti wrote:
> On 15-07-30 11:45 , EGarrulo wrote:
>  > Exceptions in Ada cannot ... be chained
> 
> I'm not sure what you mean by "chained", but an Ada exception handler 
> can either raise another exception, or re-raise the same exception, for 
> handling at higher levels.

By "chained", I mean that a failure in an operation can
cause a failure in the calling operation, and so on.  Let's
imagine that the initialization of an application relies
on reading a configuration file.  If the syntax of the 
configuration file is not correct, then the routine that
reads it will raise an exception, but this exception would
be too low-level to be meaningful for the user.  Therefore,
it makes sense to chain this exception to another higher-
level exception that explains what the application was
trying to do.  To the end user, this will appear as a chain
of exceptions:

- INITIALIZATION_ERROR: The application failed to initialize;
- CONFIGURATION_ERROR: The configuration failed;
- BAD_FORMAT: The configuration file isn't formatted correctly;
- SYNTAX_ERROR: The value of LEVEL is not of the expected type.

Basically, each exception in the chain answers the
question "why?"  Now, if you report only one of those
exceptions, then you lose context.  This is why you should
be able to chain exceptions.  Of course, you could achieve
a similar result by concatenating messages, but this way
you would be performing manually what the language should
have performed automatically.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 2:42:36 PM UTC+2, Pascal Obry wrote:
> Le jeudi 30 juillet 2015 à 04:54 -0700, EGarrulo a écrit :
> > By the way, the implementation of GNAT.Formatted_String is cryptic.
> > Isn't Ada code supposed to be readable? 
> 
> > I must be missing something.
> 
> Yes, sure: Open Mind score below 0!

Not really.  Compare the arbitrary overloading of "+", "-" and
"&" (and the cryptic "#") in GNAT.Formatted_String here:

  procedure Fout is
     F  : Formatted_String := +"%c %% %#08x";
     Vc : Character := 'v';
     Vi : Integer := 12;
  begin
     F := F & Vc & Vi;
     Put_Line (-F); -- Prints: "v % 0x00000c"
  end Fout;

with the explicit formatting directives here (I am not sure that
this is valid Ada, but you should get the idea):

  procedure Fout is
     F  : Formatted_String;
     Vc : Character := 'v';
     Vi : Integer := 12;
  begin
     F := ("%A %% %A", (Format (Vc), 
                        Format (Vi,
                                Prefix => "0x"                                
                                Base => 16,
                                Width => 8,
                                Filler => "0"));
     Put_Line (F); -- Prints: "v % 0x00000c"
  end Fout;

The only convention that you need to know is that "%A" inserts
an argument and that "%%" inserts a literal "%".  Much simpler,
don't you think?  And extensible!  You can define "Format"
for your own types, independently from "Formatted_String".

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 1:36:56 PM UTC+2, Brian Drummond wrote:
> On Thu, 30 Jul 2015 10:23:25 +0200, Georg Bauhaus wrote:
> 
> > On 30.07.15 10:03, EGarrulo wrote:
> >>
> >> Ada doesn't offer any facility for automatic
> >> resource management, and that makes it unsuitable for applications that
> >> go beyond constrained embedded development.  Who wants to chase
> >> resource leaks in this day and age?
> > 
> > Is this about GC only? 
> 
> No, since he widens the discussion beyond just memory as a resource, I 
> suspect he means controlled types.
> 
> -- Brian

Yes, I mean controlled types.  As far as I can tell, right
now controlled types are useful for resources that are local
to a routine, but they don't scale well for shared resources
because of insufficient support from the language.  I know
that non-intrusive shared pointers have been implemented in
Ada (just a couple of months ago, though, but late is better
than never), but they feel cumbersome and error-prone to use.

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 06:00:11 -0700 (PDT), EGarrulo wrote:

> On Thursday, July 30, 2015 at 1:22:36 PM UTC+2, Niklas Holsti wrote:
>> On 15-07-30 11:45 , EGarrulo wrote:
>>  > Exceptions in Ada cannot ... be chained
>> 
>> I'm not sure what you mean by "chained", but an Ada exception handler 
>> can either raise another exception, or re-raise the same exception, for 
>> handling at higher levels.
> 
> By "chained", I mean that a failure in an operation can
> cause a failure in the calling operation, and so on.  Let's
> imagine that the initialization of an application relies
> on reading a configuration file.  If the syntax of the 
> configuration file is not correct, then the routine that
> reads it will raise an exception, but this exception would
> be too low-level to be meaningful for the user.  Therefore,
> it makes sense to chain this exception to another higher-
> level exception that explains what the application was
> trying to do.  To the end user, this will appear as a chain
> of exceptions:
> 
> - INITIALIZATION_ERROR: The application failed to initialize;
> - CONFIGURATION_ERROR: The configuration failed;
> - BAD_FORMAT: The configuration file isn't formatted correctly;
> - SYNTAX_ERROR: The value of LEVEL is not of the expected type.
> 
> Basically, each exception in the chain answers the
> question "why?"  Now, if you report only one of those
> exceptions, then you lose context.  This is why you should
> be able to chain exceptions.  Of course, you could achieve
> a similar result by concatenating messages, but this way
> you would be performing manually what the language should
> have performed automatically.

exception
    when Error : Chain_Error =>
        raise Chain_Error with "Worse than " & Exception_Message (Error);
end;

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 06:21:42 -0700 (PDT), EGarrulo wrote:

> On Thursday, July 30, 2015 at 2:42:36 PM UTC+2, Pascal Obry wrote:
>> Le jeudi 30 juillet 2015 à 04:54 -0700, EGarrulo a écrit :
>>> By the way, the implementation of GNAT.Formatted_String is cryptic.
>>> Isn't Ada code supposed to be readable? 
>> 
>>> I must be missing something.
>> 
>> Yes, sure: Open Mind score below 0!
> 
> Not really.  Compare the arbitrary overloading of "+", "-" and
> "&" (and the cryptic "#") in GNAT.Formatted_String here:
> 
>   procedure Fout is
>      F  : Formatted_String := +"%c %% %#08x";
>      Vc : Character := 'v';
>      Vi : Integer := 12;
>   begin
>      F := F & Vc & Vi;
>      Put_Line (-F); -- Prints: "v % 0x00000c"
>   end Fout;
> 
> with the explicit formatting directives here (I am not sure that
> this is valid Ada, but you should get the idea):
> 
>   procedure Fout is
>      F  : Formatted_String;
>      Vc : Character := 'v';
>      Vi : Integer := 12;
>   begin
>      F := ("%A %% %A", (Format (Vc), 
>                         Format (Vi,
>                                 Prefix => "0x"                                
>                                 Base => 16,
>                                 Width => 8,
>                                 Filler => "0"));
>      Put_Line (F); -- Prints: "v % 0x00000c"
>   end Fout;
> 
> The only convention that you need to know is that "%A" inserts
> an argument and that "%%" inserts a literal "%".  Much simpler,
> don't you think?  And extensible!  You can define "Format"
> for your own types, independently from "Formatted_String".

declare
   Text : String (1..40);
   Pointer : Integer := Text'First;
begin
   Put (Text, Pointer, Vc & " % 0x");
   Put (Text, Pointer, Vi, Base=>16,Fill=>'0',Field=>6,Justify=>Right);
   Put_Line (Text, 1..Pointer - 1);

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 3:30:53 PM UTC+2, Dmitry A. Kazakov wrote:
> On Thu, 30 Jul 2015 06:00:11 -0700 (PDT), EGarrulo wrote:
> > Basically, each exception in the chain answers the
> > question "why?"  Now, if you report only one of those
> > exceptions, then you lose context.  This is why you should
> > be able to chain exceptions.  Of course, you could achieve
> > a similar result by concatenating messages, but this way
> > you would be performing manually what the language should
> > have performed automatically.
> 
> exception
>     when Error : Chain_Error =>
>         raise Chain_Error with "Worse than " & Exception_Message (Error);
> end;

Ehm... That is exactly what I had said.  Thanks for your
confirmation.  But I wonder whether chaining strings could
lead to an "Out of memory" error in Ada.  Indeed, my 
understanding was that Ada only lets you attach a message
to an exception because doing more could lead to an
 "Out of memory" error, and that would hide the original
source of the error (and indeed the approach of Ada seemed
sensible).

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 3:38:25 PM UTC+2, Dmitry A. Kazakov wrote:
> On Thu, 30 Jul 2015 06:21:42 -0700 (PDT), EGarrulo wrote:
> 
> > On Thursday, July 30, 2015 at 2:42:36 PM UTC+2, Pascal Obry wrote:
> >> Le jeudi 30 juillet 2015 à 04:54 -0700, EGarrulo a écrit :
> >>> By the way, the implementation of GNAT.Formatted_String is cryptic.
> >>> Isn't Ada code supposed to be readable? 
> >> 
> >>> I must be missing something.
> >> 
> >> Yes, sure: Open Mind score below 0!
> > 
> > Not really.  Compare the arbitrary overloading of "+", "-" and
> > "&" (and the cryptic "#") in GNAT.Formatted_String here:
> > 
> >   procedure Fout is
> >      F  : Formatted_String := +"%c %% %#08x";
> >      Vc : Character := 'v';
> >      Vi : Integer := 12;
> >   begin
> >      F := F & Vc & Vi;
> >      Put_Line (-F); -- Prints: "v % 0x00000c"
> >   end Fout;
> > 
> > with the explicit formatting directives here (I am not sure that
> > this is valid Ada, but you should get the idea):
> > 
> >   procedure Fout is
> >      F  : Formatted_String;
> >      Vc : Character := 'v';
> >      Vi : Integer := 12;
> >   begin
> >      F := ("%A %% %A", (Format (Vc), 
> >                         Format (Vi,
> >                                 Prefix => "0x"                                
> >                                 Base => 16,
> >                                 Width => 8,
> >                                 Filler => "0"));
> >      Put_Line (F); -- Prints: "v % 0x00000c"
> >   end Fout;
> > 
> > The only convention that you need to know is that "%A" inserts
> > an argument and that "%%" inserts a literal "%".  Much simpler,
> > don't you think?  And extensible!  You can define "Format"
> > for your own types, independently from "Formatted_String".
> 
> declare
>    Text : String (1..40);
>    Pointer : Integer := Text'First;
> begin
>    Put (Text, Pointer, Vc & " % 0x");
>    Put (Text, Pointer, Vi, Base=>16,Fill=>'0',Field=>6,Justify=>Right);
>    Put_Line (Text, 1..Pointer - 1);

Thank you.  Hence the functionality is already there.  You only
need to wrap it in a more convenient interface.

Re: Running a preprocessor from GPS?

[Niklas Holsti]

On 15-07-30 15:23 , Dmitry A. Kazakov wrote:
> On Thu, 30 Jul 2015 04:51:48 -0700 (PDT), EGarrulo wrote:
>
>> Exactly!  And:
>>
>>     Printf ("Mr %Arg you have won %Arg dollars!\n", Surname, Amount);
>>
>> is much more readable than:
>
> It is not readable and it is not formatting, just string concatentation.
>
>>     Put ("Mr ");
>>     Put (Surname);
>>     Put (" you have won ");
>>     Put (Amount);
>>     Put (" dollars!");
>>     New_Line;
>

   [snip]

>> Not to mention that the order of the
>> arguments is hard-coded in the valid Ada snippet, whilst you could
>> need a different order to support formatted output in different
>> languages.
>
> And how is it different from printf, except that printf has a hard-coded
> order used twice rather than once (once in the format and once in the
> arguments), adding a nice source of run-time errors...

Some printf's support, in the "%" conversion specifications, an initial 
part of the form "%12$" to say that the argument to be converted is 
argument number 12 in the argument list. So the format string can pick 
the arguments in any order it wants -- even converting the same argument 
several times.

(I did not find this feature in the C99 standard. I don't know how 
widely it is supported.)

I don't have any experience of writing multilingual programs, but it 
seems to me that just supplying a language-specific format-string to 
printf is unlikely to be enough, even if this printf has this ability to 
pick arguments in any order.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 2:23:43 PM UTC+2, Dmitry A. Kazakov wrote:
> And how is it different from printf, except that printf has a hard-coded
> order used twice rather than once (once in the format and once in the
> arguments), adding a nice source of run-time errors...

There is a misunderstanding here: I am not saying that "printf"
is perfect.  I am only saying that it provides a convenient
solution to a recurring problem (not in a type-safe way, but
then C *is* unsafe, and while adding some cryptic formatting 
directives).  Thanks to its format string, "printf" lets you see
at a glance what the output will look like.  On the contrary,
solutions in Ada -- that involve more than simple string
concatenation -- tend to obscure what the final result will look
like, and are cumbersome both to write and to read.

Re: Running a preprocessor from GPS?

[G.B.]

On 30.07.15 14:15, EGarrulo wrote:
> Now, I think that if a
> language is conceptually sound, then it shouldn't take long
> to explain its core concepts, don't you agree?

Actually, I think there is a fallacy at work here.
Conceptually sound only if quickly explained?

Like C++, Ada has sets of core concepts, and their integration.  It
shares this property with other bigger languages.  Exciting as it
might be to see how everything in a language can be built on top of
very few things, more so if one already knows the few things, the
language designers did not choose to present everything in their
language this way.  Mathematics doesn't teach 1 + 2 from set theoretic
definitions of 1 and 2, or even routinely perform "+" in this way;
neither will languages like C++, or Ada, do the equivalent.
That is, they all offer higher abstractions, and also their
integration. Both need some learning (and unlearning).  (As regards
learning, consider how the computational power of C++ templates was
discovered only after the fact; they were not quickly explained
and understood at all!)

This was addressed by Jean Ichbiah in his 1984 interview.  He said,
IIRC, that if two guys sitting in the corner do not understand
everything of a bigger language at once, that doesn't mean that the
language is unsound, or useless, or unmaintainable, or whatever.  (It
seems likely that the two guys' last names were among Hoare, Dijkstra,
and Wirth.)

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 06:51:48 -0700 (PDT), EGarrulo wrote:

> On Thursday, July 30, 2015 at 3:30:53 PM UTC+2, Dmitry A. Kazakov wrote:
>> On Thu, 30 Jul 2015 06:00:11 -0700 (PDT), EGarrulo wrote:
>>> Basically, each exception in the chain answers the
>>> question "why?"  Now, if you report only one of those
>>> exceptions, then you lose context.  This is why you should
>>> be able to chain exceptions.  Of course, you could achieve
>>> a similar result by concatenating messages, but this way
>>> you would be performing manually what the language should
>>> have performed automatically.
>> 
>> exception
>>     when Error : Chain_Error =>
>>         raise Chain_Error with "Worse than " & Exception_Message (Error);
>> end;
> 
> Ehm... That is exactly what I had said.  Thanks for your
> confirmation.  But I wonder whether chaining strings could
> lead to an "Out of memory" error in Ada.

It should not, at least not for this reason, because the exception message
length is bounded. You get the message truncated if it becomes too large.

But the idea of exception stack trace does not make much sense, except when
debugging.

-------------------
GNAT provides stack traces at run time. You can have a symbolic trace back
down to the individual source lines. [This does not work on some platforms,
though. Which is the reason why it is not a language feature. The
implementation burden would be too high for some small microcontroller]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[G.B.]

On 30.07.15 10:45, EGarrulo wrote:

>> I'm still
>> not sure anything but messages should go with exceptions: it is
>> too tempting for consultants to apply techniques of obfuscation
>> via exception classes. Even involuntarily!
>
> Could you explain further, please?

Dmitry has explained the context for a handler.

As you explained "chaining", exceptions can propagate
and be exchanged for different exceptions, perhaps after
intermediate handling.

But all the "programming" and "executing" going on when
exceptions are regular objects, or when exception messages
are concatenated, is dubious IMHO. Hack-ish. Instead, in
languages without pre-allocated environments such as Ada
or C++, I'd rather do bookkeeping of all information that
is needed for restarting, if possible, at any level of
handling.

Conceptually, maybe not always applicable:

   declare
      P : Protocol;  -- representing known good state
   begin
      --  either pass P to Op, or maybe have
      --  Op use P as a relatively global variable
      Op (...);
   exception
      when Not_Program_Error_Etc =>
         --  we now have a P ready for inspection
         ...
   end;

In fact, sometimes this is the only way one can handle
exceptions across task borders; Google's App Engine is
one example. One process never knows what is going on in some
separate process unless the other process leaves information
in the datastore, at some location known to both processes.


Involuntary obfuscation happens when the programmer codes
any knowledge of various parts of a program into exception types:
If a programmer knows two different parts of the program,
defines the exception's type in one and uses the thrown
object in the other, there is no trace of this knowledge in
the program's source text. IOW, knowing the conditions
of non-local flow entirely depends on good will, discipline,
conventions, documentation, etc., but not on language.

That's unlike P above: both parts, the one that finally
raises, as well as the handling part will refer to it.
It doesn't look elegant, but it works in general.

Re: Running a preprocessor from GPS?

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> GNAT provides stack traces at run time. You can have a symbolic trace
> back down to the individual source lines. [This does not work on some
> platforms, though. Which is the reason why it is not a language
> feature. The implementation burden would be too high for some small
> microcontroller]

But it's fine in the debugger (since the debug info is on the host). Of
course this doesn't help if the exception happens in deployed
software.

Re: Running a preprocessor from GPS?

[G.B.]

On 30.07.15 09:50, Jacob Sparre Andersen wrote:
> Simon Wright wrote:
>>> Simon Wright wrote:
>
>>>>       return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>>>>                                 then xTaskGetTickCountFromISR
>>>>                                 else xTaskGetTickCount));
>
>> I dunno. The version below is quite verbose, and verges on being less
>> readable. But this is a style issue, I think.
>>
>>        if System.FreeRTOS.Tasks.In_ISR then
>>           return Tick * Time_Base (xTaskGetTickCountFromISR);
>>        else
>>           return Tick * Time_Base (xTaskGetTickCount);
>>        end if;
>
> I definitely find the latter more readable than the former (at least
> without syntax highlighting).

We now have named conditional expressions, so

   function GetTickCount return T
      is ((if System.FreeRTOS.Tasks.In_Isr
           then xTaskGetTickCountFromISR
           else xTaskGetTickCount));
begin
    return Tick * Time_Base (GetTickCount);
end

Re: Running a preprocessor from GPS?

[EGarrulo]

On Wednesday, July 29, 2015 at 10:37:48 PM UTC+2, Simon Wright wrote:
> "Randy Brukardt"  writes:
> 
> > "Simon Wright" wrote in message 
> > ...
> >> I haven't used them often, but don't see the problem with
> >>
> >>      return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
> >>                                then xTaskGetTickCountFromISR
> >>                                else xTaskGetTickCount));
> >
> > Verbosity, for one. Second, the hiding of the control structure. In
> > general, it's better to write the control structure out in a
> > subprogram body, it's a lot more readable.
> 
> I dunno. The version below is quite verbose, and verges on being less
> readable. But this is a style issue, I think.
> 
>       if System.FreeRTOS.Tasks.In_ISR then
>          return Tick * Time_Base (xTaskGetTickCountFromISR);
>       else
>          return Tick * Time_Base (xTaskGetTickCount);
>       end if;

KISS solution:

       TickCount := (if System.FreeRTOS.Tasks.In_ISR
                     then xTaskGetTickCountFromISR
                     else xTaskGetTickCount)
       return Tick * Time_Base (TickCount);

or:

       if System.FreeRTOS.Tasks.In_ISR then 
          TickCount := xTaskGetTickCountFromISR;
       else 
          TickCount := xTaskGetTickCount;
       end if;
       return Tick * Time_Base (TickCount);

:)

The above snippets distinguish between the variable expression and
the derived expression.  I think that the latter form is more
readable.

By the way, you don't have to wrap the expression in double
parentheses (like in the original snippet).

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 5:13:18 PM UTC+2, EGarrulo wrote:
> KISS solution:
> 
>        TickCount := (if System.FreeRTOS.Tasks.In_ISR
>                      then xTaskGetTickCountFromISR
>                      else xTaskGetTickCount)
>        return Tick * Time_Base (TickCount);
> 
>
> I think that the latter form is more
> readable.

Wait!  It seems more a problem of formatting.  This looks
the best:

    TickCount := (if System.FreeRTOS.Tasks.In_ISR then
                     xTaskGetTickCountFromISR
                  else
                     xTaskGetTickCount);

And it would work well with the original solution, too:

return Tick * Time_Base (if System.FreeRTOS.Tasks.In_ISR then
                            xTaskGetTickCountFromISR
                         else 
                            xTaskGetTickCount);

Re: Running a preprocessor from GPS?

[Niklas Holsti]

On 15-07-30 01:32 , EGarrulo wrote:
> On Wednesday, July 29, 2015 at 10:32:16 PM UTC+2, Randy Brukardt wrote:
>> "EGarrulo" wrote in message

>>> 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.
>
> What do you mean?  Conceptually, generics are macros.

Randy Brukardt's message already explained why Ada generics are 
conceptually *not* macros, but perhaps his answer was too focused on how 
his compiler (Janus/Ada) implements generics and not enough on the 
conceptual point.

The aim of Ada generics is to make program components parametrizable by 
types in a safe and predictable way. (In Ada 83, generics were also the 
only way to parametrize program components by operations, but now there 
are other ways to do that.)

The "generic contract" idea in Ada is that the generic declaration 
alone, without looking at the body, gives enough information about the 
generic's formal parameters to decide two things at compile-time:

1. Whether an implementation (body) of the generic is legal, that is, 
uses only the declared properties of the generic formal parameters.

2. Whether an instantiation of the generic with particular actual 
parameters (actual types, etc.) is legal, that is, whether the actual 
parameters have all the properties declared for the generic formal 
parameters.

Thus, compile-time error messages for an illegal generic instantiation 
need only point out discrepancies between the declaration of the generic 
and the actuals in the instantiation. These error messages do not need 
to refer to the body of the generic.

Contrast this with C macros, which are pure text substitution which 
means that the compiler's error messages refer to the definition of the 
macro and can be quite obscure. Similarly, errors in C++ template 
instances are usually detected when the body of the template is compiled 
with the actual template parameters substituted for the formals, and 
again the error messages refer to and must be interpreted by looking at 
the body of the template ("body" is probably not the correct C++ term, 
sorry, I hope my meaning is clear).

This conceptual difference is related to the fact that the theoretical 
computational power of Ada generic instantiation is far below that of 
C++ template instantiation, which is Turing-complete.

 > If a compiler is clever enough to reuse a common implementation,
 > then kudos to the writers of that compiler, but such behaviour
 > shouldn't be a requirement, I think.

The generic contract concept is rather equivalent to a requirement that 
it shall be *possible* to implement generics with shared code. However, 
the generic contract concept is programmer-oriented, not 
compiler-oriented. The choice between shared code or instance-specific 
code is a pragmatic one -- for example, I suspect that the choice of 
shared code in Janus/Ada was influenced by its original 
memory-constrained target processors. Most of GNAT's targets are not so 
memory-constrained.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Running a preprocessor from GPS?

[G.B.]

On 30.07.15 17:13, EGarrulo wrote:
> By the way, you don't have to wrap the expression in double
> parentheses (like in the original snippet).

(Some of us do need them doubled, as the special permission
of Ada to sometimes omit () within () needs more effort in
Emacs mode.)

Re: Running a preprocessor from GPS?

[Simon Wright]

"G.B." <bauhaus@futureapps.invalid> writes:

> On 30.07.15 09:50, Jacob Sparre Andersen wrote:
>> Simon Wright wrote:
>>>> Simon Wright wrote:
>>
>>>>>       return Tick * Time_Base ((if System.FreeRTOS.Tasks.In_ISR
>>>>>                                 then xTaskGetTickCountFromISR
>>>>>                                 else xTaskGetTickCount));
>>
>>> I dunno. The version below is quite verbose, and verges on being less
>>> readable. But this is a style issue, I think.
>>>
>>>        if System.FreeRTOS.Tasks.In_ISR then
>>>           return Tick * Time_Base (xTaskGetTickCountFromISR);
>>>        else
>>>           return Tick * Time_Base (xTaskGetTickCount);
>>>        end if;
>>
>> I definitely find the latter more readable than the former (at least
>> without syntax highlighting).
>
> We now have named conditional expressions, so
>
>   function GetTickCount return T
>      is ((if System.FreeRTOS.Tasks.In_Isr
>           then xTaskGetTickCountFromISR
>           else xTaskGetTickCount));
> begin
>    return Tick * Time_Base (GetTickCount);
> end

An interesting way to think of it! I _think_that in this case it's
getting a little too obfuscatory.

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> By the way, you don't have to wrap the expression in double
> parentheses (like in the original snippet).

No more I do! but this is one step too far for the new Emacs ada-mode.

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> KISS solution:
>
>        TickCount := (if System.FreeRTOS.Tasks.In_ISR
>                      then xTaskGetTickCountFromISR
>                      else xTaskGetTickCount)
>        return Tick * Time_Base (TickCount);
>
> or:
>
>        if System.FreeRTOS.Tasks.In_ISR then 
>           TickCount := xTaskGetTickCountFromISR;
>        else 
>           TickCount := xTaskGetTickCount;
>        end if;
>        return Tick * Time_Base (TickCount);

Both of these require Tick_Count (!) to be declared, which adds a little
more verbosity. At least the first means you could declare it constant.

      Tick_Count : constant System.Unsigned_32
        := (if System.FreeRTOS.Tasks.In_ISR
            then xTaskGetTickCountFromISR
            else xTaskGetTickCount);
   begin
      ...

This whole code will need revisiting when I get round to making
Ada.Real_Time.Time capable of running for more than 50 days! at which
point I'll be inhibiting interrupts and managing the 32-to-64 bit
extension, and there'll certainly be an analog of Tick_Count there.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 6:14:52 PM UTC+2, Simon Wright wrote:
> EGarrulo writes:
> 
> > KISS solution:
> >
> >        TickCount := (if System.FreeRTOS.Tasks.In_ISR
> >                      then xTaskGetTickCountFromISR
> >                      else xTaskGetTickCount)
> >        return Tick * Time_Base (TickCount);
> >
> > or:
> >
> >        if System.FreeRTOS.Tasks.In_ISR then 
> >           TickCount := xTaskGetTickCountFromISR;
> >        else 
> >           TickCount := xTaskGetTickCount;
> >        end if;
> >        return Tick * Time_Base (TickCount);
> 
> Both of these require Tick_Count (!)

But then why did you write xTaskGetTickCountFromISR (!)? :D

I know, I know: they must be system calls.  I just went with what -- at first
sight -- seemed your naming convention.

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> On Thursday, July 30, 2015 at 6:14:52 PM UTC+2, Simon Wright wrote:
>> EGarrulo writes:
>> 
>> > KISS solution:
>> >
>> >        TickCount := (if System.FreeRTOS.Tasks.In_ISR
>> >                      then xTaskGetTickCountFromISR
>> >                      else xTaskGetTickCount)
>> >        return Tick * Time_Base (TickCount);
>> >
>> > or:
>> >
>> >        if System.FreeRTOS.Tasks.In_ISR then 
>> >           TickCount := xTaskGetTickCountFromISR;
>> >        else 
>> >           TickCount := xTaskGetTickCount;
>> >        end if;
>> >        return Tick * Time_Base (TickCount);
>> 
>> Both of these require Tick_Count (!)
>
> But then why did you write xTaskGetTickCountFromISR (!)? :D
>
> I know, I know: they must be system calls.  I just went with what --
> at first sight -- seemed your naming convention.

Indeed!

I'd probably have called the variable Ticks.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/30/2015 01:12 AM, EGarrulo wrote:
> On Thursday, July 30, 2015 at 2:25:39 AM UTC+2, Jeffrey R. Carter wrote:
>> On 07/29/2015 04:45 PM, EGarrulo wrote:
>>>
>>> For me, right now, the #1 annoyance -- which could easily become a deal-breaker -- is that Ada requires manual memory management.  For a
>>> language that qualify itself as safe, this is contradictory (outside
>>> embedded development).  Other modern languages either offer garbage
>>> collection, or smart pointers in the standard library.
>>
>> Unless you're implementing a dynamic data structure, it's highly unlikely that
>> you need to use access types at all.
> 
> Resource management goes beyond dynamic data structures.  At least,
> this has been my experience.

Let's see: you mentioned "manual memory management", "garbage collection", and
"smart pointers". I responded that access types are only rarely needed in Ada,
since everything you mentioned deals with pointers and dynamically allocated
memory. You replied to this by changing the subject to an undefined "resource
management".

It's clear there's no point in continuing such a discussion.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/30/2015 04:51 AM, EGarrulo wrote:
> 
> Exactly!  And:
> 
>    Printf ("Mr %Arg you have won %Arg dollars!\n", Surname, Amount);
> 
> is much more readable than:
> 
>    Put ("Mr ");
>    Put (Surname);
>    Put (" you have won ");
>    Put (Amount);
>    Put (" dollars!");
>    New_Line;

A nice strawman argument. No one would ever write that. Depending on what Printf
does with Amount, one would either write

Ada.Text_IO.Put_Line (Item => "Mr " & Surname & " you have won" &
                              Money'Image (Amount) & " dollars!");

or

Ada.Text_IO.Put (Item => "Mr " & Surname & " you have won ");
Money_IO.Put (Item => Amount, ...);
Ada.Text_IO.Put_Line (Item => " dollars!");

both of which I find easier to read than the Printf call.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> wrote in message 
news:mpbbq4$nkm$1@dont-email.me...
...
> One of the few arguments I've heard for conditional expressions that might 
> make
> sense is that
>
> X := (if Y then 2 else 0);
>
> makes it clear that the purpose of the "if" is to choose the value of X, 
> while in

Yes, I suppose that's true. (It doesn't come up that often in practice, as 
usually there is something else in one of the branches, like a trace or a 
second assignment.)

The main reason I suggest using them is if the expression needs to be 
static:

   X : constant Integer := (if Y then 2 else 0);

If Y is static, then this expression will be static. In previous versions of 
Ada, one had to use tricky expressions involving multiplying by the 
Boolean'Pos to get a static expression, at huge readability cost.

And, of course, if an expression is required for other reasons 
(Preconditions, Predicates, expression functions), then you have no choice. 
Introducing a function (and coming up with a meaningful name for it!!) is a 
pain and does not necessarily help the readability of these things (and it 
definitely reduces the possibilities for proof/optimization at compile-time 
[as opposed to in a separate, whole program tool like SPARK]).

                                         Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:d1tst3FoastU1@mid.individual.net...
...
> The only improvement in the basic Ada output facilities that I wish for is 
> a standardisation of the GNAT 'Img attribute

That was done in the recently approved Corrigendum (other than that we 
called it "'Image"; the only reason GNAT called it "'Img" is that 
changing/extending language-defined attributes is not allowed).

> and extension of this attribute to cover record and array types.

We've tried that (and the topic is still open, AI12-0020-1), but it quickly 
runs into a host of little problems (what do to with access components? 
How/whether to make a matching 'Value? What about private components? Etc.) 
I wouldn't count on seeing that ever happen.

                                         Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:b68e14e7-e304-4220-81f5-67a88cef5767@googlegroups.com...
...
>> Do you mean that exceptions of Ada cannot be used for indirecting
>> non-local control flow with the help of exception objects?
>
>Exceptions in Ada cannot carry contextual information, nor they
>can be chained (albeit you could hack them to do both).

Huh? Every Ada implementation has some sort of contextual information in the 
Exception_Occurrence. The language doesn't try to specify what is available 
there, because that would necessarily prevent better implementations. (For 
instance, Janus/Ada includes a subprogram traceback in the 
Exception_Occurrence.)

I'm not sure what you mean by "chained". Reraise works (and does not erase 
the context in Janus/Ada, perhaps it does in other implementations).

> Where is the usefulness of knowing that something has gone awry,
> without any context?  For example: "'File not found?' What file
> was the program trying to open, and why?"

Again, every real Ada implementation provides that information in the 
Exception_Message. Trying to specify that in a language standard would have 
been a never-ending task, so it's implementation-defined. But implementers 
don't intentionally make their implementations useless...

                          Randy.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 8:12:13 PM UTC+2, Jeffrey R. Carter wrote:
> On 07/30/2015 04:51 AM, EGarrulo wrote:
> > 
> > Exactly!  And:
> > 
> >    Printf ("Mr %Arg you have won %Arg dollars!\n", Surname, Amount);
> > 
> > is much more readable than:
> > 
> >    Put ("Mr ");
> >    Put (Surname);
> >    Put (" you have won ");
> >    Put (Amount);
> >    Put (" dollars!");
> >    New_Line;
> 
> A nice strawman argument. No one would ever write that. Depending on what Printf
> does with Amount, one would either write
> 
> Ada.Text_IO.Put_Line (Item => "Mr " & Surname & " you have won" &
>                               Money'Image (Amount) & " dollars!");
> 
> or
> 
> Ada.Text_IO.Put (Item => "Mr " & Surname & " you have won ");
> Money_IO.Put (Item => Amount, ...);
> Ada.Text_IO.Put_Line (Item => " dollars!");
> 
> both of which I find easier to read than the Printf call.

OK.  Now please write the code so that it could be easily adapted to a
different language by possibly swapping the arguments that are fed to the
output string (this may not cover all existing languages, but it could be good
enough). I would reimplement Printf to accept a format with positional
arguments, like "Mr %1 you have won %2 dollars!\n".  Then I would define a new
format string for the alternative output and I would be done.  This was
possible because a solution based on a formatting procedure recognizes that
output should easily adaptable, something that hard-coded concatenations of
strings are not.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:a10c8bc6-d5de-4b36-a15b-dd830c92c75b@googlegroups.com...
...
>
>> In Ada, use the stack, if possible!
>> In Ada 2005, use containers, if possible!
>
> Otherwise use C++ and its "shared/weak pointer" support ;)

We had a proposal for adding that to Ada, and it just was a complete mess. 
We simplified it to the basic subpool mechanism, which is a lot easier to 
understand and use (if not quite as safe, since it relies on the programmer 
to get the details right).

But seriously, if you can't use the stack and/or containers in Ada 2005 and 
later, you're already into a fairly unlikely problem. And then you can use 
one of the various "smart pointer" packages out there; those do reference 
counting and hide that behind the various syntax sugar techniques of Ada 
2012. (See Christophe Grein's package, for example.) There's an argument 
that one of those packages should get added to the Ada.Containers hierarchy 
(someone should propose that on Ada-Comment).

Anyway, unless you are implementing a container, the need to use access 
types directly (and thus do the storage management directly) is pretty rare. 
And if you are implementing a container, you can limit the management to 
that container (thus taking the problem out of the hands of clients).

                                     Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

<gautier_niouzes@hotmail.com> wrote in message 
news:eed7de55-d776-426d-a0e8-9d536fa2dad0@googlegroups.com...
>Le mercredi 29 juillet 2015 22:40:08 UTC+2, Randy Brukardt a écrit :

>> Besides, a compiler has a better idea of what can and should be inlined 
>> than
>> a programmer.

>About the "should", and assuming you want code optimization in time: do you 
>know
> any compiler having a better idea than a programmer of what should be 
> inlined?

Janus/Ada would have, had the full design ever have been implemented.

I suspect that some obscure compilers have done it, but I don't know for 
sure. It depends on having link-time or JIT code generation, where the 
entire program can be processed at once. JIT is even better as it typically 
has hints about the usage of the routines, so it can know which ones are 
"hot". Else there would be some benefit to "hotness" hints.

But the basic idea is that one specifies how much code expansion is 
allowable (from none to something just short of infinite - paging pressure 
means that performance will decrease at some amount of expansion, so one 
always wants to stop there), and then the compiler choses optimizations 
(inlining, loop unrolling, partial evaluation/body duplication) to meet that 
goal, maximizing "bang-for-the-buck" -- that is, getting the most value out 
of the allowed expansion. There is no way that a programmer can do that, as 
the number of calculations required is far beyond what a programmer can do.

Moreover, there are some inlinings (or partial evaluations, if inlining 
isn't practical for some reason) that should always be accomplished. For 
instance, any subprogram that is called exactly once is a candidate, since 
any parameters eliminated will reduce both the time and space of the 
program. These can't reasonably be identified by a programmer. In the 
specific case of Janus/Ada, any generic that is instantiated exactly once 
will have all calls to a subprogram declared in that generic having a common 
generic descriptor parameter -- eliminating that cuts overhead and opens up 
the possibility of other optimizations (giving code quality much closer to a 
template implementation).

And so on.

If there aren't compilers that do this, it is sad, because it means that 
programs are a lot larger and slower than they have to be.

                                        Randy.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/30/2015 11:51 AM, EGarrulo wrote:
> 
> OK.  Now please write the code so that it could be easily adapted to a
> different language by possibly swapping the arguments that are fed to the
> output string (this may not cover all existing languages, but it could be good
> enough). I would reimplement Printf to accept a format with positional
> arguments, like "Mr %1 you have won %2 dollars!\n".  Then I would define a new
> format string for the alternative output and I would be done.  This was
> possible because a solution based on a formatting procedure recognizes that
> output should easily adaptable, something that hard-coded concatenations of
> strings are not.

Why should I? That's not the problem you presented and I responded to. First a
strawman and now a non-sequitur. Clearly you have no argument.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/30/2015 01:37 AM, EGarrulo wrote:
> 
> Hence, where is the magic please?  So far, I know that programming
> languages either offer garbage collection (and that works only for
> memory), or some kind of reference-counting (and that works for
> everything, but it requires some planning).
> 
> Yet, ironically, hardly ever somebody explains how a programming
> language is meant to be used.  You are always supposed to magically "get it".

And we're supposed to magically know what you think cannot be done in Ada
without manual memory management. You have mentioned "shared resources" a couple
of times without defining what a "resource" is or what it's shared between.
Maybe you mean sharing a data structure between tasks, though anyone who
understands Ada knows how to do that without access types or manual memory
management. In Ada one can implement many recursive data structures without
access types or manual memory management. Maybe that's what you mean.

It's clear you come from a C/++ background, and I suspect you are thinking in
C/++ terms.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:d5a73210-a67f-4d21-8b16-536af10ab157@googlegroups.com...
> On Wednesday, July 29, 2015 at 10:32:16 PM UTC+2, Randy Brukardt wrote:
...
>> 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).
>
> But is this a valid excuse? Aren't programming languages supposed to
> let programmers write useful programs?

Within the language philosophy. If writing *your* useful programs is too 
hard, then you are probably using the wrong language (or you need some 
re-education, which I think applies more to the current case ;-).

...
> If Ada offered runtime typing by means of a type `Any`, then `Printf`
> could be trivially written as:
>
>   type Printf_Arguments is array (Positive range <>) of Any;
>
>   procedure Printf (Format : String; Arguments : Printf_Arguments);

Surely, at the cost of all compile-time checking (because there isn't any). 
And there couldn't be any useful runtime checking, either (at least not 
unless Ada added Multiple Inheritance, which is unlikely), so such a 
construct would be unsafe. (Exactly how unsafe depends on the capabilities 
of the format string.)

...
>> > 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.
>
> What do you mean?  Conceptually, generics are macros.

Definitely not; that's the problem that programmers with extensive C++ 
knowledge don't understand, because they *are* macros in C++. But in Ada, 
the contents of the source text is not what gets duplicated (even though the 
RM mistakenly describes it that way -- definitely a sore point with me). 
Niklas explained the model in far more detail, so I won't repeat it here --  
but the "generic contract" is considered critically important to the 
language design (just like avoiding privacy violations is). It is very 
unlikely that we would ever allow anything that would make an Ada generic 
work like a macro.

                                  Randy. 

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 8:56:01 PM UTC+2, Randy Brukardt wrote:
> "EGarrulo" wrote in message 
> ...
> >
> >> In Ada, use the stack, if possible!
> >> In Ada 2005, use containers, if possible!
> >
> > Otherwise use C++ and its "shared/weak pointer" support ;)
> 
> We had a proposal for adding that to Ada, and it just was a complete mess.

I wonder why.  Smart pointers are conceptually simple.  Sure, Ada tries to
provide bullet-proof solutions, but that is difficult, for pointers.

> But seriously, if you can't use the stack and/or containers in Ada 2005 and 
> later, you're already into a fairly unlikely problem. And then you can use 
> one of the various "smart pointer" packages out there; those do reference 
> counting and hide that behind the various syntax sugar techniques of Ada 
> 2012. (See Christophe Grein's package, for example.) There's an argument 
> that one of those packages should get added to the Ada.Containers hierarchy 
> (someone should propose that on Ada-Comment).
> 
> Anyway, unless you are implementing a container, the need to use access 
> types directly (and thus do the storage management directly) is pretty rare. 
> And if you are implementing a container, you can limit the management to 
> that container (thus taking the problem out of the hands of clients).

Unfortunately, it is clear that I haven't been clear enough (the *curse of
knowledge* has hit me, too).  This is because, as a former C++ programmer, I
tie memory and resources because -- in C++ -- the idiom is that you take care of
the memory, and the system will take care of the tied resources.  Hence, my
problem is not memory alone.  It seems that the package that you have suggested
addresses the problem, albeit it doesn't provide weak pointers.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 9:27:56 PM UTC+2, Jeffrey R. Carter wrote:
> On 07/30/2015 11:51 AM, EGarrulo wrote:
> > 
> > OK.  Now please write the code so that it could be easily adapted to a
> > different language by possibly swapping the arguments that are fed to the
> > output string (this may not cover all existing languages, but it could be good
> > enough). I would reimplement Printf to accept a format with positional
> > arguments, like "Mr %1 you have won %2 dollars!\n".  Then I would define a new
> > format string for the alternative output and I would be done.  This was
> > possible because a solution based on a formatting procedure recognizes that
> > output should easily adaptable, something that hard-coded concatenations of
> > strings are not.
> 
> Why should I? That's not the problem you presented and I responded to. First a
> strawman and now a non-sequitur. Clearly you have no argument.

I had already explained in this discussion why I think that the "Printf"
solution is preferable:

  Thanks to its format string, "printf" lets you see
  at a glance what the output will look like.  On the contrary,
  solutions in Ada -- that involve more than simple string
  concatenation -- tend to obscure what the final result will look
  like, and are cumbersome both to write and to read.

  -- 

  Now, multiply this for all the times that your program needs
  to print formatted text...  Not to mention that the order of the
  arguments is hard-coded in the valid Ada snippet, whilst you could
  need a different order to support formatted output in different
  languages.

If I don't repeat my arguments, it is because doing so would be redundant, not
because I am playing fancy tricks to win an argument.  So... have you got an
alternative to propose, or do you agree that "Printf" is a more flexible
approach?  Before you reply, I am adding that I have already proposed a
specification of Printf that takes an array of strings as the arguments to its
format string, so that formatting can be done outside, and be customized for
new types.  Actually, I think that such a function should become
standard, because it would integrate well with existing functions (like
To_Picture).

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 9:32:17 PM UTC+2, Randy Brukardt wrote:
> "EGarrulo" wrote in message 
> > But is this a valid excuse? Aren't programming languages supposed to
> > let programmers write useful programs?
> 
> Within the language philosophy. If writing *your* useful programs is too 
> hard, then you are probably using the wrong language (or you need some 
> re-education, which I think applies more to the current case ;-).
> 
> ...
> > If Ada offered runtime typing by means of a type `Any`, then `Printf`
> > could be trivially written as:
> >
> >   type Printf_Arguments is array (Positive range <>) of Any;
> >
> >   procedure Printf (Format : String; Arguments : Printf_Arguments);
> 
> Surely, at the cost of all compile-time checking (because there isn't any).

But not all conversions can be checked during compilation, that is a fact
already.

> And there couldn't be any useful runtime checking, either

Why not?  Please explain me why this is acceptable:

   -- This conversion will fail if Some_Integer is bigger than what 
   -- Constrained_Integer_Type can hold.
   Some_Constrained_Integer := Constrained_Integer_Type (Some_Integer);

whilst this is not:

   -- This conversion will fail if Any doesn't contain an Integer.
   Some_Integer := Integer (Any);

I don't see any difference.  Both conversions can fail at runtime because types
don't match.

> unless Ada added Multiple Inheritance, which is unlikely), so such a 
> construct would be unsafe. (Exactly how unsafe depends on the capabilities 
> of the format string.)

If Printf took care of formatting, then the number of supported types would be
limited to standard types (incidentally, this is why I envisioned an alternative
where formatting happens before passing the arguments to Printf).

Re: Running a preprocessor from GPS?

[EGarrulo]

On Thursday, July 30, 2015 at 9:29:38 PM UTC+2, Jeffrey R. Carter wrote:
> On 07/30/2015 01:37 AM, EGarrulo wrote:
> > 
> > Hence, where is the magic please?  So far, I know that programming
> > languages either offer garbage collection (and that works only for
> > memory), or some kind of reference-counting (and that works for
> > everything, but it requires some planning).
> > 
> > Yet, ironically, hardly ever somebody explains how a programming
> > language is meant to be used.  You are always supposed to magically "get it".
> 
> And we're supposed to magically know what you think cannot be done in Ada
> without manual memory management. You have mentioned "shared resources" a couple
> of times without defining what a "resource" is or what it's shared between.
> Maybe you mean sharing a data structure between tasks, though anyone who
> understands Ada knows how to do that without access types or manual memory
> management. In Ada one can implement many recursive data structures without
> access types or manual memory management. Maybe that's what you mean.

By "resource" I mean any resource -- like: database connections,
files, etc. -- that must be relinquished as soon as possible and that is
shared among different objects, in a way that makes it difficult for each object
to determine whether such resource is still needed by other objects or not.  Of
course, this implies a dynamic environment that precludes the possibility of
creating all the needed resources in advance and then releasing them at the end
of computation.

> It's clear you come from a C/++ background, and I suspect you are thinking in
> C/++ terms.

I am not thinking in C++ terms.  I am thinking in terms of patterns
that I know for managing resources.  So far, I only know the "shared/weak
pointer" idiom.  If Ada offers something else, besides manual reclamation, I am
eager to learn about it.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/30/2015 01:53 PM, EGarrulo wrote:
> 
> By "resource" I mean any resource -- like: database connections,
> files, etc. -- that must be relinquished as soon as possible and that is
> shared among different objects, in a way that makes it difficult for each object
> to determine whether such resource is still needed by other objects or not.  Of
> course, this implies a dynamic environment that precludes the possibility of
> creating all the needed resources in advance and then releasing them at the end
> of computation.

I still have no idea what you mean. Sharing a DB connection among objects seems
simple:

declare
   DB : DB_Connection;
begin
   O1.Op (DB => DB);
   O2.Op (DB => DB);
   O3.Op (DB => DB);
end;

and the sharing part remains just as simple if the operations pass the DB to
operations of other objects, and if the code is more complex with multiple paths
and orders of operation invocations. There doesn't seem to be any reason for the
objects to know whether another object will receive the DB after they're through
with it or not, or to be concerned with when it is "relinquished".

> I am not thinking in C++ terms.  I am thinking in terms of patterns
> that I know for managing resources.  So far, I only know the "shared/weak
> pointer" idiom.  If Ada offers something else, besides manual reclamation, I am
> eager to learn about it.

If you only know one idiom, it's not surprising you have difficulty imagining
anything else. "Shared/weak pointer" certainly sounds fairly C/++ oriented to me.

I am perhaps constrained by my Ada experience since I can't image what kind of
problem you're talking about. I wish I could. It reminds me of someone who was
telling me about his experiments with overflowing buffers in C. I said I
preferred to use a language in which that wasn't possible, and he couldn't
conceive of the possibility. He showed me what he was doing, which was something
like

char b[100];

and using strcpy to copy argv[1] into b. He asked how I'd do that with Ada, so I
showed him

B : String := Ada.Command_Line.Argument (1);

He didn't seem to be able to wrap his mind around that. I may be having a
similar problem understanding you.

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/30/2015 12:54 PM, EGarrulo wrote:
> 
> I had already explained in this discussion why I think that the "Printf"
> solution is preferable:
> 
>   Thanks to its format string, "printf" lets you see
>   at a glance what the output will look like.  On the contrary,
>   solutions in Ada -- that involve more than simple string
>   concatenation -- tend to obscure what the final result will look
>   like, and are cumbersome both to write and to read.
> 
>   -- 
> 
>   Now, multiply this for all the times that your program needs
>   to print formatted text...  Not to mention that the order of the
>   arguments is hard-coded in the valid Ada snippet, whilst you could
>   need a different order to support formatted output in different
>   languages.

Your Print as described at that point did not have any support for different
languages without changing the order of the arguments, either. So again you
changed the problem. I can do the same thing: take your Printf with its format
string of type String and numbered placeholders and show how it handles Hebrew.

> If I don't repeat my arguments, it is because doing so would be redundant, not
> because I am playing fancy tricks to win an argument.  So... have you got an
> alternative to propose, or do you agree that "Printf" is a more flexible
> approach?  Before you reply, I am adding that I have already proposed a
> specification of Printf that takes an array of strings as the arguments to its
> format string, so that formatting can be done outside, and be customized for
> new types.  Actually, I think that such a function should become
> standard, because it would integrate well with existing functions (like
> To_Picture).

Printf is a bad idea since humans are bad at mentally parsing things like the
format string and bad at counting things such as the position of an argument in
the argument list, and doing both at once while also trying to match the
placeholders in the format string with the arguments tends to be error-prone.

If formatting can be done "outside", then it's reasonable for such formatting to
result in the entire text to be output:

Ada.Wide_Wide_Text_IO.Put_Line
   (Item =>
       Internationalized (Who_Won, Language, (Surname, Image (Amount) ) ) );

-- 
Jeff Carter
"Pray that there's intelligent life somewhere up in
space, 'cause there's bugger all down here on earth."
Monty Python's Meaning of Life
61

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:262cbf86-25a0-4802-b72e-ec6e650e1dc7@googlegroups.com...
...
> OK.  Now please write the code so that it could be easily adapted to a
> different language by possibly swapping the arguments that are fed to the
> output string (this may not cover all existing languages, but it could be 
> good
> enough).

Localization is a very difficult problem that defies simple solutions like 
format strings (or resource files or any other such solution). These simple 
solutions tend to provide enough of the solution to be seductive, but not 
enough of the solution to actually save any effort.

Ultimately, one has to adopt an application-specific solution (which is why 
the only localization Ada provides is a query to find out the country and 
language). And that is no easier or harder in Ada than it is in any other 
traditional language.

                                       Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:2ac21830-619c-4145-ab99-d6036bd4ed30@googlegroups.com...
> On Thursday, July 30, 2015 at 8:56:01 PM UTC+2, Randy Brukardt wrote:
>> "EGarrulo" wrote in message
>> ...
>> >
>> >> In Ada, use the stack, if possible!
>> >> In Ada 2005, use containers, if possible!
>> >
>> > Otherwise use C++ and its "shared/weak pointer" support ;)
>>
>> We had a proposal for adding that to Ada, and it just was a complete 
>> mess.
>
> I wonder why.  Smart pointers are conceptually simple.

Sure, but thats not what the proposal was about. And "weak" pointers aren't 
so simple; the proposal required converting them (via a function) to a 
strong pointer before they could be used. And if you put that temporary 
strong pointer into a handy global, you could end up locking the object for 
a long time. Plus there was some sort of automated reference counting.

We decided instead to follow the Ada philosophy and provide the building 
blocks so that people could roll their own useful smart pointers. Thus we 
defined subpools (for arena management of memory), user-defined 
dereferencing (so that the lifetime of references can be managed), and so 
on.

Perhaps some package will get enough usage that it should be promoted to be 
part of the Standard (that's what I meant by suggesting that someone propose 
a package to be added to Ada.Containers), but we didn't think that we had 
enough of an idea how these things would be used to Standardize it in 2012.

> Sure, Ada tries to provide bullet-proof solutions, but that is difficult, 
> for pointers.

Exactly. But what is the point of another half-way safe solution? We already 
have plenty of those (subpools, unchecked deallocation itself, etc.).

                                Randy.

Re: Running a preprocessor from GPS?

[Randy Brukardt]

"EGarrulo" <egarrulo@gmail.com> wrote in message 
news:d3142cab-776d-4daa-8475-1dd4d46d8556@googlegroups.com...
> On Thursday, July 30, 2015 at 9:32:17 PM UTC+2, Randy Brukardt wrote:
...
>> And there couldn't be any useful runtime checking, either
>
> Why not?  Please explain me why this is acceptable:
>
>   -- This conversion will fail if Some_Integer is bigger than what
>   -- Constrained_Integer_Type can hold.
>   Some_Constrained_Integer := Constrained_Integer_Type (Some_Integer);
>
> whilst this is not:
>
>   -- This conversion will fail if Any doesn't contain an Integer.
>   Some_Integer := Integer (Any);
>
> I don't see any difference.  Both conversions can fail at runtime because 
> types
> don't match.

This is the same nonsense that Dmitry has been spouting. In the first 
instance, you have the *same* types with different constraints (ranges in 
this case). Ranges *might* be checked at rumtime, although Ada compilers 
spend an enormous amount of effort into checking them at compile-time (so 
there is no overhead).

The second case is a mapping of actual different types. That would require 
some sort of runtime type representation, which would imply a lot of 
overhead for elementary types (as the runtime type representation would be 
larger than the type itself in many cases). Additionally, elementary types 
are by-copy; that would prevent the techniques used for tagged types from 
working. Most likely, one would have to add a level of indirection into most 
objects. That sort of distributed overhead is typically frowned on in Ada.

Indeed, if the second case was allowed in Ada, it definitely would NOT 
represent different types. The check would be some sort of constraint check 
(similar to the tag check of tagged types). "Any" would represent any type, 
and thus would never fail type matching.

                               Randy.

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Thu, 30 Jul 2015 19:23:18 -0500, Randy Brukardt wrote:

> "EGarrulo" <egarrulo@gmail.com> wrote in message 
> news:d3142cab-776d-4daa-8475-1dd4d46d8556@googlegroups.com...
>> On Thursday, July 30, 2015 at 9:32:17 PM UTC+2, Randy Brukardt wrote:
> ...
>>> And there couldn't be any useful runtime checking, either
>>
>> Why not?  Please explain me why this is acceptable:
>>
>>   -- This conversion will fail if Some_Integer is bigger than what
>>   -- Constrained_Integer_Type can hold.
>>   Some_Constrained_Integer := Constrained_Integer_Type (Some_Integer);
>>
>> whilst this is not:
>>
>>   -- This conversion will fail if Any doesn't contain an Integer.
>>   Some_Integer := Integer (Any);
>>
>> I don't see any difference.  Both conversions can fail at runtime because 
>> types
>> don't match.
> 
> This is the same nonsense that Dmitry has been spouting. In the first 
> instance, you have the *same* types with different constraints (ranges in 
> this case). Ranges *might* be checked at rumtime, although Ada compilers 
> spend an enormous amount of effort into checking them at compile-time (so 
> there is no overhead).

It is nowhere same what I am saying. [Leaving apart the point that subtype
is a type and it is not same, the semantics of operations is different.]

> The second case is a mapping of actual different types. That would require 
> some sort of runtime type representation, which would imply a lot of 
> overhead for elementary types (as the runtime type representation would be 
> larger than the type itself in many cases).

No. The actual problem is that Any does not have the operation "Integer".
It is all about semantics. Type conversion is an operation as any other [I
don't care what RM says, when semantics is considered, you know]. There is
no such operation between any type and Integer. Period.

What you are talking about is some imaginary scenario when there existed
Root_Integer'Class and Any would be from that class. Then, indeed, Integer
would a primitive operation of. But in that scenario no conversion will be
ever necessary anyway, because Put (or Image) would be just another
operation of.

In short, you don't need to convert anything if you have a class. That is
the beauty of strong typing and Ada's OO model. It is safe and you don't
need type conversions. All cases where you do are suspicious.

> Additionally, elementary types 
> are by-copy; that would prevent the techniques used for tagged types from 
> working. 

It would not, the class-wide of a scalar type will have a different
representation. Conversion to class-wide and back will be proper
conversion, not a view conversion.

Then for this case, the class is not Root_Integer'Class, but
Printable'Class. Yes, Integer should be a member of.

> Most likely, one would have to add a level of indirection into most 
> objects. That sort of distributed overhead is typically frowned on in Ada.

No overhead in any existing code.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Georg Bauhaus]

On 30.07.15 22:53, EGarrulo wrote:
> By "resource" I mean any resource -- like: database connections,
> files, etc. -- that must be relinquished as soon as possible and that is
> shared among different objects, in a way that makes it difficult for each object
> to determine whether such resource is still needed by other objects or not.  Of
> course, this implies a dynamic environment that precludes the possibility of
> creating all the needed resources in advance and then releasing them at the end
> of computation.

This kind of automatic resource management cannot be real:
How could anything other than the entire collection of objects using
the resource determine whether any one of them still needs the resource?

Therefore, if you have several objects using the resource,
possibly in different tasks, handle the resource with the
help of a protected object.

The protected object implements a protocol. An object wishing
to use the resource will ask the PO for a handle, and will get one ASAP.
In simple cases, the resource can be released by the PO as soon
as all users have signaled to the protected object that they are
done with the resource.

Re: Running a preprocessor from GPS?

[gautier_niouzes]

Le jeudi 30 juillet 2015 22:53:28 UTC+2, EGarrulo a écrit :

> I am not thinking in C++ terms.  I am thinking in terms of patterns
> that I know for managing resources.  So far, I only know the "shared/weak
> pointer" idiom.  If Ada offers something else, besides manual reclamation, I am
> eager to learn about it.

Fantastic, then the example below is for you!
Of course it is a trivial example. You can add a field of type Text to a window type for instance, and the memory will be automatically freed when the window itself is finalized. No pointer, no manual reclamation, no garbage waiting to be collected!... Magic, isn't it ?

--  This test program reads an entire text file into a variable
--  of type Text which is a vector of unbounded strings.

with Ada.Text_IO.Unbounded_IO; use Ada.Text_IO, Ada.Text_IO.Unbounded_IO;
with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;
with Ada.Containers.Vectors;

procedure Text_Container is

  package Text_Pkg is new Ada.Containers.Vectors(Positive, Unbounded_String);
  
  ---------------------
  --  Text container --
  ---------------------
  subtype Text is Text_Pkg.Vector;
  --
  name: constant String:= "text_container.adb";
  t: Text;
  f: File_Type;
begin
  Open(f, In_File, name);
  while not End_of_File(f) loop
    t.Append(Get_Line(f));
  end loop;
  Close(f);
  --
  Create(f, Out_File, "copy_of_" & name);
  for line of t loop
    Put_Line(f, line);
  end loop;
  Close(f);
end;
_________________________
Gautier's Ada programming
http://gautiersblog.blogspot.com/search/label/Ada
NB: follow the above link for a valid e-mail address

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> So far, I only know the "shared/weak pointer" idiom.  If Ada offers
> something else, besides manual reclamation, I am eager to learn about
> it.

Would ref-counted smart pointers suit you? I'd address your problem by
having a smart pointer to a limited-controlled object representing the
resource, whose finalization would clean up the resource.

The smart pointer I wrote a while back (2003!) is at [1] (change to .adb
for the body). There are more modern ones, including AdaMagica's [2].

[1] http://sourceforge.net/p/booch95/code/ci/default/tree/src/bc-support-smart_pointers.ads
[2] http://www.christ-usch-grein.homepage.t-online.de/Ada/Smart_Pointers.html

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Fri, 31 Jul 2015 09:26:17 +0100, Simon Wright wrote:

> EGarrulo <egarrulo@gmail.com> writes:
> 
>> So far, I only know the "shared/weak pointer" idiom.  If Ada offers
>> something else, besides manual reclamation, I am eager to learn about
>> it.
> 
> Would ref-counted smart pointers suit you? I'd address your problem by
> having a smart pointer to a limited-controlled object representing the
> resource, whose finalization would clean up the resource.

Your pointer is a "hard" (AKA strong) reference/pointer, i.e. the target is
not collected until at least pointer exists.

Soft/weak reference/pointer is a pointer that does not prevent collection,
but itself becomes invalid if collection occurs. [To access the target, a
strong pointer is obtained from the weak pointer, the object is accessed
through it, and then the strong pointer is disposed.]

If there is a complex mesh of references some references must be weak to
prevent circular references:

   O1-->hard-->O2
       <--soft--

Yes, there exist many implementations in Ada *and* there is no reason to
have it in the language, as it can be implemented at the library level.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[EGarrulo]

On Friday, July 31, 2015 at 11:13:21 AM UTC+2, Dmitry A. Kazakov wrote:
> Soft/weak reference/pointer is a pointer that does not prevent collection,
> but itself becomes invalid if collection occurs. [To access the target, a
> strong pointer is obtained from the weak pointer, the object is accessed
> through it, and then the strong pointer is disposed.]
> [...]
> Yes, there exist many implementations in Ada *and* there is no reason to
> have it in the language, as it can be implemented at the library level.

Many?  Do you mean many libraries that implement "shared/weak pointer" semantics?  Because I only know of GNATCOLL.Refcount, but this library requires 
you "to create a new tagged type that extends GNATCOLL.Refcount.Refcounted, so 
that it has a counter."  This can be impractical.  Apparently, the next version 
of GNATCOLL will include an alternative implementation[1] that removes this
requirement.  But this means that right now there is GNATCOLL.Refcount only.

--
[1] http://www.adacore.com/developers/development-log/NF-18-O422-013-gnatcoll/

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Fri, 31 Jul 2015 02:31:26 -0700 (PDT), EGarrulo wrote:

> On Friday, July 31, 2015 at 11:13:21 AM UTC+2, Dmitry A. Kazakov wrote:
>> Soft/weak reference/pointer is a pointer that does not prevent collection,
>> but itself becomes invalid if collection occurs. [To access the target, a
>> strong pointer is obtained from the weak pointer, the object is accessed
>> through it, and then the strong pointer is disposed.]
>> [...]
>> Yes, there exist many implementations in Ada *and* there is no reason to
>> have it in the language, as it can be implemented at the library level.
> 
> Many?  Do you mean many libraries that implement "shared/weak pointer"
> semantics?  Because I only know of GNATCOLL.Refcount, but this library
> requires you "to create a new tagged type that extends
> GNATCOLL.Refcount.Refcounted, so 
> that it has a counter."  This can be impractical.

Can be, but isn't. My implementation also uses a base type:

   http://www.dmitry-kazakov.de/ada/components.htm#Objects_etc

It has weak pointers as well:

   http://www.dmitry-kazakov.de/ada/components.htm#persistent_objects

> Apparently, the next version 
> of GNATCOLL will include an alternative implementation[1] that removes this
> requirement.  But this means that right now there is GNATCOLL.Refcount only.

That will add a level of indirection as some other implementations do. I
don't see much merits doing this. There are no cases you might wish to have
another type as the base and furthermore it won't do any good anyway. 

Because the only usable pattern of using strong pointers is this:

   type Object_Interface is interface;
   -- define operations here
   procedure Foo (X : in out Object_Interface) is abstract;

in private
   type Object_Implementation is
       new Reference_Counted and Object_Interface with ...
   -- implement operations here
   overriding procedure Foo (X : in out Object_Implementation);

in public
   type Object is new Object_Interface with private;
   -- implement operations here
   overriding procedure Foo (X : in out Object);

in private
   type Object_Implementation_Ptr is access Object_Implementation'Class;

   type Object is new Strong_Reference with record
       Ptr : Object_Implementation_Ptr;
   end record;

The implementation of Object's Foo delegates:

   procedure Foo (X : in out Object) is
   begin
       X.Ptr.Foo;
   end Foo;

If Object_Implementation must use some existing type, aggregate it. That
won't change anything, because public clients won't see
Object_Implementation anyway. Who cares what was the parent type of?

If you mean that this is too complex for your case, then you probably need
no smart pointers at all, which is, my estimate, 95% of cases when smart
pointers come into consideration. As others many times said pointers rarely
needed in Ada. Cases when in C++ you would use a pointer are handled by the
language itself.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Brian Drummond]

On Thu, 30 Jul 2015 06:30:32 -0700, EGarrulo wrote:

> On Thursday, July 30, 2015 at 1:36:56 PM UTC+2, Brian Drummond wrote:
>> On Thu, 30 Jul 2015 10:23:25 +0200, Georg Bauhaus wrote:
>> 
>> > On 30.07.15 10:03, EGarrulo wrote:
>> >>
>> >> Ada doesn't offer any facility for automatic resource management,
>> > Is this about GC only?
>> No, since he widens the discussion beyond just memory as a resource, I
>> suspect he means controlled types.
> 
> Yes, I mean controlled types.  As far as I can tell, right now
> controlled types are useful for resources that are local to a routine,
> but they don't scale well for shared resources because of insufficient
> support from the language.  I know that non-intrusive shared pointers
> have been implemented in Ada (just a couple of months ago, though, but
> late is better than never), but they feel cumbersome and error-prone to
> use.

I suspect what's missing isn't so much anything in controlled types 
themselves, but something like an Ada Gems worked example showing their 
use in a non-trivial example. At least I can't point at a good example 
offhand.

-- Brian

Re: Running a preprocessor from GPS?

[Brian Drummond]

On Thu, 30 Jul 2015 13:53:26 -0700, EGarrulo wrote:

> I am not thinking in C++ terms.  I am thinking in terms of patterns that
> I know for managing resources.  So far, I only know the "shared/weak
> pointer" idiom.  If Ada offers something else, besides manual
> reclamation, I am eager to learn about it.

To help us all get on the same page, can you link to a good description 
(presumably, not in C++ terms) of what you mean by the "shared/weak 
pointer idiom"? Or name the appropriate Design Pattern(s)?

I have sometimes felt it would be useful to translate some of the 
standard programming texts into Ada - some of the GoF "Design Patterns" 
turn out to be utterly trivial in Ada; some others have been covered ad-
hoc in the "Gems" series, in other cases I'm not clear which of several 
approaches would be most appropriate.

-- Brian

Re: Running a preprocessor from GPS?

[EGarrulo]

On Friday, July 31, 2015 at 1:28:11 PM UTC+2, Brian Drummond wrote:
> On Thu, 30 Jul 2015 13:53:26 -0700, EGarrulo wrote:
> 
> > I am not thinking in C++ terms.  I am thinking in terms of patterns that
> > I know for managing resources.  So far, I only know the "shared/weak
> > pointer" idiom.  If Ada offers something else, besides manual
> > reclamation, I am eager to learn about it.
> 
> To help us all get on the same page, can you link to a good description 
> (presumably, not in C++ terms) of what you mean by the "shared/weak 
> pointer idiom"? Or name the appropriate Design Pattern(s)?

Unfortunately, since the "shared/weak pointer" idiom originated in C++, where
its usage is pervasive, most examples are implemented in C++.  Anyway, here
are some articles that you may read (just skip the C++ parts):

https://en.wikipedia.org/wiki/Smart_pointer
https://en.wikipedia.org/wiki/Weak_reference
https://en.wikipedia.org/wiki/Reference_counting

Re: Running a preprocessor from GPS?

[EGarrulo]

On Friday, July 31, 2015 at 1:28:11 PM UTC+2, Brian Drummond wrote:
> I have sometimes felt it would be useful to translate some of the 
> standard programming texts into Ada - some of the GoF "Design Patterns" 
> turn out to be utterly trivial in Ada; some others have been covered ad-
> hoc in the "Gems" series, in other cases I'm not clear which of several 
> approaches would be most appropriate.

Indeed, this has been done for dynamic languages:

http://norvig.com/design-patterns/

Re: Running a preprocessor from GPS?

[EGarrulo]

On Friday, July 31, 2015 at 1:02:03 PM UTC+2, Dmitry A. Kazakov wrote:
> > Apparently, the next version 
> > of GNATCOLL will include an alternative implementation[1] that removes this
> > requirement.  But this means that right now there is GNATCOLL.Refcount only.
> 
> That will add a level of indirection as some other implementations do. I
> don't see much merits doing this. There are no cases you might wish to have
> another type as the base and furthermore it won't do any good anyway. 

I don't understand what you mean.  A common case is when you have an existing
class that wraps a resource and thus you can't change its base class.  
Therefore the only general solution is to use composition, not inheritance, for
reference counting; like this, for example:

generic 
   type T is private;
package Shared_Accesses is
   type Shared_Object is record
      Reference_Count : Natural;
      Object : T;
   end record;

   type Shared_Object_Access is access Shared_Object;

   type Shared_Access is
      -- Implementation of a controlled type that holds a Shared_Object_Access.
   end;

end Shared_Accesses;

> Because the only usable pattern of using strong pointers is this:
> 
>    type Object_Interface is interface;
>    -- define operations here
>    procedure Foo (X : in out Object_Interface) is abstract;
> 
> in private
>    type Object_Implementation is
>        new Reference_Counted and Object_Interface with ...
>    -- implement operations here
>    overriding procedure Foo (X : in out Object_Implementation);
> 
> in public
>    type Object is new Object_Interface with private;
>    -- implement operations here
>    overriding procedure Foo (X : in out Object);
> 
> in private
>    type Object_Implementation_Ptr is access Object_Implementation'Class;
> 
>    type Object is new Strong_Reference with record
>        Ptr : Object_Implementation_Ptr;
>    end record;
> 
> The implementation of Object's Foo delegates:
> 
>    procedure Foo (X : in out Object) is
>    begin
>        X.Ptr.Foo;
>    end Foo;
> 
> If Object_Implementation must use some existing type, aggregate it. That
> won't change anything, because public clients won't see
> Object_Implementation anyway. Who cares what was the parent type of?

I can't follow what the code does, sorry. What would be the equivalent of this
C++ code:

   std::shared_ptr<Object> shared_object (new Object);

in the above example?  Thanks.

Re: Running a preprocessor from GPS?

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

On Thu, 30 Jul 2015, Randy Brukardt wrote:

>> and extension of this attribute to cover record and array types.
>
> We've tried that (and the topic is still open, AI12-0020-1), but it quickly
> runs into a host of little problems (what do to with access components?
> How/whether to make a matching 'Value? What about private components? Etc.)
> I wouldn't count on seeing that ever happen.

How about supporting

   T'Image (or O'Image for objects of type T)

if and only if T'Image has explicitely been defined?

One could write

   for T'Image use function The_Image_Of_T(Input: T) return String;

or in aspect syntax

   type T is record
     ...
   end record
     with Image => ...;





--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Fri, 31 Jul 2015 06:50:58 -0700 (PDT), EGarrulo wrote:

> On Friday, July 31, 2015 at 1:02:03 PM UTC+2, Dmitry A. Kazakov wrote:
>>> Apparently, the next version 
>>> of GNATCOLL will include an alternative implementation[1] that removes this
>>> requirement.  But this means that right now there is GNATCOLL.Refcount only.
>> 
>> That will add a level of indirection as some other implementations do. I
>> don't see much merits doing this. There are no cases you might wish to have
>> another type as the base and furthermore it won't do any good anyway. 
> 
> I don't understand what you mean.  A common case is when you have an existing
> class that wraps a resource and thus you can't change its base class.  
> Therefore the only general solution is to use composition, not inheritance, for
> reference counting; like this, for example:
> 
> generic 
>    type T is private;
> package Shared_Accesses is
>    type Shared_Object is record
>       Reference_Count : Natural;
>       Object : T;
>    end record;

1. Shared_Object here is not in T'Class [and T is not a limited type]. You
claimed that it would be of T.

2. This design need not to be generic. The implementation I posted is not. 

3. Smart pointers are pretty much useless if T is not limited and definite.

Change it to

   type T (<>) is limited private;

and see what happens.

>> Because the only usable pattern of using strong pointers is this:
>> 
>>    type Object_Interface is interface;
>>    -- define operations here
>>    procedure Foo (X : in out Object_Interface) is abstract;
>> 
>> in private
>>    type Object_Implementation is
>>        new Reference_Counted and Object_Interface with ...
>>    -- implement operations here
>>    overriding procedure Foo (X : in out Object_Implementation);
>> 
>> in public
>>    type Object is new Object_Interface with private;
>>    -- implement operations here
>>    overriding procedure Foo (X : in out Object);
>> 
>> in private
>>    type Object_Implementation_Ptr is access Object_Implementation'Class;

Should have been

    type Object_Implementation_Ptr is access Object_Interface'Class;

sorry.

>>    type Object is new Strong_Reference with record
>>        Ptr : Object_Implementation_Ptr;
>>    end record;
>> 
>> The implementation of Object's Foo delegates:
>> 
>>    procedure Foo (X : in out Object) is
>>    begin
>>        X.Ptr.Foo;
>>    end Foo;
>> 
>> If Object_Implementation must use some existing type, aggregate it. That
>> won't change anything, because public clients won't see
>> Object_Implementation anyway. Who cares what was the parent type of?
> 
> I can't follow what the code does, sorry. What would be the equivalent of this
> C++ code:
> 
>    std::shared_ptr<Object> shared_object (new Object);
> 
> in the above example?

Not even close. The design goals are:

1. Hiding the implementation type from the clients. Clients have no access
to the destination object except than through the "pointer".

2. Decoupling "pointer" from the target type. Thus target type can be
designed later, there can be more than one target type.

3. Ensuring that each target type implements the interface of the
"pointer".

The C++'s design is upside down and inside out.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[Pascal Obry]

Le vendredi 31 juillet 2015 à 17:21 +0200, Stefan.Lucks@uni-weimar.de a
écrit :
> How about supporting
> 
>    T'Image (or O'Image for objects of type T)
> 
> if and only if T'Image has explicitely been defined?
> 
> One could write
> 
>    for T'Image use function The_Image_Of_T(Input: T) return String;
> 
> or in aspect syntax
> 
>    type T is record
>      ...
>    end record
>      with Image => ...;

Right, this would be really nice! And has been discussed many time
here.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://v2p.fr.eu.org
  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/31/2015 04:26 AM, Brian Drummond wrote:
> 
> I have sometimes felt it would be useful to translate some of the 
> standard programming texts into Ada - some of the GoF "Design Patterns" 
> turn out to be utterly trivial in Ada; some others have been covered ad-
> hoc in the "Gems" series, in other cases I'm not clear which of several 
> approaches would be most appropriate.

Many of the "design patterns" are actually implementation patterns to work
around deficiencies in the languages used in the book. An obvious example is the
"singleton pattern". In Ada, a singleton is simply a pkg. It's only a problem
that needs a pattern in languages that lack modules.

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: Running a preprocessor from GPS?

[EGarrulo]

On Friday, July 31, 2015 at 7:54:52 PM UTC+2, Jeffrey R. Carter wrote:
> Many of the "design patterns" are actually implementation patterns to work
> around deficiencies in the languages used in the book. An obvious example is the
> "singleton pattern". In Ada, a singleton is simply a pkg. It's only a problem
> that needs a pattern in languages that lack modules.

But a singleton would be instantiated when the "Get_Instance" function gets
called by client code, not when a module gets loaded.  Or does Ada load a package
at the first call?

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 07/31/2015 11:20 AM, EGarrulo wrote:
> 
> But a singleton would be instantiated when the "Get_Instance" function gets
> called by client code, not when a module gets loaded.  Or does Ada load a package
> at the first call?

Only a generic is instantiated. A singleton need not be generic.

-- 
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

Re: Running a preprocessor from GPS?

[Per Sandberg]

Why muck around, and why not just use the simple "pragma debug":

   pragma debug(Trace (Me,"Performing Step " & Step(...)));

in accordance with the "top secret"  users guide ??


Den 2015-07-27 16:28, EGarrulo skrev:
> I would like to add logging statements to my units.  By using GNATColl.Traces, I could add lines like this one:
>
> if Active (Me) then
>     Trace (Me, "Performing Step " & Step(...));
> end if;
>
> However, this is too verbose.  I could write all the three statements onto a single line, but that wouldn't be able to use the "Pretty Print" function of GPS.  Therefore, I must find a way to use a preprocessor macro -- instead -- that lets me write a statement like this one:
>
>     TRACE (Me, "Performing Step " & Step(...));
>
> Now, it seems to me that `gnatprep`  only lets you define symbol macros, not function macros, therefore `gnatprep` cannot be used here.  Is this correct?  If it is, then I must use another processor (like `m4`, for example).  But, how can I integrate an external preprocessor in GPS so that `Build` and `Build All` will perform macro expansion before compilation?  Thank you.
>

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> On Friday, July 31, 2015 at 7:54:52 PM UTC+2, Jeffrey R. Carter wrote:
>> Many of the "design patterns" are actually implementation patterns to
>> work around deficiencies in the languages used in the book. An
>> obvious example is the "singleton pattern". In Ada, a singleton is
>> simply a pkg. It's only a problem that needs a pattern in languages
>> that lack modules.
>
> But a singleton would be instantiated when the "Get_Instance" function
> gets called by client code, not when a module gets loaded.  Or does
> Ada load a package at the first call?

According to Wikipedia, a singleton "is useful when exactly one object
is needed to coordinate actions across the system". And encapsulating
that object in a package meets that criterion.

Isn't a Get_Instance function a way of getting the desired effect in C++
etc, rather than a necessary detail of the pattern? I can see that it
allows you to postpone creating the singleton instance until a time of
your choosing, rather than the Ada way of doing it during package
elaboration in a sequence chosen by the compilation/build engine.

With regard to Carter's point about "instantiation", it's a term that
Ada has specialised to mean creating an instance of a generic. I don't
know if there's an Ada term that means creating an object that is an
instance of a type? I could suggest "reification" :-) but I doubt that
would fly.

Re: Running a preprocessor from GPS?

[Dmitry A. Kazakov]

On Fri, 31 Jul 2015 11:20:35 -0700 (PDT), EGarrulo wrote:

> On Friday, July 31, 2015 at 7:54:52 PM UTC+2, Jeffrey R. Carter wrote:
>> Many of the "design patterns" are actually implementation patterns to work
>> around deficiencies in the languages used in the book. An obvious example is the
>> "singleton pattern". In Ada, a singleton is simply a pkg. It's only a problem
>> that needs a pattern in languages that lack modules.
> 
> But a singleton would be instantiated when the "Get_Instance" function gets
> called by client code, not when a module gets loaded.  Or does Ada load a package
> at the first call?

Well, since other responses regarding singletons were IMO wrong. Here is an
answer from the OO POV.

In Ada singleton is achieved directly by the language means.

[ When Ada was designed there was no pattern stuff, which Jeffrey correctly
characterized as workarounds.  Yet Ada designers understood the problem,
maybe unconsciously, and resolved it at the language level. ]

Ada's singleton is an object of anonymous type. Many types allow object
declarations of anonymous types, which guarantees single instance, because
the type has no name.

Array singleton:

   Singleton : array (1..3) of Integer;

Task singleton:

   task Singleton is
      ...
   end task;

Protected object singleton:

   protected Singleton is
      ...
   end task;

Access type singleton (note access, not the target):

   Singleton : [not null] access ...;

For other types the singleton pattern is a declaration of the type and the
instance in the package body. This is probably what Jeffrey meant talking
about packages:

package body P is
   type Nobody_See_Me is ...;
   Singleton : Nobody_See_Me;

P.S. Get_Instance is C++ gibberish because it cannot create/return
unconstrained instances. In Ada you declare an object, singleton or not,
and that creates it. End of story.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Running a preprocessor from GPS?

[EGarrulo]

On Saturday, August 1, 2015 at 9:19:05 AM UTC+2, Simon Wright wrote:
> EGarrulo  writes:
> 
> > On Friday, July 31, 2015 at 7:54:52 PM UTC+2, Jeffrey R. Carter wrote:
> >> Many of the "design patterns" are actually implementation patterns to
> >> work around deficiencies in the languages used in the book. An
> >> obvious example is the "singleton pattern". In Ada, a singleton is
> >> simply a pkg. It's only a problem that needs a pattern in languages
> >> that lack modules.
> >
> > But a singleton would be instantiated when the "Get_Instance" function
> > gets called by client code, not when a module gets loaded.  Or does
> > Ada load a package at the first call?
> 
> According to Wikipedia, a singleton "is useful when exactly one object
> is needed to coordinate actions across the system". And encapsulating
> that object in a package meets that criterion.

But all languages that I know let you do that, including C.  Their concept of
a package may be informal, but it is there.

> Isn't a Get_Instance function a way of getting the desired effect in C++
> etc, rather than a necessary detail of the pattern? I can see that it
> allows you to postpone creating the singleton instance until a time of
> your choosing, rather than the Ada way of doing it during package
> elaboration in a sequence chosen by the compilation/build engine.

I can't see how Ada lets you postpone the creation of a singleton until a time
of your choosing, without resorting to Get_Instance.  What is the equivalent of
this code:

if Some_Condition then
   Singleton := Singleton_Package.Get_Instance;
   -- Use singleton.
end if;

without using Get_Instance?  I have tried:

   if Some_Condition then
      declare
         with Ada; use Ada;
      begin
         Singleton := Singleton_Package.Singleton_Instance; -- Read variable.
         -- Use singleton.
      end;
   end if;

But the compiler complains that "aspect specifications not allowed here".  Or
does "with Package" put a package in scope without elaborating it until "use
Package", and therefore I should have left only the "use" directive?

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

>    if Some_Condition then
>       declare
>          with Ada; use Ada;
>       begin
>          Singleton := Singleton_Package.Singleton_Instance; -- Read variable.
>          -- Use singleton.
>       end;
>    end if;
>
> But the compiler complains that "aspect specifications not allowed
> here".  Or does "with Package" put a package in scope without
> elaborating it until "use Package", and therefore I should have left
> only the "use" directive?

"with Pkg" can only occur in a compilation unit's context clauses.

"use Pkg" can appear there, and also in a declarative region (e.g. your
"declare" section).

"use" has no effect on elaboration, only on visibility. See ARM 10.2,
Program Execution.

http://www.adaic.org/resources/add_content/standards/12rm/html/RM-10-2.html

Re: Running a preprocessor from GPS?

[EGarrulo]

On Saturday, August 1, 2015 at 10:32:47 AM UTC+2, Simon Wright wrote:
> EGarrulo  writes:
> 
> >    if Some_Condition then
> >       declare
> >          with Ada; use Ada;
> >       begin
> >          Singleton := Singleton_Package.Singleton_Instance; -- Read variable.
> >          -- Use singleton.
> >       end;
> >    end if;
> >
> > But the compiler complains that "aspect specifications not allowed
> > here".  Or does "with Package" put a package in scope without
> > elaborating it until "use Package", and therefore I should have left
> > only the "use" directive?
> 
> "with Pkg" can only occur in a compilation unit's context clauses.
> 
> "use Pkg" can appear there, and also in a declarative region (e.g. your
> "declare" section).
> 
> "use" has no effect on elaboration, only on visibility. See ARM 10.2,
> Program Execution.
> 
> http://www.adaic.org/resources/add_content/standards/12rm/html/RM-10-2.html

Thanks.  Therefore there is no way to postpone the creation of a singleton 
until client code needs it, by relying on package elaboration alone, right?  
Therefore Ada -- too -- needs the Singleton pattern.

Re: Running a preprocessor from GPS?

[Simon Wright]

EGarrulo <egarrulo@gmail.com> writes:

> Therefore there is no way to postpone the creation of a singleton
> until client code needs it, by relying on package elaboration alone,
> right?  Therefore Ada -- too -- needs the Singleton pattern.

Not quite sure of the use case for that! I'd have thought it more likely
that you'd need to control the order of initialization.

But you're right that sometimes you can't rely on elaboration order
alone.

Re: Running a preprocessor from GPS?

[Björn Lundin]

On 2015-07-31 17:21, Stefan.Lucks@uni-weimar.de wrote:
> On Thu, 30 Jul 2015, Randy Brukardt wrote:
> 
>>> and extension of this attribute to cover record and array types.
>>
>> We've tried that (and the topic is still open, AI12-0020-1), but it
>> quickly
>> runs into a host of little problems (what do to with access components?
>> How/whether to make a matching 'Value? What about private components?
>> Etc.)
>> I wouldn't count on seeing that ever happen.
> 
> How about supporting
> 
>   T'Image (or O'Image for objects of type T)
> 
> if and only if T'Image has explicitely been defined?
> 
> One could write
> 
>   for T'Image use function The_Image_Of_T(Input: T) return String;
> 
> or in aspect syntax
> 
>   type T is record
>     ...
>   end record
>     with Image => ...;
> 

And if not explicitly defined, T'Image could perhaps
return an empty string, ""

--
Björn

Re: Running a preprocessor from GPS?

[Niklas Holsti]

On 15-08-01 13:47 , EGarrulo wrote:
> On Saturday, August 1, 2015 at 10:32:47 AM UTC+2, Simon Wright wrote:
>> EGarrulo  writes:
>>
>>>     if Some_Condition then
>>>        declare
>>>           with Ada; use Ada;
>>>        begin
>>>           Singleton := Singleton_Package.Singleton_Instance; -- Read variable.
>>>           -- Use singleton.
>>>        end;
>>>     end if;
>>>
>>> But the compiler complains that "aspect specifications not allowed
>>> here".  Or does "with Package" put a package in scope without
>>> elaborating it until "use Package", and therefore I should have left
>>> only the "use" directive?
>>
>> "with Pkg" can only occur in a compilation unit's context clauses.
>>
>> "use Pkg" can appear there, and also in a declarative region (e.g. your
>> "declare" section).
>>
>> "use" has no effect on elaboration, only on visibility. See ARM 10.2,
>> Program Execution.
>>
>> http://www.adaic.org/resources/add_content/standards/12rm/html/RM-10-2.html
>
> Thanks.  Therefore there is no way to postpone the creation of a singleton
> until client code needs it, by relying on package elaboration alone, right?
> Therefore Ada -- too -- needs the Singleton pattern.

Discussion of design patterns easily degenerates into a debate about 
terminology.

To second Simon's post, an Ada (library-level) package, as a collection 
of state and operations, with necessarily exactly once instance of the 
state, matches the concept of a singleton object in all respects except 
as regards the "lazy initialization" thing, which to me is a very 
secondary aspect of singletons.

If an Ada "singleton" package is a significant consumer of memory and/or 
initialization time, it is easy to arrange for most of the memory 
allocation and initialization to occur lazily, when the package (or that 
part of the package) is used for the first time. One way to do that is 
to insert a check for initialization at the start of every operation; 
another way is to have some kind of Get_Instance operation that 
initializes the package (i.e. "creates the singleton") and returns a 
handle that is a required parameter for all other operations.

While elaboration order is defined by the "need" relationship between 
modules, this is the static relationship defined by the "with" clauses, 
and is satisfied before the main subprogram starts. Whether this means 
that Ada "needs" the singleton pattern is a moot point.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Running a preprocessor from GPS?

[EGarrulo]

On Saturday, August 1, 2015 at 1:44:59 PM UTC+2, Niklas Holsti wrote:
> Discussion of design patterns easily degenerates into a debate about 
> terminology.
> 
> To second Simon's post, an Ada (library-level) package, as a collection 
> of state and operations, with necessarily exactly once instance of the 
> state, matches the concept of a singleton object in all respects except 
> as regards the "lazy initialization" thing, which to me is a very 
> secondary aspect of singletons.

But the original point was that the Singleton pattern was conceived to work
around deficiencies in the languages used in the "Design Patterns" book.  I
don't see how those languages are deficient in that respect.  It is just that
those languages implement the concept differently.  What is a package in Ada,
is a class with static methods in C++ and Java, or even a ".c" file in C.  The 
goal of the "Design Patterns" book was not to describe how to work around 
deficiencies in a language, or even to show how to solve some design problems, but to describe but how problems had already been solved and then to establish
a shared vocabulary to improve communication between designers.  The "Design 
Patterns" book is descriptive, not prescriptive.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 01:06 AM, EGarrulo wrote:
> 
> I can't see how Ada lets you postpone the creation of a singleton until a time
> of your choosing, without resorting to Get_Instance.  What is the equivalent of
> this code:
>
> if Some_Condition then
>    Singleton := Singleton_Package.Get_Instance;
>    -- Use singleton.
> end if;

The Ada equivalent is

if Some_Condition then
   -- Call operations of Singleton_Package
end if;

You don't have a variable for a singleton; the pkg is the singleton. The need
for a variable in other languages is why this "pattern" is a workaround for the
lack of modules in those languages.

If for some reason your application has a requirement that the storage for the
state of the pkg not be allocated until the first use of the pkg, then the
implementation of the pkg can allocate that storage the 1st time the pkg is
used. The clients of the pkg use it the same way in both cases.

Such a requirement is rare in my experience. What is more common is that the
initialization of the pkg state requires information that is not available
during elaboration; in that case, the pkg has an Initialize operation that is
called when the information is available.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 12:20 AM, Simon Wright wrote:
> 
> With regard to Carter's point about "instantiation", it's a term that
> Ada has specialised to mean creating an instance of a generic. I don't
> know if there's an Ada term that means creating an object that is an
> instance of a type? I could suggest "reification" :-) but I doubt that
> would fly.

Creating an object of a type can be done in 2 ways in Ada, and there are 2 terms
for it. One is an object declaration:

Object : [constant] Type_Name [:= Initial];

The other is an allocator:

type Type_Ptr is access [all] Type_Name;

Ptr : Type_Ptr;

Ptr := new Type_Name['(Initial)];

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 05:19 AM, EGarrulo wrote:
> 
> But the original point was that the Singleton pattern was conceived to work
> around deficiencies in the languages used in the "Design Patterns" book.  I
> don't see how those languages are deficient in that respect.  It is just that
> those languages implement the concept differently.  What is a package in Ada,
> is a class with static methods in C++ and Java, or even a ".c" file in C.  The 
> goal of the "Design Patterns" book was not to describe how to work around 
> deficiencies in a language, or even to show how to solve some design problems, but to describe but how problems had already been solved and then to establish
> a shared vocabulary to improve communication between designers.  The "Design 
> Patterns" book is descriptive, not prescriptive.

I guess we have different definitions of "deficiency." Yours seems to be
something that it is impossible to achieve using the language; if there's a way
to do it, no matter how difficult, complex, and unintuitive, then it's not a
deficiency. By mine, a language that doesn't have a simple, obvious way to
implement common concepts has a deficiency.

In this case, a common idiom that is so simple and obvious in Ada that it
doesn't even have a name for it (I was creating them for over a decade before I
ever encountered the term "singleton" as used in DP) is so difficult, complex,
and unintuitive in these other languages that apparently many people can't
figure it out on their own, so the "trick" has to be written down for them.

The differences between true modules and the C++ "class" construct have been
hashed over so much that there's no point in me repeating it here. The upshot of
it is that they are not equivalent. If they were, a singleton in C++ would be as
simple and obvious as in Ada.

The pkg is a very important concept in Ada, and your insistence that there has
to be a Get_Instance function shows that you don't fully understand it yet.
Until you do, you won't really understand Ada.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> The pkg is a very important concept in Ada, and your insistence that there has
> to be a Get_Instance function shows that you don't fully understand it yet.
> Until you do, you won't really understand Ada.

Is there a good place to read about this?  I had the impression that
package initialization runs unconditionally.  EGarrulo was asking how to
get it to run only in response to a runtime request that might never
happen.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 11:15 AM, Paul Rubin wrote:
> 
> Is there a good place to read about this?  I had the impression that
> package initialization runs unconditionally.  EGarrulo was asking how to
> get it to run only in response to a runtime request that might never
> happen.

It depends on what you mean by "initialize". Elaboration of a library pkg occurs
at start up unconditionally. There's no requirement that a pkg be a library pkg,
so that could be a way to get pkg elaboration to happen later, though it's not
common.

Initialization of an object happens when the object is created. For an object
created by an object declaration, that happens when the declaration is elaborated:

package body P is
   State : Integer := Integer'First;

If the initialization is complex, it can be done in the executable part of the
pkg body when that is elaborated:

package body P is
   State : Integer;
   ...
begin
   -- complex code that assigns a value to State
end P;

If initializing State requires information that the pkg can't get by itself,
then initialization can be performed by an operation called by a client:

package P is
   State       : Integer;
   Initialized : Boolean := False;

   procedure Initialize (Value : in Integer) is
   begin
      if Initialized then
         raise Already_Initialized;
      end if;

      State := Value;
      Initialized := True;
   end Initialize;

   procedure Op is
   begin
      if not Initialized then
         raise Not_Initialized;
      end if;
      ...
   end Op;

This latter case delays initialization to response to a run-time request that
might never happen. Allocation of storage for State still happens during
elaboration of P. Delaying allocation of storage as well is straightforward and
left as an exercise for the reader.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[Stefan.Lucks]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

On Sat, 1 Aug 2015, Björn Lundin wrote:

>> How about supporting
>>
>>   T'Image (or O'Image for objects of type T)
>>
>> if and only if T'Image has explicitely been defined?
>>
>> One could write
>>
>>   for T'Image use function The_Image_Of_T(Input: T) return String;
>>
>> or in aspect syntax
>>
>>   type T is record
>>     ...
>>   end record
>>     with Image => ...;
>>
>
> And if not explicitly defined, T'Image could perhaps
> return an empty string, ""

I would prefer raising a "Program_Error" (or whatever).


--------  I  love  the  taste  of  Cryptanalysis  in  the morning!  --------
www.uni-weimar.de/de/medien/professuren/mediensicherheit/people/stefan-lucks
----Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany----

Re: Running a preprocessor from GPS?

[Georg Bauhaus]

On 01.08.15 20:15, Paul Rubin wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> The pkg is a very important concept in Ada, and your insistence that there has
>> to be a Get_Instance function shows that you don't fully understand it yet.
>> Until you do, you won't really understand Ada.
>
> Is there a good place to read about this?  I had the impression that
> package initialization runs unconditionally.  EGarrulo was asking how to
> get it to run only in response to a runtime request that might never
> happen.


I'm sneaking this in here. A generic instance has context, sometimes
non-static context, on which it depends:

with Ada.Text_IO;
with Ada.Calendar;  use Ada.Calendar;

procedure Late is
    
    Start : Time;
    
    generic
       Now : Time;
    package Again is
       --  tells the time
    end Again;
    
    package body Again is
    begin
       Ada.Text_IO.Put_Line (Duration'Image (Now - Start));
    end Again;
    
begin
    Start := Clock;
    loop
       delay 1.0;
       declare
          package Tick is new Again (Now => Clock);
       begin
          null;
       end;
    end loop;
end Late;

Re: Running a preprocessor from GPS?

[EGarrulo]

On Saturday, August 1, 2015 at 7:49:17 PM UTC+2, Jeffrey R. Carter wrote:
> I guess we have different definitions of "deficiency." Yours seems to be
> something that it is impossible to achieve using the language; if there's a way
> to do it, no matter how difficult, complex, and unintuitive, then it's not a
> deficiency. By mine, a language that doesn't have a simple, obvious way to
> implement common concepts has a deficiency.

I would rather say that my definition of "deficiency" does not include 
different idioms.  Ada and C++ have different ways to accomplish encapsulation:

   Ada encapsulation is accomplished using the Package.
   C++ encapsulation is accomplished using the Class.
   [source: http://www.adahome.com/articles/1997-03/ada_vs_cpp.html]

> The differences between true modules and the C++ "class" construct have been
> hashed over so much that there's no point in me repeating it here. The upshot of
> it is that they are not equivalent. If they were, a singleton in C++ would be as
> simple and obvious as in Ada.

And indeed it is.  Your Ada example:

if Some_Condition then
   -- Call operations of Singleton_Package
end if;

translates directly to C++:

if (some_condition) {
   // Call static operations of Singleton_Class.
}

Where is the difference?  I don't see any.

Maybe some C++ constructs are not well understood by Ada programmers.  Take this
quote, for example:

    12. What is the fundamental difference between a C++ class and an Ada
    package?

    Ada packages are more generalize [sic] encapsulations that can define any 
    number of types.

    [see https://stevanussugianto.wordpress.com/2013/06/06/concept-of-programming-languages-chapter-11-abstract-data-types-and-encapsulation-constructs/]

But you can define any number of types in C++ classes, too!  This is why you can
ask a container about the type of its elements; something that the STL exploits
heavily; and also something that you can't do in Ada, because the type of the 
elements of a container are defined in the package that defines the 
container.

> The pkg is a very important concept in Ada, and your insistence that there has
> to be a Get_Instance function shows that you don't fully understand it yet.
> Until you do, you won't really understand Ada.

Actually, I don't see anything esoteric about Ada packages.  I have insisted on
a Get_Instance function because otherwise the Singleton pattern wouldn't be any
different from global variables (or static class members).

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 01:44 PM, EGarrulo wrote:
> 
> if Some_Condition then
>    -- Call operations of Singleton_Package
> end if;
> 
> translates directly to C++:
> 
> if (some_condition) {
>    // Call static operations of Singleton_Class.
> }
> 
> Where is the difference?  I don't see any.
> 
> Actually, I don't see anything esoteric about Ada packages.  I have insisted on
> a Get_Instance function because otherwise the Singleton pattern wouldn't be any
> different from global variables (or static class members).

Here you've lost me again. A singleton is some hidden state and some operations
that use that state. If it can be as simple as calling static operations of a
class, then why do you and the DP book insist on all the complications? If the
complications are necessary, how can it be that simple?

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[EGarrulo]

On Sunday, August 2, 2015 at 12:44:46 AM UTC+2, Jeffrey R. Carter wrote:
> On 08/01/2015 01:44 PM, EGarrulo wrote:
> > 
> > if Some_Condition then
> >    -- Call operations of Singleton_Package
> > end if;
> > 
> > translates directly to C++:
> > 
> > if (some_condition) {
> >    // Call static operations of Singleton_Class.
> > }
> > 
> > Where is the difference?  I don't see any.
> > 
> > Actually, I don't see anything esoteric about Ada packages.  I have insisted on
> > a Get_Instance function because otherwise the Singleton pattern wouldn't be any
> > different from global variables (or static class members).
> 
> Here you've lost me again. A singleton is some hidden state and some operations
> that use that state.

It is more than that.  The "Applicability" for the Singleton patterns requires 
that "the sole instance should be extensible by sub-classing, and clients should
be able to use an extended instance without modifying their code."  In other
words: if you don't need sub-classing, then you don't need the complications of
the Singleton pattern.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 04:39 PM, EGarrulo wrote:
> 
> It is more than that.  The "Applicability" for the Singleton patterns requires 
> that "the sole instance should be extensible by sub-classing, and clients should
> be able to use an extended instance without modifying their code."  In other
> words: if you don't need sub-classing, then you don't need the complications of
> the Singleton pattern.

You never need programming by extension.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[EGarrulo]

On Sunday, August 2, 2015 at 2:02:30 AM UTC+2, Jeffrey R. Carter wrote:
> You never need programming by extension.

"Never" is a big word :)  Here is a use case: a GUI application that lets the 
user use its preferred GUI widgets (GTK, Motif, etc.).

Re: Running a preprocessor from GPS?

[EGarrulo]

I meant: a GUI application that lets the user select its preferred GUI widget
toolkit (GTK, Motif, etc.) at startup.
 

Re: Running a preprocessor from GPS?

[Paul Rubin]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> Here you've lost me again. A singleton is some hidden state and some operations
> that use that state. If it can be as simple as calling static operations of a
> class, then why do you and the DP book insist on all the complications? If the
> complications are necessary, how can it be that simple?

Singleton is sort of a misnomer.  It sounds like there is always exactly
one instance, but it really means there is either one instance or zero
instances.  There are zero when the program starts, but during the
program's execution it may decide to create one instance.  The scheme
you're describing with packages sounds like the one instance is created
when the program starts.  It doesn't explain how to start with zero
instances, and dynamically create one later.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 05:30 PM, EGarrulo wrote:
> I meant: a GUI application that lets the user select its preferred GUI widget
> toolkit (GTK, Motif, etc.) at startup.

Programming by extension is not needed for this.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/01/2015 07:53 PM, Paul Rubin wrote:
> 
> Singleton is sort of a misnomer.  It sounds like there is always exactly
> one instance, but it really means there is either one instance or zero
> instances.  There are zero when the program starts, but during the
> program's execution it may decide to create one instance.  The scheme
> you're describing with packages sounds like the one instance is created
> when the program starts.  It doesn't explain how to start with zero
> instances, and dynamically create one later.

Normally you don't care if you've allocated the pkg state and it's never used.
That's the normal Ada way. If there is some reason to avoid allocating the state
unless it's used, then you don't allocate the state until an operation is called.

-- 
Jeff Carter
"I don't know why I ever come in here. The
flies get the best of everything."
Never Give a Sucker an Even Break
102

Re: Running a preprocessor from GPS?

[EGarrulo]

On Sunday, August 2, 2015 at 8:05:21 AM UTC+2, Jeffrey R. Carter wrote:
> On 08/01/2015 05:30 PM, EGarrulo wrote:
> > I meant: a GUI application that lets the user select its preferred GUI widget
> > toolkit (GTK, Motif, etc.) at startup.
> 
> Programming by extension is not needed for this.

How would you solve the problem, then?

Re: Running a preprocessor from GPS?

[EGarrulo]

On Sunday, August 2, 2015 at 4:53:49 AM UTC+2, Paul Rubin wrote:
> "Jeffrey R. Carter" writes:
> > Here you've lost me again. A singleton is some hidden state and some operations
> > that use that state. If it can be as simple as calling static operations of a
> > class, then why do you and the DP book insist on all the complications? If the
> > complications are necessary, how can it be that simple?
> 
> Singleton is sort of a misnomer.  It sounds like there is always exactly
> one instance, but it really means there is either one instance or zero
> instances.  There are zero when the program starts, but during the
> program's execution it may decide to create one instance.

Actually, the Singleton pattern lets you add instances later, without the 
clients noticing.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Friday, July 31, 2015 at 2:23:20 AM UTC+2, Randy Brukardt wrote:
> "EGarrulo" wrote in message 
> > On Thursday, July 30, 2015 at 9:32:17 PM UTC+2, Randy Brukardt wrote:
> ...
> >> And there couldn't be any useful runtime checking, either
> >
> > Why not?  Please explain me why this is acceptable:
> >
> >   -- This conversion will fail if Some_Integer is bigger than what
> >   -- Constrained_Integer_Type can hold.
> >   Some_Constrained_Integer := Constrained_Integer_Type (Some_Integer);
> >
> > whilst this is not:
> >
> >   -- This conversion will fail if Any doesn't contain an Integer.
> >   Some_Integer := Integer (Any);
> >
> > I don't see any difference.  Both conversions can fail at runtime because 
> > types
> > don't match.
> 
> This is the same nonsense that Dmitry has been spouting. In the first 
> instance, you have the *same* types with different constraints (ranges in 
> this case). Ranges *might* be checked at rumtime, although Ada compilers 
> spend an enormous amount of effort into checking them at compile-time (so 
> there is no overhead).
> 
> The second case is a mapping of actual different types. That would require 
> some sort of runtime type representation, which would imply a lot of 
> overhead for elementary types (as the runtime type representation would be 
> larger than the type itself in many cases). Additionally, elementary types 
> are by-copy; that would prevent the techniques used for tagged types from 
> working. Most likely, one would have to add a level of indirection into most 
> objects. That sort of distributed overhead is typically frowned on in Ada.
> 
> Indeed, if the second case was allowed in Ada, it definitely would NOT 
> represent different types. The check would be some sort of constraint check 
> (similar to the tag check of tagged types). "Any" would represent any type, 
> and thus would never fail type matching.

Right.  A proper type-safe and efficient solution would require the use of
generics but, right now, C++ is the only language whose generics are complete 
enough to implement such a solution.  In Ada, we are stuck with performing the
job of Printf by hand, or sacrifice performance.

Re: Running a preprocessor from GPS?

[EGarrulo]

On Sunday, August 2, 2015 at 12:08:52 PM UTC+2, EGarrulo wrote:
> On Friday, July 31, 2015 at 2:23:20 AM UTC+2, Randy Brukardt wrote:
> > "EGarrulo" wrote in message 
> > > On Thursday, July 30, 2015 at 9:32:17 PM UTC+2, Randy Brukardt wrote:
> > ...
> > >> And there couldn't be any useful runtime checking, either
> > >
> > > Why not?  Please explain me why this is acceptable:
> > >
> > >   -- This conversion will fail if Some_Integer is bigger than what
> > >   -- Constrained_Integer_Type can hold.
> > >   Some_Constrained_Integer := Constrained_Integer_Type (Some_Integer);
> > >
> > > whilst this is not:
> > >
> > >   -- This conversion will fail if Any doesn't contain an Integer.
> > >   Some_Integer := Integer (Any);
> > >
> > > I don't see any difference.  Both conversions can fail at runtime because 
> > > types
> > > don't match.
> > 
> > This is the same nonsense that Dmitry has been spouting. In the first 
> > instance, you have the *same* types with different constraints (ranges in 
> > this case). Ranges *might* be checked at rumtime, although Ada compilers 
> > spend an enormous amount of effort into checking them at compile-time (so 
> > there is no overhead).
> > 
> > The second case is a mapping of actual different types. That would require 
> > some sort of runtime type representation, which would imply a lot of 
> > overhead for elementary types (as the runtime type representation would be 
> > larger than the type itself in many cases). Additionally, elementary types 
> > are by-copy; that would prevent the techniques used for tagged types from 
> > working. Most likely, one would have to add a level of indirection into most 
> > objects. That sort of distributed overhead is typically frowned on in Ada.
> > 
> > Indeed, if the second case was allowed in Ada, it definitely would NOT 
> > represent different types. The check would be some sort of constraint check 
> > (similar to the tag check of tagged types). "Any" would represent any type, 
> > and thus would never fail type matching.
> 
> Right.  A proper type-safe and efficient solution would require the use of
> generics but, right now, C++ is the only language whose generics are complete 
> enough to implement such a solution.  In Ada, we are stuck with performing the
> job of Printf by hand, or sacrifice performance.

If I recall correctly, Ada was the first standardized language that introduced 
generics.  Then other languages caught up and nowadays they lead the way. 
Yet, I am sure that Ada will catch up in the future.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/02/2015 01:29 AM, EGarrulo wrote:
> On Sunday, August 2, 2015 at 8:05:21 AM UTC+2, Jeffrey R. Carter wrote:
>> On 08/01/2015 05:30 PM, EGarrulo wrote:
>>> I meant: a GUI application that lets the user select its preferred GUI widget
>>> toolkit (GTK, Motif, etc.) at startup.
>>
>> Programming by extension is not needed for this.
> 
> How would you solve the problem, then?

With programming by composition, of course.

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

Re: Running a preprocessor from GPS?

[EGarrulo]

On Sunday, August 2, 2015 at 9:21:12 PM UTC+2, Jeffrey R. Carter wrote:
> On 08/02/2015 01:29 AM, EGarrulo wrote:
> > On Sunday, August 2, 2015 at 8:05:21 AM UTC+2, Jeffrey R. Carter wrote:
> >> On 08/01/2015 05:30 PM, EGarrulo wrote:
> >>> I meant: a GUI application that lets the user select its preferred GUI widget
> >>> toolkit (GTK, Motif, etc.) at startup.
> >>
> >> Programming by extension is not needed for this.
> > 
> > How would you solve the problem, then?
> 
> With programming by composition, of course.

And would that decrease complexity, or just move it elsewhere?  I am afraid
that it would increase complexity, and substantially.  Indeed, the "Design 
Patterns" book itself recommends "Favor 'object composition' over 'class 
inheritance'".  And yet the Singleton pattern uses inheritance.  Had the 
authors felt that composition were applicable for the Singleton, they would 
have adopted it, don't you think?  Anyway, if an alternative to Singleton that
uses composition has been documented somewhere, I would gladly peruse it.

Re: Running a preprocessor from GPS?

[Jeffrey R. Carter]

On 08/02/2015 02:37 PM, EGarrulo wrote:
> 
> And would that decrease complexity, or just move it elsewhere?  I am afraid
> that it would increase complexity, and substantially.  Indeed, the "Design 
> Patterns" book itself recommends "Favor 'object composition' over 'class 
> inheritance'".  And yet the Singleton pattern uses inheritance.  Had the 
> authors felt that composition were applicable for the Singleton, they would 
> have adopted it, don't you think?  Anyway, if an alternative to Singleton that
> uses composition has been documented somewhere, I would gladly peruse it.

Some years ago I published articles on the problems with programming by
extension. I'm hardly going to repeat them here. Using examples intended to show
the advantages of extension, I showed that programming by composition can do
anything extension can, leads to code that is clearer and easier to understand,
and that the examples violated basic S/W-engineering principles. The  papers can
be be found at

http://pragmada.x10hosting.com/papers.html

-- 
Jeff Carter
"Hold your temper. Count ten.... Now let 'er go.
You got a good aim."
Never Give a Sucker an Even Break
105

Re: Running a preprocessor from GPS?

[Randy Brukardt]

<Stefan.Lucks@uni-weimar.de> wrote in message 
news:alpine.DEB.2.20.1507311715090.24880@debian...
On Thu, 30 Jul 2015, Randy Brukardt wrote:

>>> and extension of this attribute to cover record and array types.
>>
>> We've tried that (and the topic is still open, AI12-0020-1), but it 
>> quickly
>> runs into a host of little problems (what do to with access components?
>> How/whether to make a matching 'Value? What about private components? 
>> Etc.)
>> I wouldn't count on seeing that ever happen.
>
>How about supporting
>
>   T'Image (or O'Image for objects of type T)
>
>if and only if T'Image has explicitely been defined?
>
>...

There would be a contract model problem (in a generic, you couldn't know if 
a formal private type had 'Image). That's solveable.

The real problem is that this doesn't buy much of anything. All it does is 
changes the name slightly, as anyone can define a function Image for their 
type. And the call is easier than the attribute reference since you don't 
have to figure out the name of the subtype:
     Image (Obj)
or
     Obj.Image   -- If Obj has a tagged type.

vs.

    My_Type'Image (Obj)

The gain from having an attribute is when it is automatically created in 
some cases (that's true for Streams, and it's true here). And that's where 
the issues pop up.

                                           Randy.

Re: Running a preprocessor from GPS?

[David Thompson]

On Thu, 30 Jul 2015 16:55:52 +0300, Niklas Holsti
<niklas.holsti@tidorum.invalid> wrote:
<snip>
> Some printf's support, in the "%" conversion specifications, an initial 
> part of the form "%12$" to say that the argument to be converted is 
> argument number 12 in the argument list. So the format string can pick 
> the arguments in any order it wants -- even converting the same argument 
> several times.
> 
> (I did not find this feature in the C99 standard. I don't know how 
> widely it is supported.)
> 
It's not in any C standard to date. It is in POSIX, marked XSI meaning
"extension to the C standard", and has been as long as I remember.
POSIX is pretty widely supported.