Framing yet another form@fix level     \F

To frame an input array/file/function is to arrange that as a byte-stream, for form@fix to interpret that, right next.

framing a frame

\F [filename]   frame from a file.
    If no filename, the default is the stdin.

\F@ az   frame from az, a null-terminated array

\F_ #ar  frame from #ar, a width-informing array
\F_. #ar   the array-width is int (not only <= 255).

\F* fun  frame from fun, a function as the input

\F^ return to the first-byte of this frame.
   That is, as-if getting out of this frame,
   and re-framing, afresh.

buffering in

\F= filename Read from the file, verbatim.

That is, neither framing an input, nor writing-out. However, if the aim is to later frame that buffer, then \F= is the intermediate work - from a written, to a framing. After \F= any of \F@ \F_ or \F* may frame that array. For example,

0. For a faster form@fix program, buffer the most-often framed files, in memory.

1. To freeze a file, with snapshots at multiple time-points, the programmer may buffer (all of, or a piece/digest from) each, in memory.

2. To differentiate a file-not-found vs. a "\A- 0" from a frame. That is the load-time error, in contrast to an internal response from the frame. The existence of the \F= facility, is an enabler for a well-isolated load-phase.

buffering out

\F== [filename] write the range, to a file.
    If no filename, the default is the stdout.
\F=^ [filename] write the range, append to a file.
    If no filename, the default is the stdout.

If the file is not appended, that file is truncated-to-zero, at first. That guarantees finding an empty file, even if that file existed, previously.

There are implicit information, important in buffering-out,

• the extent/range to write-out, is what the facility \Ae is managing
• the platform-function @write (the third field) is invoked here. e.g: If the platform is an .exe for running on MSDOS, the exe-header is to reflect the file-length information. Each platform may expect some different format/protocol/interface for a written output-file.

The default @write function, when form@fix is starting afresh, does not modify anything. That is the implicit platform-0.

The default extent is zero-zero. The latter, when zero (NULL), is to mean that, the write-range is until where the active-remz is. The \a is easy.

When the platform-reference-point is not at zero-offset, the latter zero is not really a zero (NULL). For example, for an MSDOS .exe program, a "zero" would mean the offset 0x40, as there is a 64-byte .exe header at the start of that. Therefore, if to mean the "default," then leave the extent altogether.

\A extent0  \\the extent is left out, to mean NULL.

record vs. file

The append \F=^ is not really intended for record-management. Notice that, there is no offset-relative read/load facility. I intend the \F=^ for writing log-files, as is customary. At the end, that logfile is a single object - to list the event-history.

The form@fix i/o model is not restrictive. Even if the end-programmer, or the database-designer is wishing a large repository, with a record-in-table model, and with many table-varieties, the form@fix model is not the restrictive. That is probably quite easy, in most cases, to write a wrapper, a middle-layer, to interface. e.g: For MSDOS, a TSR to hook int21h for filtering-file-operations, a foreign-file system. For Windows, a shell-object to act as-if a folder, with files, although that is only software-defined. i.e: The form@fix frame in/out facilities would appear only as a record-by-record retrieval/recording, from the viewpoint of a table-minded designer.

quote, or not

Quoting a frame-name is optional. No-quotes, single-quotes, or double-quotes, all fit. The existence-vs.-not of spaces/quotes in that frame-name, would motivate a preference.

for example ...

For writing a buffer, to a file.

\'Heaveno, World!'
\F== heaveno.txt

\F== total.txt  \\write anew

If we do not want to write all of the written range, ...

\r z  \'R-world, a haven-for-heaven.'

\Ae z  \\the Arz-extent is from z, to here.
\F== haven.txt

\F=^ total.txt  \\append

how to isolate the frame-name, from the facility

form@fix frame-related facilities do not take the frame-name from any buffer. Whether quoted, or unquoted, the text after the facility is the literal frame-name. If the end-programmer is wishing a buffer-driven case, isolating the facility from the filename (the action/tool vs. the object), the answer is, again, framing. For example,

\r @FrameMacro
    \'\\F'
  \r! FramingVariety
    \'   '   \\the default is from file
  \r! FrameName
    \'reserved-buffer-area-for-a-frame-name   '
    \'\0'

\r frame{
  \'\\\'Heaveno, World!\''
\r }frame

\Ae frame{ }frame
\r! z   \a FramingVariety  \'=='  \a z
\r! z   \a FrameName  \'example.hta\0'  \a z
\F@ @FrameMacro

That is not really different from Pascal, or C, where we modify the text in a reserved-buffer (e.g: reserved with malloc), or from specifying the fopen() options as a text-buffer, in C, e.g: "wt+"

from history

In the 2003 release of form@fix, there were the two. The \i and \F. The \i was "include," as termed after the C programming language. The \F was "FIX," although not defined, yet. A reader may readily reflect that the former is the latter, as form@fix does interpret that "include." Well, I reflected that, myself. Therefore, there is nothing lost, when the "\i" is deleted-out, and "\F" received the fitting function-and-name.

As the \F was not defined, yet, I had referred to a few research ideas of mine, in the reference page of the 2003 \F. A reader may wonder whether those are lost. Those listed - the persocode-list - go with aFiRMz. i.e: I plan to research them as two different cases. Instead of evolve the 2003-FIX into aFiRMZ, now there are two - the form@fix, and aFiRMz. I do not know now, whether in time, they may resemble each other more and more, or instead, walk altogether different distances.