array-from-remz     \_   \@

To receive a referred array, from afar, there are the two, the \_ and the \@. The former is to receive from a remz, where the array-width is recorded at the foremost byte/int.

Here is an example array, with a width-informer byte, at the front.

\r #afrmz	\a+ 1
\r afrmz
    \'Ahmed Ferzen/Ferzan R Midyat-Zilan\r\n\0'
\* #afrmz\-f

Notice that,

• the "\a+ 1" is only to leave an empty byte. The width is written by \-f
• that width-informer, after #afrmz, is not (implicitly) needed by \@
• for \@ to neglect the width-informer, there is yet another remz, the afrmz
• the null-terminator '\0' is needed neither by \_ nor by \@
• the null-terminator is needed by \F@ and elsewhere

These next two, are with the equivalent output

\_ #afrmz

\@#afrmz afrmz  \\refer to the width, explicitly

full-replication

To replicate that array, in full, \_ is not enough. The \@ is needed, too.

\@1 #afrmz  \\replicate the width-informer byte
\_ #afrmz   \\replicate the rest

\_ vs. \@

This was only one of the cases, where \_ is relatively limited, as opposed to \@. Although \_ is really, mostly, the easier to employ in quicky programming, there are the intricacies to note, when a limit is approached, or probably exceeded. For example,

• if the array may ever exceed 255 bytes, the (dot'less) \_ is not employable
• therefore, the programmer ought to estimate the max-width
• if dot'full (width-toggle) \_. then the \-f. is dot'ful, too.
• The \F_ does not work with dot'full \_. Null-terminate that array, for a \F@
• always tell the width for a \@ - unless that is int, the default width.

where are these written to?

The form@fix active-remz is the recipient. After each byte, that Arz.remz is advanced a byte. e.g: If 18 bytes were copied, the array is now 18 bytes further - unless the border was hit, after where there is no range to go.

That border is implementation-defined by form@fix. e.g: In form@fix 0.1f, that upper-border is the lower-border of the remz-table. Nearer, after each remz, with a new name, is defined - the remz-table expanded.

is form@fix reflecting?

For a form@fix interpreter, no array is active. That is, form@fix does not reflect about what is in there. To activate, refer to the array of choice, as a frame, with \F_ or \F@. These frame their argument array, as a form@fix runnable.

what if the array is not there, yet?

If not to receive the array there, but to record the remz to the array, there is another facility, the forward/record-remz, \* to record that as a pointer. That is the needed, if the value is not there, yet, although next, when the built-file is run, that array is there - whether that file is a frame, run with an \F variety, or that is the built executable file.