Re: Ideas for Ada 200X

[Bill Findlay <yaldnifw@blueyonder.co.uk>]

On 31/5/03 20:18, in article bbavc7$ns8@library1.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

>> Does Oberon make adding 2, multiplying by 10, etc, equally concise and
>> 'unmistakable'?
> 
> Empirically, those operations do not happen nearly as often as the canonical
> I = I + 1.  See Knuth, "An Empirical Study of FORTRAN Programs", ca. 1970,
> and various follow-on papers in the decades since.

Agreed. But we are discussing ?:= operators here, not just increment.
As I said in another post, "We have a perfectly good syntax for changing a
variable, namely assignment. The fewer notations there are for the same
thing, the better, surely."

> ...  If I have to change
> 
> <some_lvalue_expr> := idem op expr;
> 
> to
> 
> shadow := idem op expr;
> <some_lvalue_expr> := shadow; -- This happens ALL THE TIME in device drivers.
>
> I'd rather not have to worry about the implications of not doing fetch *AND*
> store on the device register.  I've gotten burned on this kind of thing
> enough times to be wary.

You seem to be making major assumptions about the target architecture and
about the semantics of "INC(<some_lvalue_expr>)"  or "<some_lvalue_expr>++"

On many (if not most) ISPs, the fetch and store would be unavoidable, even
for apparently update-in-place operations. On other, regrettably popular,
ISPs there might well be no fetch. So what?

Constraining a high-level language to get architecture-dependent effects is
not the way to go IMO. That's what machine-code inserts are for.
(Or, better, abstracted operations that might use either the latter, or
language-defined operations, *if* the compiler *happens* to give what you
need.)

Further,

On 31/5/03 22:38, in article bbb7sv$8s2@library2.airnews.net, "John R.
Strohm" <strohm@airmail.net> wrote:

> OK, so what are the implications for parsing expressions?

I don't see any significant implications for *parsing* as such.
'idem' or equivalent refers to the variable on the LHS of an assignment.
It is meaningless elsewhere.

> For example:
> What does
>   I := idem + idem;
> mean?

What it seems to.
 
> How about
> 
> do_some_proc(foo, baz, idem);
> 
> Does "idem" refer back to foo, baz, or do_some_proc?

No.
 
> Should we allow, or not allow,
> 
> J := idem;
> 
> Why or why not?  What are the semantics?

The precise semantics are up for discussion, but hardly seem difficult.
I can immediately think of two reasonable definitions.

1. For the assignment:
   V := f(idem);
We set
   A := V'access; 
and V and 'idem' in the assignment are replaced by A.all, passim:
   A.all := f(A.all);

2. We define the anonymous procedure:
   procedure assign_f_to_V (V : in out T) is
   begin V := f(V); end;
and replace the assignment by the call:
   assign_f_to_V(V);

In each case all reasonable optimizations would be permitted, nay
encouraged. 

I'm sure these first cuts would need to be refined, and I'm sure there are
other approaches.

> In particular, consider:
> 
> DEVICE_DATA_REGISTER : BYTE;
> for DEVICE_DATA_REGISTER use at 16#4000_00F0#;
>  ...
> DEVICE_DATA_REGISTER := 16#40#;
> DEVICE_DATA_REGISTER := idem;
> DEVICE_DATA_REGISTER := idem + 1;
> 
> How many times should DEVICE_DATA_REGISTER be *read* by the above code
> fragment?  Why?

I note that DEVICE_DATA_REGISTER  is not declared volatile.
How many times would it be read by:

DEVICE_DATA_REGISTER := 16#40#;
DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER;
DEVICE_DATA_REGISTER := DEVICE_DATA_REGISTER + 1;

?

The answers 2, 1 and 0 all seem reasonable to me.
Why do you think the language *should* define this?

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")