[erlang-questions] alternate forms for comparisons >= and =<

[Richard A. O'Keefe]

On 27 Mar 2008, at 12:10 pm, Robert Virding wrote:
 > The reason the associativity of # is what it is is actually to  
force using
 > parentheses in these case.

My complaint wasn't that the precedence was wrong,
but that the table in section 6.25 doesn't make it clear what
the precedence, if any, IS.
>
> The reason the associativity of # is what it is is actually to force  
> using parentheses in these case.

I'm sorry, but I really cannot see any advantage to requiring

	X#ick.ack#ack.uck

to have parentheses.  X#(ick.ack#ack.uck) makes no sense at all.  The  
ONLY
reading that makes sense is (X#ick.ack)#ack.uck.

> While this may seem perverse at the time records were added we were  
> discussing whether to allow not just giving the key by its name, an  
> atom, but also expressions which evaluate to the key name.

For 'proper structs'/'frames'/dictionaries, such a feature makes sense.
For records, it doesn't.  It makes no sense because records are not
distinct types, and it makes no sense because the preprocessor simply
doesn't have the information available to it.  Oh, it's perfectly  
possible
for a preprocessor to generate a hidden function

	%get_field('rec.fld', #rec{fld=X}) -> X;
	%get_field(fld,       #rec{fld=X}) -> X;
	...

for each field of each record *that is visible to the preprocessor*, but
it isn't going to work with records (and field names) passed in from
other modules.  Quick example:

	-module(a).
	-export([a/2]).
	-record(bellman, {snark,boojum}).

	a(Record, Field) -> Record#Field.

	-module(b).
	-export([b/0]).
	-record(bellman, {boojum,snark}).

	b() -> a:a(#bellman{boojum=1,snark=2}, 'bellman.snark').

"For the Snark _was_ a Boojum, you see."

I presume this is why the ability to get a position number from a field
name exists, so that

	-module(a).
	-export([a/2]).
	-record(bellman, {snark,boojum}).

	a(Record, Field_Number) -> element(Field_Number, Record).

	-module(b).
	-export([b/0]).
	-record(bellman, {boojum,snark}).

	b() -> a:a(#bellman{boojum=1,snark=2}, #bellman.snark).

should work.  But in such a case it is always better to pass a fun:

	-module(a).
	-export([a/2]).
	-record(bellman, {snark,boojum}).

	a(Record, Field_Function) -> Field_Function(Record).

	-module(b).
	-export([b/0]).
	-record(bellman, {boojum,snark}).

	b() -> a:a(#bellman{boojum=1,snark=2},
		   fun (#bellman{snark=X}) -> X end).

In fact, when I first met the #<record>.<field> notation,
I expected it to be just such a function, not a number.
Perhaps there could be an abbreviated form

	fun#<record>.<field>

rewriting to whatever

	fun (#<record>{<field> = <v>}) -> <v> end

would rewrite to, for some new variable <v>.

> This was never implemented but we wanted the parser to be ready for  
> such a change and I felt that you could easily get completely  
> incomprehensible expressions without parentheses.

For the reasons above, the extension never made sense.
It is long past time to fix this grammar bug.

> The problem would not be for the parser of course but for the poor  
> human reader.
> Perhaps this was being over cautious.

Not so much over-cautious as over-optimistic (that the extension might
ever be useful).