Re: [FYI v3 8/8] Rename OP_F90_RANGE to OP_RANGE.

[Joel Brobecker <brobecker at adacore dot com>]

Hey Tom,

Glad to "see" you!

> This renames OP_F90_RANGE to OP_RANGE, and similarly renames the
> f90_range_type enum.
> 
> 2016-05-17  Tom Tromey  <tom@tromey.com>
> 
> 	* std-operator.def (OP_RANGE): Rename from OP_F90_RANGE.
> 	* rust-lang.c: Don't include f-lang.h.
> 	(rust_range, rust_compute_range, rust_subscript)
> 	(rust_evaluate_subexp): Update.
> 	* rust-exp.y: Don't include f-lang.h.
> 	(ast_range, convert_ast_to_expression): Update.
> 	* parse.c (operator_length_standard): Update.
> 	* f-lang.h (enum f90_range_type): Move to expression.h.
> 	* f-exp.y: Use OP_RANGE.
> 	* expression.h (enum range_type): New enum; renamed from
> 	f90_range_type.
> 	* expprint.c: Don't include f-lang.h.
> 	(print_subexp_standard, dump_subexp_body_standard): Use OP_RANGE.
> 	* eval.c (value_f90_subarray, evaluate_subexp_standard): Update.

FWIW, this is the kind of change I have advocated for in the past.
In other words, I didn't understand the need to show that an OP_RANGE
was an F90 range, since a range is a range. How it is expressed in
the language should not be relevant in the tree. At the time, there
was one disagreement, saying that having the F90 helped show that
this OP was only used by fortran, but I think that can be very
quickly infered, and so never found this to be a good reason. Given
that this was not a very important discussion, I let it go, but
now is a good opportunity to mention this again, because it shows
another example of why the F90 can get in the way.

-- 
Joel