[erlang-questions] count_characters example from Programming Erlang

[Joe Armstrong]

On Sat, Feb 6, 2016 at 12:26 AM, Mark Bucciarelli <mkbucc@REDACTED> wrote:
> 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.

What I want it to be - it's vision of the future - not a description
of the current state of art.

>
> 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.

This was the same in the early days of Erlang - I think this is always the
case in a programmer lead project - sooner or later the change must occure
after a few months or years

>
>>
>> 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?
>

Yes :-)


> 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.
>

Glad you're enjoying it


/Joe

> Thanks,
>
> Mark
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>