We have a "display" directive... why not an "input" directive?

The "input" directive would be useful for a couple things- fixing errors that are not very serious, and only need a "patch" which would be entered at assemble time, and patching into a binary file. Take as an example a binary file that has some ASCII text in it. We can use the "file" directive to include that in our
output file. But say we want to modify the ASCII text that is in the binary file?
Well, this is possible too, with "store" (am I correct?), but if we want to be
able to define that at assemble time, then we could use my "input" directive
for that.

Also, we should have a "halt" directive- so that you could halt assembling if a serious error (which would be detected using preprocessing directives and etc.) occurs. For example, a bootloader.
Say we're writing a bootloader, and of course it must be 512 bytes or less.
We could put a label "endloader" at the very end of the sourcecode, and then
using "IF" or other directives, check if "endloader" is greater than 512- and if so, display an error message and "halt" assembling. Without this, if we
are stupid enough not to look at the thing that tells how many bytes the program is, we might not realize that it is too big.

These could be very useful, I don't know how you think about them Privalov. I think you may think better of "halt" than of "input," since input can
be used to modify the source at assemble-time, whereas "halt" only stops
the process. Please respond, tell me if its possible, maybe even include it in future versions of FASM, or tell me how so I can put it in my own FASM.

Sounds like a completely new approach in coding. I prefer making changes in my code after a failed compilation, not during it. But the problem is that this would require lots of complicated communication between the preprocessor and other flat assembler parts, which would require restructuring everything, because later parts will have to go back at preprocessor stage after asking the user about the error and so on. I think this task would need more effort than it would use us.

Yeah, I guess so. But what good is "store" if you can only use it at coding time? But I guess it's probably too hard. Maybe not the input one, but the halt one should exist so we can halt if we detect an error, don't you think?

Maybe there should be a list of most-wanted features/language modifications. I think multiline comments would be pretty high on my list... and of course, to have a finished internals guide would be nice, though that's not part of FASM itself. It would be interesting if we could modify misspelled directives or instructions from FASM and then tell FASM to continue assembling.

That way, if we get the "bad instruction: mob ax,10" or something similar, FASM would allow us to enter the correct thing. Of course, for "extra characters on line" we could insert a RETURN, and so forth. I don't know how easy this would be to do, and maybe it would actually encourage or even cause bad coding or accidental mistakes that could cause the program that is being assembled to have errors/bugs. But if it were only for those types of errors, it might be effective and even useful.

I hope I'm not making suggestions that are unrealistic, and I hope I'm not insulting the maker of FASM, because FASM rulez! Don't get me wrong, it's just a couple features it would be nice to see...