[erlang-questions] count_characters example from Programming Erlang

Mark Bucciarelli mkbucc@REDACTED
Sat Feb 6 00:26:14 CET 2016

On Fri, Feb 5, 2016 at 3:24 AM, Joe Armstrong <erlang@REDACTED> wrote:
> The idea was that by the time the book was published the book and
> implementation would be in phase with each other.
> There's a back story here:
> In the early days of Erlang the implementation and the documentation were
> always out of phase. This means there was a heck of a lot of code and very
> little documentation.
> When the documentation was written there was short time when it was in
> with the code but then the code changed and the documentation was not
> updated. The point is the two were never in phase, or at least if there
> in phase it was for a short time.
> At the time I used to say
>     "If the code and documentation different, read the code."
> But reading code is difficult - especially for a beginner.
> Anyway even if I can understand the code I don't know a) what it's
> to do and b) if it is buggy.
> When the code and documentation differ I don't know which is definitive.
> At a certain point in time I thought to myself - "this is stupid" so I
> changed strategy.
> I said -
>     "the documentation should describe that the system is supposed to do,
>     if the code and documentation differ it's a bug and the code is
> Then I wrote the documentation from the standpoint of what the system
> do rather than what it actually does, and I do this in my books.
> Most system documentation describe what the code does, and not what it
> do.
> In an ideal world the two should be the same - but this is only true in
> mature systems.

So your book describes the expected behavior.

And thanks for that back story. I struggle with the issue of technical
documentation at my day job; if you have code, comments and technical specs,
those are three version of the same state.  I would prefer to let the code
the technical spec, but the systems I work with are pretty small.

> Now to the point in question. If stare hard at the clause where the
> is it looks like this:
>     count_characters([H|T], #{ H := N }=X})
> Erlang semantics dictate that if a variable occurs more than once in a
> pattern then it must have the same value - so reading from left to right H
> has a value after matching the first argument in the function and so this
> value can be used as a key in the hash map lookup that is implies by the
> second argument.
> This should be similar to the behavior of pattern matching in binaries
> you can "propagate forward" a length of a segment, which has been pattern
> matched earlier in the binary.
> For example:
>      <<Len:8, A:Len/binary, B/binary>> = <<2,1,2,3,4,5>>
> matches with bindings Len = 2, A = <<1,2>> and B = <<3,4,5>> So Len is
> propagated forwards in the pattern match (in this case, and in the hashmap
> case we can't match all the arguments "in parallel" but have to do it in a
> specific order.
> To compile hashmap patterns like the one above that failed, is certainly
> possible.

Would you like me to file a bug reports for this case?

And let me take this opportunity to say I am _really_ enjoying learning
I'm about one week in and I wanted to play hooky so I could keep tinkering.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160205/d2313abb/attachment.htm>

More information about the erlang-questions mailing list