Some drastic changes for HLA v1.81

[Randall Hyde]

While in the process of cleaning up some nagging bugs that have been in HLA for a while, I've completely redone how the stdout, fileio, and str "put" macros operate. To begin with, I've cleaned up *several* bugs that have affected this macros for quite some time now. I've also added a few missing routines (str.put with 64-bit and 128-bit operands). Lastly, and this is the kicker, I've redone how the put macros are written to make it very easy for the average person to create their own "put" macros. BUT....  in order to do this I had to change the prototypes for all the str.catXXXX (except str.cat, itself) functions and place the destination operand first in the parameter list. If you use the str.catXXX routines (e.g., str.catbool), this will *break* your code and you will have to make modifications to your source to get it to recompile. Fortunately, if you use HLA's high-level procedure call mechanism, type checking will let you know if you need to change the code. However, if you call these routines the "old-fashioned" way, you're going to have to track down the calls to these routine and move the push for the destination operand. A prime example of how using the HLL-like procedure calls makes your code easier to maintain.

Note that people who've used str.put do *not* have to change their code. Only those who've called the str.put support routines (str.catXXX) directly need worry about this.  As usual, I suspect I'm one of the few people who've done this, so I don't expect too many people will be affected by this.  If you happen to be one of the few, I apologize, but the returns are worth it in the long run.
Cheers,
Randy Hyde

[V Coder]

Looking forward to it.

Good thing is I use str.cat countless times in my program, not str.put, and not str.catXXX.

[Sevag.K]

Since writing 'put' macros will become easier, it would be nice if the next release also contained a str.cat2 macro with the syntax as str.put: str.cat2 (dest, src1, src2, src3, ... );

[Randall Hyde]

Since writing 'put' macros will become easier, it would be nice if the next release also contained a str.cat2 macro with the syntax as str.put: str.cat2 (dest, src1, src2, src3, ... );

Is that not what str.put does?
str.put, indeed, was the whole reason things got changed around. I was tempted to do a second set of str.catXXX macros for use by str.put, but I decided that I didn't want to carry such baggage into HLA v2.0. Better to deal with the *few* people who call str.catXXX directly today.

BTW, the syntax for str.cat did *not* change.  Having the destination operand as the second operand is logically better for *all* the string routines (including the ones I changed). Because str.cat gets called frequently in programs, and is not used by str.catXXX, I left it alone. I added an str.catstr function (which is just str.cat with the operands reversed) in order to handle the needs of the str.put macro.
Cheers,
Randy Hyde

[Sevag.K]

Since writing 'put' macros will become easier, it would be nice if the next release also contained a str.cat2 macro with the syntax as str.put: str.cat2 (dest, src1, src2, src3, ... );

Is that not what str.put does?
str.put, indeed, was the whole reason things got changed around. I was tempted to do a second set of str.catXXX macros for use by str.put, but I decided that I didn't want to carry such baggage into HLA v2.0. Better to deal with the *few* people who call str.catXXX directly today.

No, str.put overwrites existing data in the destination.
I finde myself at times using a list of str.cat routines:

str.cat ( src1, dest);
str.cat (src2, dest);
str.cat ( ... , dest);

Which would better be served by a str.put like macro for concatination:

str.catTo ( dest, src1, src2, ...);

BTW, the syntax for str.cat did *not* change.  Having the destination operand as the second operand is logically better for *all* the string routines (including the ones I changed). Because str.cat gets called frequently in programs, and is not used by str.catXXX, I left it alone. I added an str.catstr function (which is just str.cat with the operands reversed) in order to handle the needs of the str.put macro.
Cheers,
Randy Hyde

I agree dest being second operand is better for routines that have only 2 operands.  This matches nicely with HLA's instruction format.  But for macros that perform multiple operations on a single destination, dest as 1st operand is the easiest way to go.

[Randall Hyde]

No, str.put overwrites existing data in the destination.
I finde myself at times using a list of str.cat routines:

str.cat ( src1, dest);
str.cat (src2, dest);
str.cat ( ... , dest);

Which would better be served by a str.put like macro for concatination:

str.catTo ( dest, src1, src2, ...);

Okay.
Let me share a little secret with you. str.put has been broken and has been doing exactly this all along. :-)
I fixed that for the 1.81 release, but, being way ahead of you, it occurred to me that it might be nice to have an actual concatenation function. So I also create str.put2, which does exactly that. This was possible because of the new hla.put and hla._put_ macros I created (well, it's not like it was impossible before, but it only took 12 lines of code to create the new str.put2 macro once I had those HLA.XXX macros in place).

I agree dest being second operand is better for routines that have only 2 operands.  This matches nicely with HLA's instruction format.  But for macros that perform multiple operations on a single destination, dest as 1st operand is the easiest way to go.

Yeah, I'm still wondering if I ought to change things back and use a *different* set of str.catXXX macros for the str.put/str.put2 macros. Then again, I suspect that few people have used the str.cat routines (and are not likely to use them in the future), so I don't know if it's worth having two sets of routines in the library.
Cheers,
Randy Hyde

[V Coder]

I should have been using str.put all along. Instead I have sequences of str.cat.

Too bad. Now I know.