A request for opinion on proc read xlx integer in van Vliet

[Jose E. Marchesi]

> Thanks for the opinion, Jose.  A few other "excavations" below...
>
> On Fri, Feb 20, 2026 at 2:34 AM Jose E. Marchesi <jemarch@gnu.org> wrote:
>
>>
>>
>> > Hello again;
>> >
>> > This appears in van Vliet's transput:
>> >
>> >           #<#{PROC read xlx integer = ({REF #L# {INT i) {BOOL:
>
>
> [snip]
>
>>
>> > This will expand to
>> >
>> > proc read_short_short_integer(ref short short int i) bool: ...
>> > proc read_short_integer(ref short int i) bool: ...
>> > proc read_integer(ref int i) bool: ...
>> > proc read_long_integer(ref long int i) bool: ...
>> > proc read_long_long_integer(ref long long int i) bool: ...
>> >
>> > This "proc" is immediately followed by
>> >
>> >           {PROC read l real = ({UNION(#<#{REF #L# {REAL#>#) r) {BOOL:
>> >             # similar to 'read xlx integer', for real numbers #
>> >
>> > I'm not going to copy/paste the rest of it.  Note that it chooses to
>> take a
>> > union of the various lengths of reals rather than creating
>> >
>> > proc read_real(ref real r) bool:...
>> > proc read_long_real(ref long real r) bool: ...
>> > proc read_long_long_real(ref long long real r) bool: ...
>> >
>> > I find this kind of awkward.  He only references read_xlx_integer once,
>> in
>> > the body of read_l_real.  But even so.
>> >
>> > I would appreciate any opinions offered!
>>
>> I don't know why van Vliet decided to use an union in this case, rather
>> than expansion.  I think we should prefer expansion for efficiency
>> reasons: balancing is done at compile-time.
>>
>
> I've found some similar puzzles.  For instance, van Vliet uses
>
>  {OP #?# {INTWIDTH = ({UNION(#<##L# {INT#>#) x) {INT:
>   {CASE x {IN #<#(#L# {INT): xlx int width#># {ESAC;
>
> I would greatly prefer to use operator overloading for this type of thing,
> for example:
>
>  #<#{OP #?# {INTWIDTH = (#L# {INT x) {INT:
>   xlx int width#>#;
>
> and I'm assuming Jose's comment about preferring expansion for efficiency
> applies here as well.

Well in this case this operator is to be used internally right... it may
be that it is not that critical performance wise..