Please define the word “shape”. You never do, so the reader is left to decide for themselves (rightly or wrongly) what that definition is. Thank you! 🙂
Pattern Matching BNF-E? Below—I hack together what I think might be a sensible BNF-E Specification to describe pattern matching from the point of view of a parser/compiler. It is fair to note that even this does not “Shape” more than the course prose above. Therefore, I am left to think that the word “Shape” is really talking about the structure of data types like Maps and Lists, which appear to be collections of primitives like integer, float, string, and so on.
NOTE: Read “≜” as “consists of” or “is defined as”. Also, BNF-E walks a list of general constructs down to terminals, where one can then present “specimen” (examples). See suggested BNF-E below.
———–
¹ Match Shape and Type, and then Bind, if specified in “left” Pattern. Presume that Shape is defined as Structure—such that—containers like Maps, Lists, and Tuples having matching elements or items by either name (key lookup) or position and then a matching Type. Therefore, Shape is presumed to be determined first, then Type(s) and then Binding (if any).
² The “left” Pattern construct cannot be or contain a function.
³ However, the “right” Pattern can be or contain a function.
———–
———–
¹ A Function_call always returns Immutable_data of some Data_type as a result, which makes a Function_call syntactically legal on the “right” side of the Pattern_match_operator.
———–
Hi Larry! Thanks for the feedback on needing a definition for the “shape” of the data. I added a brief section titled “What Does “The Shape of Data” Mean?” to hopefully give move clarity.
I like the way the subject is explained: step by step, with caution to details! 🎠
This tutorial series is the best tutorial series on Elixir I found on the web.
Thanks!
Please define the word “shape”. You never do, so the reader is left to decide for themselves (rightly or wrongly) what that definition is. Thank you! 🙂
Pattern Matching BNF-E? Below—I hack together what I think might be a sensible BNF-E Specification to describe pattern matching from the point of view of a parser/compiler. It is fair to note that even this does not “Shape” more than the course prose above. Therefore, I am left to think that the word “Shape” is really talking about the structure of data types like Maps and Lists, which appear to be collections of primitives like integer, float, string, and so on.
NOTE: Read “≜” as “consists of” or “is defined as”. Also, BNF-E walks a list of general constructs down to terminals, where one can then present “specimen” (examples). See suggested BNF-E below.
===========
Pattern_match¹ ≜ Pattern² Pattern_match_operator Pattern³
———–
¹ Match Shape and Type, and then Bind, if specified in “left” Pattern. Presume that Shape is defined as Structure—such that—containers like Maps, Lists, and Tuples having matching elements or items by either name (key lookup) or position and then a matching Type. Therefore, Shape is presumed to be determined first, then Type(s) and then Binding (if any).
² The “left” Pattern construct cannot be or contain a function.
³ However, the “right” Pattern can be or contain a function.
———–
Pattern_match_operator ≜ “=”
Pattern ≜ {Immutable_data | Function_call¹}+
———–
¹ See ² for Pattern_match, above.
———–
Immutable_data ≜ {Data_type}+
Data_type ≜ {Integer
| Float
| Map
| Struct
| String
| Tuple
| Boolean
| etc}
Function_call¹ ≜ Function_name [ [“(“] Arguments [“)”] ]
———–
¹ A Function_call always returns Immutable_data of some Data_type as a result, which makes a Function_call syntactically legal on the “right” side of the Pattern_match_operator.
———–
Hi Larry! Thanks for the feedback on needing a definition for the “shape” of the data. I added a brief section titled “What Does “The Shape of Data” Mean?” to hopefully give move clarity.
The shape & type of the course are great Mark, it matches my present needs. (True, albeit v corny)