Is this a bug in my code or the compiler?

Is this a bug in my code or the compiler?

[David Botton]

Given:

   function Token_Start (Source : in out Awesome.Source.Source_Type'Class)
                         return Character;
   function Token_End (Source : in out Awesome.Source.Source_Type'Class)
                       return String;

The following works:

   function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class)
                            return String
   is
      N : Character := Token_Start (Source);
   begin
      return N & Token_End (Source);
   end Get_Token_Text;

The following does not work:

   function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class)
                            return String
   is
   begin
      return Token_Start (Source) & Token_End (Source);
   end Get_Token_Text;

Token_End is never called and only the value of Token_Start.

Thanks
David Botton

Re: Is this a bug in my code or the compiler?

[Dmitry A. Kazakov]

On Fri, 12 Jun 2015 08:56:23 -0700 (PDT), David Botton wrote:

> Given:
> 
>    function Token_Start (Source : in out Awesome.Source.Source_Type'Class)
>                          return Character;
>    function Token_End (Source : in out Awesome.Source.Source_Type'Class)
>                        return String;
> 
> The following works:
> 
>    function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class)
>                             return String
>    is
>       N : Character := Token_Start (Source);
>    begin
>       return N & Token_End (Source);
>    end Get_Token_Text;
> 
> The following does not work:
> 
>    function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class)
>                             return String
>    is
>    begin
>       return Token_Start (Source) & Token_End (Source);
>    end Get_Token_Text;
> 
> Token_End is never called and only the value of Token_Start.

That is one of the reasons why in-out's were not allowed for functions in
Ada 83. The code is clearly erroneous because the computation order is not
defined. Possibly Token_End is called before Token_Start!

P.S. When in-out's for functions were discussed I proposed not to allow
them as operands in operations that do not state the evaluation order. E.g.

   function Foo (X : in out T) return Boolean;

Foo (A) and Foo (A) -- Illegal
Foo (A) and then Foo (A) -- Legal

P.P.S. It would become even worse with fine-grained parallelism, as Georg
keep on suggesting. If Token_Start (Source) and Token_End (Source) were
running in parallel on different cores, that would be great fun!

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

Re: Is this a bug in my code or the compiler?

[G.B.]

On 12.06.15 18:15, Dmitry A. Kazakov wrote:
> Foo (A) and Foo (A) -- Illegal
> Foo (A) and then Foo (A) -- Legal

C has similar features...

> P.P.S. It would become even worse with fine-grained parallelism, as Georg
> keep on suggesting.

Not sure to what this is referring (or how concatenation
"&" necessitates the apparent omission of a call, if not
a gotcha?).

Query-command separation (on objects) seems far better than
functions that make their side effects explicit.
IIUC, SofCheck has brought tons of aliasing analysis and
more to the AdaCore offerings, plus Parasail's automatically
parallel loops...

So, in Ada 83, when A is of an access type,

    Foo (A) and Foo (A)  -- Legal

Moreover, if B and A become pointing to the same object,

    Foo (A) and Foo (B)  -- Legal, same effects

Can a compiler detect this? --- So, you'd be asking for pure
functions? Or total referential transparency?

Re: Is this a bug in my code or the compiler?

[Dmitry A. Kazakov]

On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote:

> On 12.06.15 18:15, Dmitry A. Kazakov wrote:
>> Foo (A) and Foo (A) -- Illegal
>> Foo (A) and then Foo (A) -- Legal
> 
> C has similar features...

So?

>> P.P.S. It would become even worse with fine-grained parallelism, as Georg
>> keep on suggesting.
> 
> Not sure to what this is referring

Parallel evaluation of arguments.

> Query-command separation (on objects) seems far better than
> functions that make their side effects explicit.

You forgot about indefinite return values, which are not available for
procedures. The real motivation to have functions with side effects is such
return values.

> So, in Ada 83, when A is of an access type,

That does not change anything because:
 
>     Foo (A) and Foo (A)  -- Legal

Only if A is a constant access. Illegal otherwise.

With parallelism atomicity of all immutable operations would additionally
be required. Which is why that sort of parallelism is a can of worms.

> Moreover, if B and A become pointing to the same object,
> 
>     Foo (A) and Foo (B)  -- Legal, same effects
> 
> Can a compiler detect this?

Easily. Access is logically a referential type which, if properly designed,
should be a subtype of the target type. Thus the same rules would apply. If
access is meant to be a type of its own, like a pointer in C, then the
language should better have no such types.

> --- So, you'd be asking for pure
> functions? Or total referential transparency?

Both.

Though purity is not enough for parallelism. A pure function may still get
broken under parallel access if not atomic.

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

Re: Is this a bug in my code or the compiler?

[Georg Bauhaus]

