<div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 16, 2015 at 1:02 AM,  <span dir="ltr"><<a href="mailto:lloyd@writersglen.com" target="_blank">lloyd@writersglen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2ic" class="a3s" style="overflow:hidden">1) I'm guessing repr is your abbreviation for replica and rel for relation. Is this correct?<br>
</div></blockquote><div><br></div><div> Dmitry is right on both accounts here. `repr` is a shorthand for representation, i.e., how to represent the data.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":2ic" class="a3s" style="overflow:hidden">3) Pardon my thick skull, but the book/0 declaration in the -opaque and -export_type attributes still puzzles me. Can I use book() in external modules? But without a parameter for a book instance, just exactly how would it be used?</div></blockquote></div><br></div><div class="gmail_extra">In languages with static types, you eventually have to make a choice for a type 'book'. If we export this type and use it in other modules, are these other modules allowed to the see the structure of a book and work with that structure or are they not? The former is called a transparent ascription and the latter is called an opaque ascription.<br><br></div><div class="gmail_extra">The reason you may want to use opaque ascriptions is that you can change the internal representation. Say you have defined <br><br></div><div class="gmail_extra">type 'a queue = 'a list<br></div><div class="gmail_extra">let empty = []<br></div><div class="gmail_extra">let push x q = List.append q [x]<br></div><div class="gmail_extra">let pop q =<br></div><div class="gmail_extra">    match q with<br></div><div class="gmail_extra">    | [] -> None<br></div><div class="gmail_extra">    | (x :: q) -> Some (x, q)<br><br></div><div class="gmail_extra">In something like OCaml. Now, if another module abuses the fact that a queue is a list, then you can't change the implementation later on. So you mark the queue as opaque which means any user of the queue *has* to use the functions empty/push/pop defined in the module. We can thus later change the internal representation to, say,<br><br></div><div class="gmail_extra">type 'a queue =<br>    { front : 'a list ;<br>      back : 'a list }<br><br></div><div class="gmail_extra">and change the functions accordingly, without breaking any other user of the module as we forced them into a mode where they cannot inspect the internal representation of the queue.<br><br></div><div class="gmail_extra">The -opaque annotation serves the same purpose in Erlang, and this is also, what Dmitry said :)<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>