CSC302 2011S, Class 17: Erlang (3)

Overview:
* Left-over issues.
* Synchronous and asynchronous messaging.
* Lab.

Admin:
* It's cold so ... Cocoa, Coffee, Cookies
* Are there questions on Assignment 6?
* EC: This week's CS extra on FPGAs.
* EC: Friday's CS table: GPUs, continued.

HW 6 Questions?

Question for you, using list comprehensions

Generate: [1,2,2,3,3,3,4,4,4,4,5,5,5,5,5]

[ X || X <- [1,2,2,3,3,3,4,4,4,4,5,5,5,5,5] ].

* How do we approach this problem?
  * Google/Bing it
  * Look for helpful functions, such as make-list
    lists:seq(L:U). creates [L,L+1,L+2,....U-1,U]
  * Ask someone else
  * Find a similar problem with a solution
  * Try a similar problem that might be more natural
  * Stare
  * Break the problem into parts
* Break it into parts
  * First, build the list from 1 to 5.  (Or 1 to N, for general case)
[ X || X <- lists:seq(1,5) ].
  * And then
    * Repeat each number 5 times
    * Filter out the extras.
    * May be inefficient
  * And then
    * Use foreach
    * Doesn't restrict ourselves to list comprehensions
  * And then lists:duplicate
    * Giving us
lists:flatten([lists:duplicate(X,X) || X <- lists:seq(1,5)]).

What about the related problem of [1,1,2,1,2,3,1,2,3,4,1,2,3,4,5]
* Could use appending of lists
  * But that's beyond list comprehensions
lists:flatten([lists:seq(1,X) || X <- lists:seq(1,5)]).

6> [X || X <- lists:seq(1,5), Y <- lists:seq(1,X)].
[1,2,2,3,3,3,4,4,4,4,5,5,5,5,5]
7> [Y || X <- lists:seq(1,5), Y <- lists:seq(1,X)].
[1,1,2,1,2,3,1,2,3,4,1,2,3,4,5]

---

Synchonicity

* Asynchronous message passing
  * One process sends a message to another, and does not wait for
    an acknowledgement (USPS, UDP)
* Synchronous message passing
  * Process sends a message and waits for a reply.

What's Erlang's primary message-passing mechanism?
* Asynchronous?
* The response mechanism seems more like mailboxes.
* foo ! bar has no return value, so you're not waiting for one.

Why would you choose asynchronous?  
* Seems more parallel - Things can work at the same time, rather than
  waiting for responses
* Easier to implement; no need to try to deal with acknowledgements and
  loss thereof.
  (There's a reason TCP is built on top of a UDP-like thing.)
* In many case, the only thing to return is an acknowledgement.
  * Useful for robustness, but not much else.
* You can build something like synchronicity on top of an asynchronous
  system.

Why would you choose synchronous?
* No acknowledgement in asynchronous.  Messages can get lost.
* You can build something like asynchronicity on top of a syncrhonous
  system.