Ready.
This page is for a list of old wishes. I had listed these, for vote. This page is the status report, now that these are not listed for vote, any more. The reason is either that, I implemented them already, or rejected.
I preserve the 2003 way of Arz, instead of implement "floating-frames."
A type is optional, for a remz, in general. The default type is void.
A form is a GFS form, with the four-functions. Must keep compatible with GFS. i.e: Pluggable into GFS, and vice versa. I had written GFS in C. Now, I only transferred/translated the form of GFS, from C, to form@fix - without any modification, except for the minor case of pointer segment-offset management.
The new facility-names are bilingual, and all fit me, AFRM-Z, the Istanbuli.
The facilities are listed in the form@fix reference manual.
Here is a table, for what is different in form@fix, after 2003. I do not
list every feature, here. I list only where older crafted-code need get
transformed.
| 2003 zFIX | 2005 form@fix 0.1F |
|---|---|
| \' | The 2005 \' is mostly fitting-2003. I dumped-away the not-needed options, as they rarely, if at all, find an application within those quotes, and even then, the other facilities would readily provide that function, very easily. i.e: Why replicate the capabilities of the facilities? Let me avoid. |
| \* | The 2005 \* is fitting-2003. No obsolescence. |
| \: | == \r remz (reference). Renamed and extended with (optional) typecasting |
| \@ | The 2005 \* is fitting-2003. No obsolescence. |
| \\ | The 2005 \\ is fitting-2003. No change. |
| \_ | The 2005 \* is fitting-2003. No obsolescence - unless if your code was with no spaces after the underline. i.e: First find-and-replace every \_ (2 letters) with a \_ followed by a blank (3 letters). That is trivial to do. |
| 2003 zFIX | 2005 form@fix 0.1F |
|---|---|
| \c | In house, I was only referring to this facility, only as a debug-breakpointer. Next, when I published code, I employed \c to program/set values, at fix'ing time. The function of \c was mainly to ignite a pointer, to run that address as a function. Very trivial to code, yet potentially very troublesome to try to use. Now that, I have already imported the original form as \f from GFS, I have the more versatile way. The \c is totally superseded by form, by far. |
| \e | \e was a zebra. Fine. However, not needed. The \@ and \* are
a versatile-team, for what \e really was for - and more. e.g: \*= 0x10 for \e 0x10 e.g: \@1 val for \e val |
| \E | \E was similar to \e except with preserved position, after the writing. No need for a full-facility, if only for that. The \a with \r do that. I rarely employed \E, and especially the limitation was there, when \E referred only to values, not to references. Now, the four-marvel team, \@ \* \a \r are the most flexible force for what is needed - and quite easy, too. |
| \F \i | To FIX a file, or to include a file, from within form@fix, is to \Frame yet another level of form@fix |
| \f \j | The fill "vs." jump, were similar. The \arrive replaced them, without loss. |
| \q | To quit, an \A-- is enough |
| \w | To write, is to \F== |
| Telling the array-width on-the-fly. The "\@width array0" does that, to copy from array0. e.g: For letting any label act as a macro. This way, multiple overlapping macros may exist within a range of bytes. The offset- and width-information, for each, is known by the end-programmer himself/herself. There are the resembling, too. The \F@ and \F* do not need a prefix byte. The \F* is to receive the input from a function. When the function is invoked, that function may find the range/extent-info from wherever it would. i.e: form@fix does not expect the array itself to contain the array-width information. |
| for output, write-out only a range of bytes - not until the
upper-limit The \F== does write, only from within the range/extent. |
| \F@ \F_ \F* are for framing an array - not from a file. To copy the referred array with \_ or to frame that with \F_ are two different functionalities, with that array. The latter, I had referred as the "active-inlining," when I proposed that. That is only a framing, though. No difference. |
In 2003, I had proposed-for-vote the next listed. I postpone, yet, or dump away, totally.
| No need for an extended-line operator, the \ The \F@ \F_ and \F* are good enough for having a long list of facilities together - if no \n or \r. That is, only let the intermediate "lines" not get terminated with some \n or \r in them. i.e: To avoid the explicit line-terminator is enough for form@fix to interpret that as a single-line. Although the \ would have its own flexibilities, I do not think I need that - at least, not yet. |
| No need for a function-interface, to invoke the form@fix facilities If I were to implement that interface, the functions would interact with/into form@fix, directly. However, that is already easy with only the facilities themselves. For example, within a \F@ the facilities and invoked-functions may co-operate. Even in the first-page example, in 2003, the function TextOut was receiving the pointer-to-text. With that, any-reference is there. The arg-list to a \F@ (as the macro-block) may feature whatever form/function/remz/value is known to form@fix. The only thing left is the rare extra-function-implementing facilities, as in the case of \arrive. I may think, whether I wish a function interface, to make them publicly-referrable. |
A facility-list is terminated with the first failed facility. For a full programming-model around this (cf. Prolog?), next, I may polish the fail-semantics for each facility. This is a well-known interface-related problem. i.e: Let each implement the common-denominator, to resemble each other, or otherwise, let each facility fit the fail-semantics to the expected facility-function. For example,
The exclamation-mark is not probably common - e.g: the meaning of '!' is different for the \r! vs. \a!= The former is an override (related to a fail, only about a repeated-name, not for lack-of-space, etc.) whereas the latter is to reverse the search-condition (not related to a fail-semantics, at all).
A question-mark is employable as dont-care, or anti-failing, value-query, for each operator. What matters, for each operator, is the meaningful fit.
"\@0 remz0" is enough to verify the existence of remz0. As the width is 0, nothing is written at Arz.
"\F= frame0" is enough to verify the existence of a file. That is good, to tell whether a \F failed as a result of "file not found" or an explicit fail-return, "\A- 0"