On 12.06.15 20:00, Dmitry A. Kazakov wrote:
> On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote:
>
>> On 12.06.15 18:15, Dmitry A. Kazakov wrote:
>>> Foo (A) and Foo (A) -- Illegal
>>> Foo (A) and then Foo (A) -- Legal
>>
>> C has similar features...
>
> So?
>
>>> P.P.S. It would become even worse with fine-grained parallelism, as Georg
>>> keep on suggesting.
>>
>> Not sure to what this is referring
>
> Parallel evaluation of arguments.

Yes, but where is the difference, exactly, between incorrect due
to order dependence, and incorrect due to sharing issues? If
nothing is lost by forcing an order on evaluation of arguments
on all programs, then I don't know any more why that's not enforced
by languages, and why instead we saw Haskell.

>> So, in Ada 83, when A is of an access type,
>
> That does not change anything because:
>
>>      Foo (A) and Foo (A)  -- Legal
>
> Only if A is a constant access. Illegal otherwise.

Is there chapter and verse in the 83 LRM for this? I found this in 1.6:

"Whenever the reference manual specifies that different parts of a given
  construct are to be executed in some order that is not defined by the language,
  this means that the implementation is allowed to execute these parts
  in any given order, following the rules that result from that given order,
  but not in parallel. Furthermore, the construct is incorrect if execution
  of these parts in a different order would have a different effect.
  Compilers are not required to provide either compilation-time or run-time
  detection of incorrect order dependences."

(No mention of legality here.)

So, is GNAT buggy if it accepts this Ada 83 program (you claim that
it is *easy* to detect aliasing of A and B):

WITH Text_IO;
PROCEDURE Par IS
    TYPE I IS RANGE 1 .. 3;
    TYPE Ptr IS ACCESS I;
    A, B: Ptr;
    V, Legal : Boolean;
    
    FUNCTION Foo (X : Ptr) RETURN Boolean IS SEPARATE;
    
    PACKAGE Boolean_Io IS NEW Text_IO.Enumeration_IO (Boolean);
BEGIN
    A := NEW I'(1);
    
    Boolean_Io.Get (V);

    IF V THEN
       B := A;
    ELSE
       B := NEW I'(3);
    END IF;
    
    Legal := Foo (A) AND Foo (B);  -- legal?

END Par;

>  parallelism is a can of worms.

... if designed without regard to parallel evaluation/execution.
That's a matter of course, isn't it?

Re: Is this a bug in my code or the compiler?

[Dmitry A. Kazakov]

On Sat, 13 Jun 2015 12:04:57 +0200, Georg Bauhaus wrote:

> On 12.06.15 20:00, Dmitry A. Kazakov wrote:
>> On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote:

>>>      Foo (A) and Foo (A)  -- Legal
>>
>> Only if A is a constant access. Illegal otherwise.
> 
> Is there chapter and verse in the 83 LRM for this?

Constant access was introduced in Ada 95, I believe.

>>  parallelism is a can of worms.
> 
> ... if designed without regard to parallel evaluation/execution.
> That's a matter of course, isn't it?

Well, the parallelism of that kind is too low-level.

There could be different approaches to the issue. One is a contract on the
arguments evaluation order, which is usually proposed. It does not make
much sense because the operation usually has no idea about the semantics of
the actual arguments.

Another approach would be properties of the operation's results influencing
the order, e.g. purity. By-value vs. by-reference mode is an example of
this approach. I.e. instead of stating any order, the set of possible
orders would be deduced from the expressions of actual arguments.

The third approach is explicit ordering syntax, e.g. some extended syntax
of the keyed argument association.

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

Re: Is this a bug in my code or the compiler?

[G.B.]

On 13.06.15 12:32, Dmitry A. Kazakov wrote:

>>>   parallelism is a can of worms.
>>
>> ... if designed without regard to parallel evaluation/execution.
>> That's a matter of course, isn't it?
>
> Well, the parallelism of that kind is too low-level.

I find this ascription of low level a little too general,
missing opportunities, and pessimistic. After all, processors
do manage to provide even lower level parallelism internally,
and while difficult to predict, the results seem logically
correct.

> The third approach is explicit ordering syntax, e.g. some extended syntax
> of the keyed argument association.

Yes. But how?

"&" means "concatenation", therefore sequencing, only at the level of
metaphor, not at the level of programming. For operators, consider

   function "+" (Left : S; Right : T) return R;

where + is any infix operator. Knowing that the order of evaluation of
Left and Right is not specified leads to better design: If you know it
isn't, then you start fixing the interface of S and T in view of "+".

To me, this looks like "normal", good O-O design principles at work,
in that Left's operation does not rely on Right's internal state, and
vice versa.  It avoids spaghetti style design, as a consequence of
no order of evaluation being specified.

Conversely, if order is needed when evaluating input to "+", i.e. if a
particular succession of states is needed, then this order can be
established using a constant, or a renaming.

