Cleanup and convert to Markdown

eeps/eep-0004.md

@@ -1,14 +1,14 @@
-EEP: 4
-Title: New BIFs for bit-level binaries (bit strings)
-Version: $Revision$
-Last-Modified: $Date$
-Author: Per Gustafsson
-Status: Draft
-Type: Standards Track
-Content-Type: text/x-rst
-Created: 10-Aug-2007
-Erlang-Version: R12B-0
-Post-History: 
+    Author: Per Gustafsson <pergu(at)it(dot)uu(dot)se>
+    Status: Final/R12B-0 Proposal is implemented in OTP release R12B-0
+    Type: Standards Track
+    Created: 10-Aug-2007
+    Erlang-Version: R12B-0
+    Post-History: 
+****
+EEP 4: New BIFs for bit-level binaries (bit strings)
+----
+
+
 
 Abstract
 ========
@@ -125,3 +125,13 @@ bit-level binaries as we have for ordinary binaries without changing
 the semantics of the BIFs for binaries such as size/1,
 binary_to_list/1, list_to_binary/1 etc.. This means that all such BIFs
 will throw an exception if their arguments contains bit strings.
+
+
+
+[EmacsVar]: <> "Local Variables:"
+[EmacsVar]: <> "mode: indented-text"
+[EmacsVar]: <> "indent-tabs-mode: nil"
+[EmacsVar]: <> "sentence-end-double-space: t"
+[EmacsVar]: <> "fill-column: 70"
+[EmacsVar]: <> "coding: utf-8"
+[EmacsVar]: <> "End:"

eeps/eep-0005.md

@@ -1,33 +1,34 @@
-EEP 5: More Versatile Encapsulation with export_to
-====
-
-    Author: Per Gustafsson
+    Author: Per Gustafsson <pergu(at)it(dot)uu(dot)se>
     Status: Draft
     Type: Standards Track
-    Content-Type: text/x-markdown
     Created: 10-Aug-2007
     Erlang-Version: R12B-0
     Post-History: 
+****
+EEP 5: More Versatile Encapsulation with `export_to`
+----
+
 
-====
 
 Abstract
---------
+========
 
-This EEP describes a new directive called export_to which allows a
+This EEP describes a new directive called `export_to` which allows a
 module to specify exactly which other modules that can call a function
 defined in the module. This provides a very fine grained primitive for
 encapsulation. Allowing the programmer to control more directly how
 his code should be used.
 
 This is an idea originally proposed by Richard O'Keefe. 
 
+
+
 Specification
--------------
+=============
 
-This is the syntax for the export_to directive:
+This is the syntax for the `export_to` directive:
 
-``-export_to(m,[f/a])``
+    -export_to(m,[f/a])
 
 where `f` is the name of a function of arity `a` and `m` is a
 module. (Perhaps we should allow a list of modules)
@@ -40,8 +41,10 @@ In addition these functions should act as exported functions to the
 rest of the world i.e. calls to these functions should always be to
 the latest version of the function.
 
+
+
 Motivation
-----------
+==========
 
 The module in Erlang have several roles. It is the unit of compilation
 and code reloading. It is also the unit of encapsulation, because the
@@ -61,18 +64,20 @@ the module, but sometimes we want to have more control than this
 e.g. this function should only be called from other modules in this
 application, or this function should only be called from the shell.
 
-The export_to directive gives the programmer the possibility to
+The `export_to` directive gives the programmer the possibility to
 express such restrictions that the runtime system then enforces. It
-should be noted that the export_to directive is not meant to replace
+should be noted that the `export_to` directive is not meant to replace
 the export directive, but to be an alternative in the case when the
 programmer knows all possible collaborators.
 
+
+
 Rationale 
----------
+=========
 
-There are some choices in designing the export_to syntax for example
+There are some choices in designing the `export_to` syntax for example
 should m be allowed to be a list of modules or should we have an
-export_to list where each entry is a module, function/arity pair. One
+`export_to` list where each entry is a module, function/arity pair. One
 reason to use the suggested syntax is that it reads pretty easily as:
 
 export to module `m` this list of functions `[f/a]`
@@ -84,30 +89,42 @@ make it possible to apply the function or to make it possible to
 update the code of the function.
 
 Discussions about such changes is outside the scope of this EEP, we
-only note that the export_to directive makes a good building block for
+only note that the `export_to` directive makes a good building block for
 creating such extensions without having to change the Erlang runtime.
 
-  .. Other languages that have something like this? 
+
 
 Backwards Compatibility
------------------------
+=======================
 
-Adding an export_to directive should be totally backwards
+Adding an `export_to` directive should be totally backwards
 compatible. Since writing such a directive now causes a syntax error
 since it is not a legal attribute.
 
+
+
 Implementation
---------------
+==============
 
 This feature has not been implemented yet, but here are some goals
 that we think the implementation should fulfill:
 
-* Ordinary static calls to an export_to function should cost the same
-  as calls to other exported functions
+*   Ordinary static calls to an `export_to` function should cost the same
+    as calls to other exported functions
 
