[erlang-questions] Abstract patterns, structs and frames

[Richard O'Keefe]

On 24 Feb 2009, at 3:56 pm, Richard Andrews wrote:
> I agree whole-heartedly with an optional tag - but it should be a  
> convention, in the same way that record names appear as the first  
> element in a tuple. I woudl like to see a tagged frame syntax as a  
> convenience; in the way records were added as a convenience for  
> tuples.

 From a .y file I've been using:

pattern
     : WILD
     | ...
     | lf frame_pattern RC GTR
     ;
lf
     : LSS LC
     | LSS atom_or_var LC
     ;
frame_pattern
     :
     | field_pattern_list
     ;
field_pattern_list
     : field_pattern_list COMMA ATOM TILDE pattern
     | ATOM TILDE pattern
     ;

primary
     : atom_or_var
     | ...
     | lf frame_expression RC GTR
     ;
frame_expression
     :
     | field_expression_list expression_tail
     ;
field_expression_list
     : field_expression_list COMMA ATOM TILDE expression
     | ATOM TILDE expression
     ;

So you can write things like
     <{ year ~ Year, month ~ Month }> = <date{ day ~ 27 | Old_Date }>

Why did I switch from = here to ~ ?
Because I want to keep things simple:  = means matching,
so let it _always_ mean matching, never anything else.

(The programming language S used to use <- for assignment,
  == for equality testing, and = for keyword=argument.
  Succumbing to pressure from C, they decided to allow =
  as a synonym for assignment, and R followed, not that the
  R team had much choice if R was to remain usefully compatible
  with S.  The result is that when I see R code these days I
  have to beware of the difference between
	f(x = 1)		# pass 1 to parameter called x
  and	f((x = 1))		# assign 1 to x and pass at as 1st param
  I honestly cannot see this as an improvement.  I don't want a similar
  confusion between X = 1 and x = 1 in Erlang.)

Why ~ ?  Because that's what Xerox PARC used in a series of
interesting papers.

There really is no substitute for trying things out.
I wanted <{ ... | ... }> syntax to let me make incremental
updates to a frame.  By symmetry, <{ a ~..., b ~ ... }> as
a pattern would have matched only frames with only those
two fields; to match something with more you'd have needed
<{ a ~ ..., b ~ ... | _ }>, and after a while it got quite
annoying to keep on having to write |_.  So I decided that
frame patterns should be like record patterns in some other
languages and always allow any other fields, symmetry or
no symmetry.

> The OP stated structs *or* frames would be considered in an EEP.  
> Can't we have both?

Syntax aside, they are basically the same thing.