[erlang-questions] count_characters example from Programming Erlang

[Mark Bucciarelli]

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
phase
> 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
were
> 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
supposed
> 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,
and
>     if the code and documentation differ it's a bug and the code is
wrong."
>
> Then I wrote the documentation from the standpoint of what the system
should
> 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
should
> do.
>
> In an ideal world the two should be the same - but this is only true in
very
> 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
be
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
problem
> 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
where
> 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
Erlang.
I'm about one week in and I wanted to play hooky so I could keep tinkering.

Thanks,

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