So in sum, suppose the absence of an ordering stricture could be made
explicit syntactically. Would it be a boon, both driving better
interfaces and also an aid to understanding?

Re: Is this a bug in my code or the compiler?

[Dmitry A. Kazakov]

On Mon, 15 Jun 2015 12:37:37 +0200, G.B. wrote:

> On 13.06.15 12:32, Dmitry A. Kazakov wrote:
> 
>>>>   parallelism is a can of worms.
>>>
>>> ... if designed without regard to parallel evaluation/execution.
>>> That's a matter of course, isn't it?
>>
>> Well, the parallelism of that kind is too low-level.
> 
> I find this ascription of low level a little too general,
> missing opportunities, and pessimistic. After all, processors
> do manage to provide even lower level parallelism internally,
> and while difficult to predict, the results seem logically
> correct.

Determinism /= high level.

>> The third approach is explicit ordering syntax, e.g. some extended syntax
>> of the keyed argument association.
> 
> Yes. But how?
> 
> "&" means "concatenation", therefore sequencing, only at the level of
> metaphor, not at the level of programming. For operators, consider
> 
>    function "+" (Left : S; Right : T) return R;

E.g.

   "+" (Right #> Y, Left #> X);

#> reads evaluated left-to-right.

> To me, this looks like "normal", good O-O design principles at work,
> in that Left's operation does not rely on Right's internal state, and
> vice versa.

It is not about the state in this case. When the body of + is called its
arguments already reached their states.

The concept of evaluation order is orthogonal to procedural/states POV.
Compare procedure with entry point. Entry point is nothing but a procedure
with an evaluation order enforced on separate tasks.

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

Re: Is this a bug in my code or the compiler?

[Simon Wright]

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

>    "+" (Right #> Y, Left #> X);
>
> #> reads evaluated left-to-right.

   "+" (Right => Y and then Left => X);

maybe.

And you could even put it on the spec.

Re: Is this a bug in my code or the compiler?

[Dmitry A. Kazakov]

On Mon, 15 Jun 2015 13:31:33 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>    "+" (Right #> Y, Left #> X);
>>
>> #> reads evaluated left-to-right.
> 
>    "+" (Right => Y and then Left => X);
> 
> maybe.

"and then" could be ambiguous.

> And you could even put it on the spec.

You mean:

   function "+" (Left : T and then Right : T) return T;

?

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

Re: Is this a bug in my code or the compiler?

[Simon Wright]

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

> On Mon, 15 Jun 2015 13:31:33 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>>    "+" (Right #> Y, Left #> X);
>>>
>>> #> reads evaluated left-to-right.
>> 
>>    "+" (Right => Y and then Left => X);
>> 
>> maybe.
>
> "and then" could be ambiguous.

?

>> And you could even put it on the spec.
>
> You mean:
>
>    function "+" (Left : T and then Right : T) return T;
>
> ?

Yes, I guess, but it's not going to happen!

Re: Is this a bug in my code or the compiler?

[G.B.]

On 15.06.15 16:56, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>
>> On Mon, 15 Jun 2015 13:31:33 +0100, Simon Wright wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>
>>>>     "+" (Right #> Y, Left #> X);
>>>>
>>>> #> reads evaluated left-to-right.
>>>
>>>     "+" (Right => Y and then Left => X);
>>>
>>> maybe.
>>
>> "and then" could be ambiguous.
>
> ?

It could be a little dangerous in general if there is
a default parameter,

    (Right => Y and then Left >= X);

Also, if there were permission to drop parentheses around
a record literal in

    (Right => Y and then (Left => X));

if this were to make sense somehow.

Re: Is this a bug in my code or the compiler?

[Brad Moore]

On 2015-06-12 12:00 PM, Dmitry A. Kazakov wrote:
> On Fri, 12 Jun 2015 19:25:00 +0200, G.B. wrote:
>
>> On 12.06.15 18:15, Dmitry A. Kazakov wrote:
>>> Foo (A) and Foo (A) -- Illegal
>>> Foo (A) and then Foo (A) -- Legal
>>
>> C has similar features...
>
> So?
>
>>> P.P.S. It would become even worse with fine-grained parallelism, as Georg
>>> keep on suggesting.
>>
>> Not sure to what this is referring
>
> Parallel evaluation of arguments.

In the above case with regard to implicit parallelism, the compiler
should be able to determine that the two calls both involve
modifications the same storage, which would be a data race, and then
rule out parallelism and thus generate sequential code. So the issue
here is not about parallelism, but about ordering of evaluation for the
sequential case.

For the sequential case, I would think that a good compiler could also
detect that an expression with multiple calls with in out parameters to
the same storage is likely a problem with evaluation order, and
generate a warning to the programmer, which could be averted by coding
with "and then" for force evaluation order. If your compiler does not
generate such a warning, it might be good to ask your vendor  to
provide such a warning.

Or a programmer could adopt a programming style to use "and then" for
the general case, which I believe could be checked by a tool such as
AdaControl.

This should work for the case Boolean sub expressions, but doesn't help 
in the case of concatenation operations. Hopefully, the compiler could
at least generate warnings for this case, then the programmer can
decide how best to address the warning.

>
>> Query-command separation (on objects) seems far better than
>> functions that make their side effects explicit.
>
> You forgot about indefinite return values, which are not available for
> procedures. The real motivation to have functions with side effects is such
> return values.
>
>> So, in Ada 83, when A is of an access type,
>
> That does not change anything because:
>
>>      Foo (A) and Foo (A)  -- Legal
>
> Only if A is a constant access. Illegal otherwise.
>
> With parallelism atomicity of all immutable operations would additionally
> be required. Which is why that sort of parallelism is a can of worms.
>
>> Moreover, if B and A become pointing to the same object,
>>
>>      Foo (A) and Foo (B)  -- Legal, same effects
>>
>> Can a compiler detect this?


In Ada 2012, we have the attributes 'Has_Same_Storage and 'Overlaps_Storage.

These were introduced to facilitate writing preconditions for a
subprogram.  One would think that if these are available for checking
multiple parameters of a subprogram, the compiler could also do similar
checks for the parameters of subprograms that are part of the same
expression. In some cases, this could be a compile time check, but in
others, it may need to be a run-time check, that possibly could be
enabled/disabled via compiler options.

Brad

>
> Easily. Access is logically a referential type which, if properly designed,
> should be a subtype of the target type. Thus the same rules would apply. If
> access is meant to be a type of its own, like a pointer in C, then the
> language should better have no such types.
>
>> --- So, you'd be asking for pure
>> functions? Or total referential transparency?
>
> Both.
>
> Though purity is not enough for parallelism. A pure function may still get
> broken under parallel access if not atomic.
>

Re: Is this a bug in my code or the compiler?

[David Botton]

> That is one of the reasons why in-out's were not allowed for functions in
> Ada 83. The code is clearly erroneous because the computation order is not
> defined. Possibly Token_End is called before Token_Start!

A programmer having to worry about order of operation in a concatenation operation is a language flaw in my opinion. I can accept the issue in evaluation order of Boolean expressions or numerics (and knew of that), but not in non numeric types.

David Botton

Re: Is this a bug in my code or the compiler?

[Dmitry A. Kazakov]

On Fri, 12 Jun 2015 10:53:04 -0700 (PDT), David Botton wrote:

>> That is one of the reasons why in-out's were not allowed for functions in
>> Ada 83. The code is clearly erroneous because the computation order is not
>> defined. Possibly Token_End is called before Token_Start!
> 
> A programmer having to worry about order of operation in a concatenation
> operation is a language flaw in my opinion.

Yes, but in Ada 83 side effects in functions were frowned at. The troubles
arose first with side effects used quite liberally in the standard library
and by most programmers.

> I can accept the issue in
> evaluation order of Boolean expressions or numerics (and knew of that),
> but not in non numeric types.

The name suggests that short-cut logical operations were considered as a
syntax sugar to save keystrokes - a replacement for nested IFs. Quickly
enough it was discovered that in some contexts you cannot have IFs (e.g. in
barriers) and that people disliked nested IFs anyway.

But the issues of ordering and re-ordering, eager vs. lazy evaluation,
aliasing, purity, atomicity are not limited to Boolean types.

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

Re: Is this a bug in my code or the compiler?

[marciant]

On Friday, June 12, 2015 at 2:11:33 PM UTC-4, Dmitry A. Kazakov wrote:
> 
> The name suggests that short-cut logical operations were considered as a
> syntax sugar to save keystrokes - a replacement for nested IFs. Quickly
> enough it was discovered that in some contexts you cannot have IFs (e.g. in
> barriers) and that people disliked nested IFs anyway.
> 

(nit-picker alert! ;-)

They are called short-circuit not short-cut, short in that normally all parts of a boolean expression are evaluated (even those that would cause an exception with elements some values).  That was to improve testability: you are normally sure that some part of an expression isn't actually never evaluated with some given test input.  It also can minimize execution time variance.

I think that the canonical example is something like "if x/=0 and then y/x=n then ..." but I see what you mean by less nested if's.   But avoiding the nested if's was less about minimizing typing and more about increasing readability.

Re: Is this a bug in my code or the compiler?

[Jeffrey R. Carter]

On 06/12/2015 10:53 AM, David Botton wrote:
> 
> A programmer having to worry about order of operation in a concatenation
> operation is a language flaw in my opinion. I can accept the issue in
> evaluation order of Boolean expressions or numerics (and knew of that), but
> not in non numeric types.

Boolean is a non-numeric type. You must mean "non-numeric types other than
boolean types".

You're using

function "&" (Left : in Character; Right : in String) return String;

which is predefined (and a similar "&" is predefined for all 1-D array types),
and want it to have different evaluation rules than if you define

function "&" (Left : in Integer; Right : in Integer) return Integer;

?

Order of evaluation is not defined for any subprogram (with more than 1
parameter). That's a simple rule. What you want seems much more complex.

-- 
Jeff Carter
"Unix and C are the ultimate computer viruses."
Richard Gabriel
99

Re: Is this a bug in my code or the compiler?

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> function "&" (Left : in Character; Right : in String) return String;

function "&" (Left : in Character; Right : in Character) return String;

ARM 4.5.3(4) (which actually defaults the mode rather than saying 'in')

Re: Is this a bug in my code or the compiler?

[Jeffrey R. Carter]

On 06/12/2015 12:55 PM, Simon Wright wrote:
> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
> 
>> function "&" (Left : in Character; Right : in String) return String;
> 
> function "&" (Left : in Character; Right : in Character) return String;
> 
> ARM 4.5.3(4) (which actually defaults the mode rather than saying 'in')

No, the function he was using as his right argument returned String.

-- 
Jeff Carter
"Unix and C are the ultimate computer viruses."
Richard Gabriel
99

Re: Is this a bug in my code or the compiler?

[Simon Wright]

"Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:

> On 06/12/2015 12:55 PM, Simon Wright wrote:
>> "Jeffrey R. Carter" <spam.jrcarter.not@spam.not.acm.org> writes:
>> 
>>> function "&" (Left : in Character; Right : in String) return String;
>> 
>> function "&" (Left : in Character; Right : in Character) return String;
>> 
>> ARM 4.5.3(4) (which actually defaults the mode rather than saying 'in')
>
> No, the function he was using as his right argument returned String.

I'll get me coat

Re: Is this a bug in my code or the compiler?

[jan.de.kruyf]

On Friday, June 12, 2015 at 7:53:07 PM UTC+2, David Botton wrote:

> 
> A programmer having to worry about order of operation in a concatenation operation is a language flaw in my opinion. I can accept the issue in evaluation order of Boolean expressions or numerics (and knew of that), but not in non numeric types.

Or, uh . . . A language designer having to worry about...  :)

I was going to post when I first saw the issue. But maybe I must still say it:
Programming twice removed from the bare metal might _seem_ easy and convenient, but it _is_ not in my experience.  Plenty of 'wait-a-bit' thorns await those who think otherwise.

A computer is a tool. A language is a tool. When you know your tools you can make wonders. When you dont . . you might need a few lessons of that most detested computer scientist Prof Wirth. :)

cheers, keep well David,

j.


> 
> David Botton

Re: Is this a bug in my code or the compiler?

[David Botton]

> Or, uh . . . A language designer having to worry about...  :)

Actually it is exactly what a designer should think about. Want to prevent when and how reasonable errors by the use of that language.
 
> I was going to post when I first saw the issue. But maybe I must still say it:
> Programming twice removed from the bare metal might _seem_ easy and convenient, but it _is_ not in my experience.  Plenty of 'wait-a-bit' thorns await those who think otherwise.

Yes, I could just write in assembly, but that would remove the efficiency of my creativity as a programmer :) I choose my tools to assist me in both beautiful expression of the idea that others can read (and as Wirth points out in Programming in Oberon, Assembly is unreadable) and to assist me in correctness.


> A computer is a tool. A language is a tool. When you know your tools you can make wonders. When you dont . . you might need a few lessons of that most detested computer scientist Prof Wirth. :)

