[m-rev.] for post-commit review: reorder foreign code in io.m

[Zoltan Somogyi]

This changes only the order of declarations and definitions,
and their packaging inside foreign_decl and foreign_code items;
the code itself is not changed.

I intend to commit this as soon as the C# and Java bootchecks
are done (asm_fast is done already), and deal with any comments
post-commit.

The diff is with -b. The best way to look at it is to apply it,
and look at the affected parts of the file.

Also attached is the output of --show-definition-extents for io.m.
It is not complete because that foreign_procs show up as having
an extent consisting of just one line (since such goals have only
one context) and foreign_decls and foreign_code items are
completely invisible to it, but they do show roughly how big
each part of io.m is.

I next propose to carve the following submodules out of io.m:

- io.open_close to handle all the open and close operations

- io.read_primitives and io.write_primitives, or possibly
  io.primitives_{read,write}, to handle the reading and writing
  respectively of values of primitive types. The read submodule
  would also handle putback. For now, I don't propose to split
  these modules further into text vs binary parts; we can think
  about that once these modules are available to look at to help
  form an informed opinion about that.

  The way I propose to do this is split is to keep the main predicates
  in io.m, and put all the service predicates into the submodule.
  For example, consider write_int/3 and write_int/4. They would stay,
  but do_write_int8 would move, and so would also any foreign language
  function that the latter would need. (I am *hoping* that after the move,
  no foreign language function would end up being called from more than
  one module.) This would reduce the size of io.m with minimal disruption
  to the optimization of these predicates.

Later, I think we will want to carve out two other submodules
for reading and writing non-primitive entities, so the naming scheme
of the new submodules should accomodate them.

Opinions? Naming suggestions?

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.fc
Type: application/octet-stream
Size: 401 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220311/e1492c09/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.fc
Type: application/octet-stream
Size: 30709 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220311/e1492c09/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: io.defn_extents
Type: application/octet-stream
Size: 29145 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20220311/e1492c09/attachment-0005.obj>