<div dir="ltr"><div class="gmail_extra"><div>On Fri, Feb 5, 2016 at 3:24 AM, Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>> wrote:</div><div>> </div><div>> The idea was that by the time the book was published the book and</div><div>> implementation would be in phase with each other.</div><div>> </div><div>> There's a back story here:</div><div>> </div><div>> In the early days of Erlang the implementation and the documentation were</div><div>> always out of phase. This means there was a heck of a lot of code and very</div><div>> little documentation.</div><div>> </div><div>> When the documentation was written there was short time when it was in phase</div><div>> with the code but then the code changed and the documentation was not</div><div>> updated. The point is the two were never in phase, or at least if there were</div><div>> in phase it was for a short time.</div><div>> </div><div>> At the time I used to say</div><div>> </div><div>>     "If the code and documentation different, read the code."</div><div>> </div><div>> But reading code is difficult - especially for a beginner.</div><div>> </div><div>> Anyway even if I can understand the code I don't know a) what it's supposed</div><div>> to do and b) if it is buggy.</div><div>> </div><div>> When the code and documentation differ I don't know which is definitive.</div><div>> </div><div>> At a certain point in time I thought to myself - "this is stupid" so I</div><div>> changed strategy.</div><div>> </div><div>> I said -</div><div>> </div><div>>     "the documentation should describe that the system is supposed to do, and</div><div>>     if the code and documentation differ it's a bug and the code is wrong."</div><div>> </div><div>> Then I wrote the documentation from the standpoint of what the system should</div><div>> do rather than what it actually does, and I do this in my books.</div><div>> </div><div>> Most system documentation describe what the code does, and not what it should</div><div>> do.</div><div>> </div><div>> In an ideal world the two should be the same - but this is only true in very</div><div>> mature systems.</div><div>> </div><div><br></div><div>So your book describes the expected behavior.</div><div><br></div><div>And thanks for that back story. I struggle with the issue of technical</div><div>documentation at my day job; if you have code, comments and technical specs,</div><div>those are three version of the same state.  I would prefer to let the code be</div><div>the technical spec, but the systems I work with are pretty small.</div><div><br></div><div>></div><div>> Now to the point in question. If stare hard at the clause where the problem</div><div>> is it looks like this:</div><div>> </div><div>>     count_characters([H|T], #{ H := N }=X})</div><div>> </div><div>> Erlang semantics dictate that if a variable occurs more than once in a</div><div>> pattern then it must have the same value - so reading from left to right H</div><div>> has a value after matching the first argument in the function and so this</div><div>> value can be used as a key in the hash map lookup that is implies by the</div><div>> second argument.</div><div>> </div><div>> This should be similar to the behavior of pattern matching in binaries where</div><div>> you can "propagate forward" a length of a segment, which has been pattern</div><div>> matched earlier in the binary.</div><div>> </div><div>> For example:</div><div>> </div><div>>      <<Len:8, A:Len/binary, B/binary>> = <<2,1,2,3,4,5>></div><div>> </div><div>> matches with bindings Len = 2, A = <<1,2>> and B = <<3,4,5>> So Len is</div><div>> propagated forwards in the pattern match (in this case, and in the hashmap</div><div>> case we can't match all the arguments "in parallel" but have to do it in a</div><div>> specific order.</div><div>> </div><div>> To compile hashmap patterns like the one above that failed, is certainly</div><div>> possible.</div><div>> </div><div><br></div><div>Would you like me to file a bug reports for this case?</div><div><br></div><div>And let me take this opportunity to say I am _really_ enjoying learning Erlang.</div><div>I'm about one week in and I wanted to play hooky so I could keep tinkering.</div><div><br></div><div>Thanks,</div><div><br></div><div>Mark</div></div></div>