Not sure I got that one. I assume first I was wrong and the tool had a different idea than I, as was evident. Not sure though how Wirth fits in, since in the next line in the Wirth text I just mentioned, he points out a program that is not readable by humans is worthless. (I wish he would have qualified his statements a bit more and sorry for not exact quotes but close enough paraphrase here. I don't have time to grab the PDF).

I would say that concatenation operations with order of evaluation not significant is an unexpected gotcha for most human readers and so a language should not tolerate it.

David Botton

Re: Is this a bug in my code or the compiler?

[Dennis Lee Bieber]

On Fri, 12 Jun 2015 15:10:21 -0700 (PDT), David Botton <david@botton.com>
declaimed the following:

>Yes, I could just write in assembly, but that would remove the efficiency of my creativity as a programmer :) I choose my tools to assist me in both beautiful expression of the idea that others can read (and as Wirth points out in Programming in Oberon, Assembly is unreadable) and to assist me in correctness.
>
	Assembly is tedious -- and hardware specific (how much time did the
PowerPC designers spend coming up with "EIEIO" as an instruction? rather
than something like memsync; 68K with its differentiation between data and
address registers, along with lots of addressing modes; ARM Thumb-2
[purported RISC architecture] with some instructions essentially embedding
what would be stand-alone shift instructions as just parts of the
addressing mode... Give me a good old "logical" Sigma-6 meta-symbol file!)

	PERL is unreadable...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

