The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

pminten (16) [Avatar] Offline
Here are a few minor things in the current v7 MEAP that aren't worth opening separate threads about.

p81, The capturing syntax is actually `&<expr>`, not `&(<expr>smilie`. The parentheses are not needed except to make the capturing operator bind to the right expression. For example `&(&1 + &2)` but `&[&1|&2]`, `&{&1,&2}`, `&%{foo: &1}`, `&foo.(&1)`. Superfluous parentheses appear in many places (just search for `&(`).

p239, You use called_pid as the same parameter of handle_call, however it gets, as you correctly described earlier, a tuple of a pid and a tag. It may be somewhat clearer to call this called_from or something.

p245, Is there a particular reason you use HashDict.fetch instead of using the more general Dict.fetch?

p325, "Whenever a single process must serve many clients, those clients effectively become synchronized while accessing that single process." Not quite sure, but is the terminology synchronized correct? Or do they become serialized?
sjuric (109) [Avatar] Offline
Re: Small things
1. Thanks. I'll see if it makes sense to reduce extra parens. I tend to use them personally, because I prefer to have this extra bit of noise instead of worrying about ambiguity. But yeah, some constructs such as &[], &{}, or &foo(...) don't need extra parens.

2. Yeah, good catch!

3. I used to use Dict functions earlier, but then I saw José mentioning somewhere (maybe ML) that we use concrete modules unless we aim to support whichever dict, so I changed to that. I also think it makes the code a bit easier to understand.

4. Good question. I was under impression that when some piece of code is synchronized in a concurrent system, it means that we have at most one instance of it running at any point in time. So yeah, thinking about it now, I guess requests become serialized, while the server code is synchronized (at most one instance at the time is running per distinct server). I think I'll have to reword this.