<html><body><span style="font-family:Verdana; color:#000; font-size:10pt;"><div>> Then I wrote the documentation from the standpoint of what the system<br>
> should do rather than what it actually does, and I do this in my<br>
> books.<br>
</div><div>Sounds like Behavior Driven Development (<a href="http://dannorth.net/introducing-bdd">http://dannorth.net/introducing-bdd</a>/)<br></div><div>:-)</div><div><br></div><div>Are there any erlang BDD tools? ie converting english sentences into CT test cases? </div><div><br></div><div>Note I agree with James Bach (<a href="http://www.satisfice.com/blog/archives/638">http://www.satisfice.com/blog/archives/638</a>) that humans are needed also but erlang tools for english-like to test case would be awesome. And I think erlang would 'need less humans' than other languages because the 'let it crash' philosophy makes Bach's 'all possible states' more tractable. <br></div><div><br></div><div>Duncan Sparrell</div><div>s-Fractal Consulting LLC</div><div><br><br></div>
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; font-family:verdana;">
<div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: Re: [erlang-questions] count_characters example from<br>
Programming Erlang<br>
From: Joe Armstrong <<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>><br>
Date: Fri, February 05, 2016 3:24 am<br>
To: zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>><br>
Cc: Erlang <<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>><br>
<br>
On Fri, Feb 5, 2016 at 5:58 AM, zxq9 <<a href="mailto:zxq9@zxq9.com">zxq9@zxq9.com</a>> wrote:<br>
...<br></div><div><br>
The idea was that by the time the book was published the<br>
book and implementation would be in phase with each other.<br>
<br>
There's a back story here:<br>
<br>
In the early days of Erlang the implementation and the documentation<br>
were always out of phase. This means there was a heck of a lot of code<br>
and very little documentation.<br>
<br>
When the documentation was written there was short time when it was in<br>
phase with the code but then the code changed and the documentation<br>
was not updated. The point is the two were never in phase, or at least<br>
if there were in phase it was for a short time.<br>
<br>
At the time I used to say<br>
<br>
"If the code and documentation different, read the code."<br>
<br>
But reading code is difficult - especially for a beginner.<br>
<br>
Anyway even if I can understand the code I don't know a) what it's<br>
supposed to do and b) if it is buggy.<br>
<br>
When the code and documentation differ I don't know which is definitive.<br>
<br>
At a certain point in time I thought to myself - "this is stupid" so I<br>
changed strategy.<br>
<br>
I said -<br>
<br>
"the documentation should describe that the system is<br>
supposed to do, and if the code and documentation differ it's a bug<br>
and the code is wrong."<br>
<br>
Then I wrote the documentation from the standpoint of what the system<br>
should do rather than what it actually does, and I do this in my<br>
books.<br>
<br>
Most system documentation describe what the code does, and not what it<br>
should do.<br>
<br>
In an ideal world the two should be the same - but this is only true<br>
in very mature systems.<br>
<br>
Now to the point in question. If stare hard at the clause where the problem is<br>
it looks like this:<br>
<br>
count_characters([H|T], #{ H := N }=X})<br>
<br>
Erlang semantics dictate that if a variable occurs more than once in a<br>
pattern then it must have the same value - so reading from left to<br>
right H has a value after matching the first argument in the function<br>
and so this value can be used as a key in the hash map lookup that is<br>
implies by the second argument.<br>
<br>
This should be similar to the behavior of pattern matching in binaries<br>
where you can "propagate forward" a length of a segment, which has been<br>
pattern matched earlier in the binary.<br>
<br>
For example:<br>
<br>
<<Len:8, A:Len/binary, B/binary>> = <<2,1,2,3,4,5>><br>
<br>
matches with bindings Len = 2, A = <<1,2>> and B = <<3,4,5>><br>
So Len is propagated forwards in the pattern match (in this case, and in the<br>
hashmap case we can't match all the arguments "in parallel" but have to do<br>
it in a specific order.<br>
<br>
To compile hashmap patterns like the one above that failed, is<br>
certainly possible.<br>
<br>
/Joe<br>
<br>
<br>
<br>
<br>
<br>
<br>
><br>
> -Craig<br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div>
</blockquote></span></body></html>