Re: Is this a bug in my code or the compiler?

[jan.de.kruyf]

On Saturday, June 13, 2015 at 12:10:22 AM UTC+2, David Botton wrote:
> > Or, uh . . . A language designer having to worry about...  :)
> 

David,

> Actually it is exactly what a designer should think about. Want to prevent when and how reasonable errors by the use of that language.
>  

Of course I agree with you there; but there is a fine line, that we as programmers are not always aware of. Which is the balance between nannying the programmers and giving them true power. (not in the C sense)

> 
> Yes, I could just write in assembly, but that would remove the efficiency of my creativity as a programmer :) I choose my tools to assist me in both beautiful expression of the idea that others can read (and as Wirth points out in Programming in Oberon, Assembly is unreadable) and to assist me in correctness.

Which is fully my sentiment. But I grew up with those 8 bitters. So historically I might be more inclined not to trust my tools, unless I fully understand them. Which is very hard of course these days.


> 
> Not sure I got that one. I assume first I was wrong and the tool had a different idea than I, as was evident. 

I always blame the tool first (shame faced . .) but that got me quite far because then I start taking the tools apart, to see what is cooking. (and most of the time find it is me)

> Not sure though how Wirth fits in

I was just repeating the sentiment of the group in a joking way, as I understood it a while back.

