form@fix programming-guide
Heaveno World!

The form@fix platform, is an inter-platform programming tool, for byte-crafting.

form@fix'ing the first page

We start experimenting with form@fix, by studying and modifying our first example, that was on the form@fix, the first page, for writing on the monitor of your computer, the text "Heaveno, World!" Let's first understand that code, in this section.

The code is the following:

\\0. \F "fixDef.htm"
\\1. \F "fixDC.htm"
\\2. \F "fixLib.htm"
\\3. \r! write.azText=  \'Heaveno, World!\r\n\0'

\\4. Start running here        \F@ fixStArt
\\5.    Write out the text        \F@ az.write
\\6.    Exit the application      \_ ExitApp
\\7. Record the binary         \F== 'heaveno.com'


\\8. Exit the form@fix session \A--

for an immediate act

For form@fix to interpret this example, gather these together, in a folder

1. fix.exe (the form@fix interpreter)
2. fixDef.htm
3. fixDC.htm
4. fixLib.htm
5. fix.htm (the first page) or fix_prog.htm (this page)

Next, either run "fix fix.htm" or "fix fix_prog.htm" Or first, run fix.exe, and next, interactively, frame either of these, as with \F fix.htm or \F fix_prog.htm

After these, find that, heaveno.com is (produced) in that folder, too.

decoding the code, row-by-row

A form@fix row, is a facilities-list. Each of them are activated, one-by-one, until (if there is) the first facility with a failure result. The end-of-the-row, is where there is a CRLF or CR or LF. Normally, as on this page, each visible line is terminated with a CRLF/CR/LF. However, there are other cases, where very long range of bytes, on several lines, may pass as a row, that is a single, lengthy, facilities-list. For example,

• if your text-editor is with line-wraps, showing a row as multiple-lines
• if the frame is built in memory, without \r\n (CRLF) in the array - as is often the case, with those framed by a \F@

forgetting a range, within a row

In this example, each line starts with a forget-this-range facility, i.e: commented-out. When two backslashes are adjacent, the bytes until the next backslash, get ignored. i.e: Not interpreted by form@fix. They are for a human, who would read them, or to reserve the place, as when turning a facility on/off while testing the program.

Row 0
a refresher, defining the root

The framing facility, \F is with a few varieties. The example on the row-0 is for framing a file. That is, for letting form@fix to immediately read and interpret that file.

fixDef.htm is for defining the default form@fix, the way I find easy to interact. That is the pre-requisite for most other ready/library pages that I publish for form@fix.

However, not really needed in this example, as the next row, framing the fixDC.htm, is implicitly framing fixDef.htm, too. No problem, any way. That only does reset, again. Here, in this example, the fine point is to inform the reader, that fixDef.htm is the first event.

Row 1
framing for a platform

The fixDC.htm is the platform-wrapper, for ease, when crafting an MSDOS ".com" format program. Alternatively, as another example, framing fixDX.htm would lead to the program getting recorded in the MSDOS ".exe" format.

Row 2
a function repository

Not to "invent" the wheel again and again, a well-received, extremely popular, idea is to form libraries of already-polished code. As an example, here is fixLib.htm, for writing-out-text, and exiting-program - as next referred, on this page.

Row 3
what to write

There are two facilities on the row-3. The first is to reset a remz (reference), here. That remz, is pointing at what is written next, with the read-quoted facility.

Text-output is a very usual operation in a software. That means, normally, we may invoke az.write() several times, probably with a modified-text, each time. Therefore, in this example I demonstrate the force-reset facility \r! Without that '!' the facility \r would fail-to-register the remz here, if that remz-name is/was already registered.

In this example, that remz was not already defined. Therefore, \r would function no different. However, no problem, in employing \r! either.

The read-quoted facility, in this example, is with three escape-codes, at the end. The '\r\n' is the CR-LF. The '\0' is a zero-byte, the null-terminator, at the end of the array.

Row 4
StArt running here

The framing facility on the fourth row, is different than the earlier three. Here, the frame is from memory - as fixDC.htm defined that. Each platform would manage that first-entry point differently. i.e: The frame/macro fixStArt is implemented variously.

The fixStArt is for the program (heaveno.com), to know where to start its execution.

Row 5
for a reader, at his/her monitor

Row-5 is the main action of this tiny program. The framed, is a function, expanded as a macro. If this were C, the macro header would read az_write(azText_4_write). i.e: The array write.azText is the arg-list to the frame/macro az.write(). Overall, that is resembling both the "with" statement of Pascal, as the argument is received implicitly, and also the C & assembly macros, as the arg is active in the framing/initialization of that frame/macro, determining the produced text, the result, conditionally.

Row 6
Providing An Exit for the Resulting Application

The ExitApp is a function, to exit (quit) the running application. In contrast to framing (with \F_), an \_ array-replicator facility is always to replicate exactly, byte-by-byte. That is fitting here, as far as ExitApp does not refer to any arg.

Row 7
Fixing It In Its Place

The coding of the application is finished, now. Let's fix it in its own .com file, as a stable version. We name it 'heaveno.com'. The user, then, may run it on a platform that can run MSDOS .com files.

Row 8
to terminate the form@fix interpreter

After we have finished these, if no other job to do, we may terminate the current session. That is what row-8 does, in this example.