-* The performance of other calls should not be affected by the
-  introduction of export_to calls
+*   The performance of other calls should not be affected by the
+    introduction of `export_to` calls
 
 This can be archived by putting most of the machinery to handle this
 feature in to the loader and only use dynamic checks for dynamic
 calls.
+
+
+
+[EmacsVar]: <> "Local Variables:"
+[EmacsVar]: <> "mode: indented-text"
+[EmacsVar]: <> "indent-tabs-mode: nil"
+[EmacsVar]: <> "sentence-end-double-space: t"
+[EmacsVar]: <> "fill-column: 70"
+[EmacsVar]: <> "coding: utf-8"
+[EmacsVar]: <> "End:"

eeps/eep-0006.md

@@ -1,69 +1,88 @@
-EEP 6: New BIFs for tuple and binary sizes
-====
-
-    Author: Bjorn Gustavsson
-    Status: Draft
+    Author: Björn Gustavsson <bjorn(at)erlang(dot)org>
+    Status: Final/R12B-0 Proposal is implemented in OTP release R12B-0
     Type: Standards Track
-    Content-Type: text/x-markdown
     Created: 10-Aug-2007
     Erlang-Version: R12B-0
     Post-History: 
+****
+EEP 6: New BIFs for tuple and binary sizes
+----
+
 
-====
 
 Abstract
---------
+========
+
+This EEP describes the two new guards BIFs `tuple_size/1`  and `byte_size/1 `
+as a prefered alternative to the  `size/1 ` BIF.
+
 
-This EEP describes the two new guards BIFs ``tuple_size/1`` and ``byte_size/1``
-as a prefered alternative to the ``size/1`` BIF.
 
 Specifications
---------------
+==============
 
-``byte_size/1::bitstring() -> integer()``
+    byte_size/1::bitstring() -> integer()
 
 Returns the number of bytes needed to store the entire *bitstring*
-(see <http://github.com/KennethL/EEP/blob/master/eep-0004.md>). This BIF will return
-the same value as ``(bit_size(Bin)+7) div 8`` (that is, the number
-of bytes will be rounded up if number of bits is not evenly divisible by 8).
+(see [EEP 4][]). This BIF will return the same value as
+`(bit_size(Bin)+7) div 8` (that is, the number of bytes will be
+rounded up if number of bits is not evenly divisible by 8).
 This BIF is allowed in guards.
 
-``tuple_size/1::tuple() -> integer()``
+    tuple_size/1::tuple() -> integer()
 
 Returns the size of a tuple. This BIF will fail if passed anything
 that is not a tuple. This BIF is allowed in guards.
 
+
+
 Rationale
----------
+=========
 
-The ``size/1`` BIF accepts either a binary or a tuple, and returns
+The `size/1` BIF accepts either a binary or a tuple, and returns
 either the size of binary in bytes or the size of the tuple.
 
-Because ``size/1`` accepts two different types, it is difficult to
+Because `size/1` accepts two different types, it is difficult to
 optimize uses of it, both in the compiler and in the run-time system.
 Adding the two new BIF will faciliate optimization, and will also
 help Dialyzer.
 
-It could be argued that ``byte_size/1`` should only work for
+It could be argued that `byte_size/1` should only work for
 binaries (bitstrings whose size in bits is disivible by 8) to catch
 the bug that the code cannot handle general bitstrings and still does not
-use an ``is_binary/1`` guard test. In my opinion, if the programmer
-must round up the result from ``bit_size/1`` to a whole number of bytes,
+use an `is_binary/1` guard test. In my opinion, if the programmer
+must round up the result from `bit_size/1` to a whole number of bytes,
 he or she is more likely to get *that* wrong: The "obvious" expressions
-``bit_size(B) / 8 + 1`` or ``bit_size(B) div 8 + 1`` are both wrong,
-and the correct expression ``(bit_size(B)+7) div 8`` is not immediately
+`bit_size(B) / 8 + 1` or `bit_size(B) div 8 + 1` are both wrong,
+and the correct expression `(bit_size(B)+7) div 8` is not immediately
 obvious.
 
+
+
 Implementation
---------------
+==============
 
 The implementation is trivial.
 
+
+
 Backwards Compatibility
------------------------
+=======================
+
+Code containing local functions named `tuple_size/1` or `byte_size/1`
+need to be changed.
+
+The compiler will issue a warning that `size/1` is deprecated
+and will be removed in R14B for code that uses `size/1`.
+
+
 
-Code containing local functions named ``tuple_size/1`` or ``byte_size/1`` need
-to be changed.
+[EEP 4]: <eep-0004.md> "EEP 4"
 
-The compiler will issue a warning that ``size/1`` is deprecated and will be removed
-in R14B for code that uses ``size/1``.
+[EmacsVar]: <> "Local Variables:"
+[EmacsVar]: <> "mode: indented-text"
+[EmacsVar]: <> "indent-tabs-mode: nil"
+[EmacsVar]: <> "sentence-end-double-space: t"
+[EmacsVar]: <> "fill-column: 70"
+[EmacsVar]: <> "coding: utf-8"
+[EmacsVar]: <> "End:"