> (I wish he would have qualified his statements a bit more.

He killed his life's work by not communicating. And what is worse, the faculty had no real way forward when he left. Nothing is happening there anymore.
His secrets are revealed in his code.

> I would say that concatenation operations with order of evaluation not significant is an unexpected gotcha for most human readers and so a language should not tolerate it.

Or perhaps this "must have" runs amok with the limitations Dmitry pointed out in the second post of this thread, but the designers did not realize at the time (it was still single processors then).
This touches the deepest levels of computer science. Many thick books have been written about order of evaluation and concurrent execution.
Look at the amount of work it took to clean up the linux kernel so it could be more or less real time and pre-emptible.

Now it will take a lot of courage to go back a few steps and see if we can implement this thing in a different way, which automatically resolves the concurrency issue.

If you are interested in that kind of thing, have a look at the chapter about texts in Project Oberon (the book that describes the operating system, and the compiler) He found a very clever way to deal with strings, texts, streams fonts etc.
Any text consists of a collection of pieces (strings) in a double linked list. And each piece has attributes (font, color, anything). And a text knows how to load itself and store itself (That is also where the mess gets sorted and the pieces are collected into bigger pieces, where the attributes allow)

So if you want to insert some text you just split the piece in two and insert a new piece, and so on. The concept looks very messy at first, but it works very fast and it automatically deals with wide strings etc. by virtue of the attributes.
As a programmer you have a unified and coherent view of the whole text business, except for the most trivial strings, there you just roll your own if needed.

enjoy your weekend,

j.

Re: Is this a bug in my code or the compiler?

[Randy Brukardt]

>David Botton" <david@botton.com> wrote in message 
>news:afb6fe82-1f67-49a8-b4b1-f814a71ba8fd@googlegroups.com...
>> That is one of the reasons why in-out's were not allowed for functions in
>> Ada 83. The code is clearly erroneous because the computation order is 
>> not
>> defined. Possibly Token_End is called before Token_Start!
>
> A programmer having to worry about order of operation in a concatenation
> operation is a language flaw in my opinion. I can accept the issue in 
> evaluation
> order of Boolean expressions or numerics (and knew of that), but not in
> non numeric types.

Yes, but at least we tried to prevent obvious cases. (It's way too late to 
change the order of evaluation rules for Ada!) And you need a lot more 
complex program to show a problem. Simple cases are illegal; we only made 
the rules apply to simple cases so that there clearly was a problem before 
the code was rejected.

                             Randy.

Re: Is this a bug in my code or the compiler?

[Randy Brukardt]

"David Botton" <david@botton.com> wrote in message 
news:afb6fe82-1f67-49a8-b4b1-f814a71ba8fd@googlegroups.com...
>> That is one of the reasons why in-out's were not allowed for functions in
>> Ada 83. The code is clearly erroneous because the computation order is 
>> not
>> defined. Possibly Token_End is called before Token_Start!
>
> A programmer having to worry about order of operation in a concatenation
> operation is a language flaw in my opinion. I can accept the issue in
> evaluation order of Boolean expressions or numerics (and knew of that),
> but not in non numeric types.

Lots of people would agree with you, but neither J. Ichbiah or STT would, so 
Ada doesn't define the order of evaluation of almost anything: parameters 
(not just concat, but in all subprogram calls), aggregate components, and 
many more things. It would be way too disruptive to try to introduce any 
such rules now, especially as there are legal dispatching calls that cannot 
be evaluated left-to-right.

The rules in 6.4.1 are supposed to prevent the worst problems, but of course 
they only work if correctly implemented.

I'd suggest submitting one or more ACATS tests. :-)

                    Randy.

Re: Is this a bug in my code or the compiler?

[Jeffrey R. Carter]

On 06/12/2015 08:56 AM, David Botton wrote:
> Given:
> 
>    function Token_Start (Source : in out Awesome.Source.Source_Type'Class)
>                          return Character;
>    function Token_End (Source : in out Awesome.Source.Source_Type'Class)
>                        return String;
> 
> The following works:
> 
>    function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class)
>                             return String
>    is
>       N : Character := Token_Start (Source);
>    begin
>       return N & Token_End (Source);
>    end Get_Token_Text;
> 
> The following does not work:
> 
>    function Get_Token_Text (Source : in out Awesome.Source.Source_Type'Class)
>                             return String
>    is
>    begin
>       return Token_Start (Source) & Token_End (Source);
>    end Get_Token_Text;

Given that the Source parameters to both Token_Start and Token_End are mode "in
out", I presume that both functions modify Source and therefore, Token_Start
must be called before Token_End. Your 1st version ensures this order; your 2nd
does not. You are presuming an order of evaluation of the parameters to "&" that
is not guaranteed.

What happens if Token_End is called 1st?

-- 
Jeff Carter
"Unix and C are the ultimate computer viruses."
Richard Gabriel
99

Re: Is this a bug in my code or the compiler?

[Jacob Sparre Andersen]

David Botton wrote:

>    function Token_Start (Source : in out Awesome.Source.Source_Type'Class)
>                          return Character;
>    function Token_End (Source : in out Awesome.Source.Source_Type'Class)
>                        return String;

>    return Token_Start (Source) & Token_End (Source);

Doesn't your compiler warn you about modifying Source in two places
(roughly) at the same time?

GNAT 4.9 complains loudly about the roughly similar case:

   procedure P (A, B : in out T);

   P (C, C);

But I can't get it to complain about a simplified variation of your
case.

Maybe there is an AdaControl rule to detect this kind of problem.  But
it is an obviously faulty expression, so it would make most sense if it
was forbidden in the language.

Greetings,

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."

Re: Is this a bug in my code or the compiler?

[J-P. Rosen]

Le 13/06/2015 15:33, Jacob Sparre Andersen a écrit :
>   procedure P (A, B : in out T);
> 
>    P (C, C);
> 
> But I can't get it to complain about a simplified variation of your
> case.
> 
> Maybe there is an AdaControl rule to detect this kind of problem. 
Of course. It's called Parameter_Aliasing :-)

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Is this a bug in my code or the compiler?

[Jacob Sparre Andersen]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 13/06/2015 15:33, Jacob Sparre Andersen a écrit :
>>   procedure P (A, B : in out T);
>> 
>>    P (C, C);
>> 
>> But I can't get it to complain about a simplified variation of your
>> case.
>> 
>> Maybe there is an AdaControl rule to detect this kind of problem. 
> Of course. It's called Parameter_Aliasing :-)

I tried it without luck on this test case:

% cat bad_style_2.adb
with Ada.Integer_Text_IO,
     Ada.Text_IO;

procedure Bad_Style_2 is
   function F (I : in out Integer) return Character;
   function G (I : in out Integer) return String;

   function F (I : in out Integer) return Character is
   begin
      return R : Character do
         if I < 0 then
            R := '-';
         else
            R := '+';
         end if;

         I := 2 * I;
      end return;
   end F;

   function G (I : in out Integer) return String is
   begin
      return R : constant String := Integer'Image (I) do
         I := I - 1;
      end return;
   end G;

   C : Integer := 3;
begin
   Ada.Text_IO.Put_Line (F (C) & G (C));
   Ada.Integer_Text_IO.Put (C);
end Bad_Style_2;
% adactl -l 'check parameter_aliasing' bad_style_2.adb
%

I.e. no detection of "expression parameter aliasing" (or what we should
call it).  I think it is only slightly harder to detect than plain
parameter aliasing, but I'm not yet quite proficient enough in ASIS to
promise to contribute a new rule to AdaControl.

Greetings,

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."

Re: Is this a bug in my code or the compiler?

[J-P. Rosen]

Le 13/06/2015 18:43, Jacob Sparre Andersen a écrit :
>>> Maybe there is an AdaControl rule to detect this kind of problem. 
>> > Of course. It's called Parameter_Aliasing :-)
> I tried it without luck on this test case:
[Snip example on a function call]

Yeap, it works on procedure and entry calls, I didn't put (yet) the case
of function calls... Added to my todo list for the next version.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Is this a bug in my code or the compiler?

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87si9vohrg.fsf@adaheads.sparre-andersen.dk...
> David Botton wrote:
>
>>    function Token_Start (Source : in out 
>> Awesome.Source.Source_Type'Class)
>>                          return Character;
>>    function Token_End (Source : in out Awesome.Source.Source_Type'Class)
>>                        return String;
>
>>    return Token_Start (Source) & Token_End (Source);
>
> Doesn't your compiler warn you about modifying Source in two places
> (roughly) at the same time?

As I noted, this code is illegal in Ada. Forget the warning, and fix the 
compiler to detect the error!

             Randy.

Re: Is this a bug in my code or the compiler?

[Randy Brukardt]

"David Botton" <david@botton.com> wrote in message 
news:4f4cd4b1-0a6d-441b-a4f7-98add70e4e1e@googlegroups.com...
> Given:
>
>   function Token_Start (Source : in out Awesome.Source.Source_Type'Class)
>                         return Character;
>   function Token_End (Source : in out Awesome.Source.Source_Type'Class)
>                       return String;
>
> The following works:
>
>   function Get_Token_Text (Source : in out 
> Awesome.Source.Source_Type'Class)
>                            return String
>   is
>      N : Character := Token_Start (Source);
>   begin
>      return N & Token_End (Source);
>   end Get_Token_Text;
>
> The following does not work:
>
>   function Get_Token_Text (Source : in out 
> Awesome.Source.Source_Type'Class)
>                            return String
>   is
>   begin
>      return Token_Start (Source) & Token_End (Source);
>   end Get_Token_Text;
>
> Token_End is never called and only the value of Token_Start.

I would have expected this second expression to be illegal, because it seems 
to violate 6.4.1(6.18-19/3). That rule was introduced in Ada 2012 along with 
"in out" function parameters to avoid "obvious" dependence on order of 
evaluation.

The rule is:

If a construct C has two or more direct constituents that are names or 
expressions whose evaluation may occur in an arbitrary order, at least one 
of which contains a function call with an in out or out parameter, then the 
construct is legal only if:

For each name N that is passed as a parameter of mode in out or out to some 
inner function call C2 (not including the construct C itself), there is no 
other name anywhere within a direct constituent of the construct C other 
than the one containing C2, that is known to refer to the same object.

(Here C is "&", N is Source, and C2 is Token_Start; the rule says that 
Source can't appear outside of the call of Token_Start, and it does. I'd 
suggest filing a bug report.)

                            Randy.

Re: Is this a bug in my code or the compiler?

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> I would have expected this second expression to be illegal, because it
> seems to violate 6.4.1(6.18-19/3). That rule was introduced in Ada
> 2012 along with "in out" function parameters to avoid "obvious"
> dependence on order of evaluation.

Is there an ACATS test for that rule?  (If not, then I'll volunteer to
formulate and submit one.)

Greetings,

Jacob
-- 
"It is very easy to get ridiculously confused about the
 tenses of time travel, but most things can be resolved
 by a sufficiently large ego."

Re: Is this a bug in my code or the compiler?

[brbarkstrom]

Oddly, the June 2015 issue of the Comm. ACM showed up on
the same day I noted this thread.  That issue contains
Leslie Lamport's 2013 Turing Prize lecture 

Lamport, L., 2015: The Computer Science of Concurrency:
The Early Years, CACM, Vol. 58, No. 6, pp. 71-76.

The paper is reasonably readable if you don't mind a bit
of math.  It seems to me that David's program has instances
that fall into problems that require mutual exclusion, which
Lamport discusses in a fair amount of detail.  As he comments
concurrency problems are subtle and complex - and hard to 
solve correctly.  I'm not sure whether it's fair to expect
the compiler to be able to deal by itself with a problem
that might involve an underspecified set of preconditions.
Lamport might suggest that it needs a mathematical specification
of the type he sets up in his TLA+ language (see
<http://research.microsoft.com/en-us/um/people/lamport/tla/tla.html>).
In the Ada world, this might be one of the targets of SPARK.

Bruce B.

Re: Is this a bug in my code or the compiler?

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87k2v6oe6q.fsf@adaheads.sparre-andersen.dk...
> Randy Brukardt wrote:
>
>> I would have expected this second expression to be illegal, because it
>> seems to violate 6.4.1(6.18-19/3). That rule was introduced in Ada
>> 2012 along with "in out" function parameters to avoid "obvious"
>> dependence on order of evaluation.
>
> Is there an ACATS test for that rule?  (If not, then I'll volunteer to
> formulate and submit one.)

Not yet. When I was going to write one, there was some talk of changing the 
rules, so I put it off. And of course it never made it back to the top 
(yet).

                                       Randy.