Hi,All!
This is a sample from test program.
#macro qwerty (_par_[]);
#print(_par_)
#endmacro;

#macro unpack_params (_p_): _i_, _str_;
#if (@elements(_p_) > 0)
?_i_: dword := 0;
?_str_: string := "";
#while (_i_ < @elements(_p_))
?_str_ := _str_ + _p_[_i_] + ",";
?_i_ := _i_ + 1;
#endwhile
?_str_ := @substr(_str_,0,@length(_str_) - 1);
_str_
#endif
#endmacro;

#macro test_unpack (_params_[]): _str_;
qwerty(@eval(unpack_params(_params_)))
?_str_: string := unpack_params(_params_);
qwerty(@text(_str_))
#endmacro;

begin testprg;
test_unpack(1,2,3);
end testprg;

And this is result from compilation:
["_params_1,2,3"]
["1", "2", "3"]

Why there is difference? On my opninon the results must be the same.
Also qwerty(@eval(_params_)) produces Access Violation in hlaparse.exe.
I undestand that it's not a legal code, but in that case i think must be an error message and not access violation.
Posted on 2004-05-20 06:55:08 by Elohim Meth
They should be the same, and certainly shouldn't produce "_params_1". This is probably a memory deallocation error (dangling pointer problem) and is probably the same reason the code seg faults when just use @eval.

I'll look into this at some point.

BTW, here's a slight modification you might be interested in:


#macro test_unpack (_params_[]): _str_;
qwerty(@eval(unpack_params(_params_)))
?_str_: text := unpack_params(_params_);
qwerty(_str_)
#endmacro;


Another useful feature in HLA might be to allow "@text( stringArray )" that concatenates all the strings in the array (doing, essentially, what unpack_params is doing). I'll have to think about that.
cheers,
Randy Hyde
Posted on 2004-05-20 18:54:41 by rhyde
Thanks for reply,Randall!
I also wanted to ask:
Why if macro returns text instead of string
#macro unpack_params (_p_): _i_, _str_;
#if (@elements(_p_) > 0)
?_i_: dword := 0;
?_str_: string := "";
#while (_i_ < @elements(_p_))
?_str_ := _str_ + _p_[_i_] + ",";
?_i_ := _i_ + 1;
#endwhile
?_str_ := @substr(_str_,0,@length(_str_) - 1);
//_str_
@text(_str_)
#endif
#endmacro;
then @eval generates error?
Posted on 2004-05-21 04:31:27 by Elohim Meth
Consider the following example:


program t;

#macro qwerty (_par_[]);
#print(_par_)
#endmacro;

#macro unpack_params (_p_): _i_, _str_;
#if (@elements(_p_) > 0)
?_i_: dword := 0;
?_str_: string := "";
#while (_i_ < @elements(_p_))
?_str_ := _str_ + _p_[_i_] + ",";
?_i_ := _i_ + 1;
#endwhile
?_str_ := @substr(_str_,0,@length(_str_) - 1);
@text(_str_)
#endif
#endmacro;

#macro test_unpack (_params_[]): _str_;
qwerty(@eval(unpack_params(_params_)))
#endmacro;

begin t;
test_unpack(1,2,3);
end t;


The qwerty invocation in test_unpack expands to the following:


qwerty( @eval(1,2,3))

and @eval doesn't know what to do with this argument list. @eval is used to expand a *single* parameter, not three, which is what unpack_params expands into. All @eval is really doing is taking an identifier (macro or text) and expanding it prior to passing it as a parameter. As such, it only accepts a single argument. This is where the error occurs.

Now, as to why "qwerty(@eval(unpack_params(_params_)))" displays a bizarre string, that's simply a bug in HLA.

I must also admit that @eval is a weak point in HLA v1.x's design. Also, the limitation of not allowing text arrays has been no end of trouble (alas, I figured out how to do text arrays in flex/bison long after the release of HLA v1.x, but it was too much trouble to fix it at that point). Text substitution is one of the *big* areas that will change in HLA v2.0. Macros will be handled better (so you don't need to follow the crazy convention of "_name_" in locals to stay out of trouble), text equates will be handled better, and I'll come up with a better way of doing lazy evaluation vs eager evaluation. In the meantime, I'll try and find the problem with the @eval operator in this example (again, it *really* looks like a memory allocation/deallocation problem).
Cheers,
Randy Hyde
Posted on 2004-05-21 10:24:16 by rhyde