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

[chris hermansen]

Good afternoon everyone,

On Fri, Feb 20, 2026 at 12:42 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> > 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..
>
> I suppose!

I find it interesting that van Vliet is using this operator INTWIDTH (as
well as REALWIDTH, RREALWIDTH and EXPWIDTH) as a way to have the mode of
the operand select the mode of the result.  That is

INTWIDTH 10 will yield the constant int_width
INTWIDTH long 10 will yield the constant long_int_width

and so on.  So in van Vliet's (pseudo) code, he is using the united-mode
argument to these operators to encapsulate the case-conformity clause, but
alternatively he could have used operator overloading to make the
united-mode and case-conformity-clause vanish completely.

(which I like better, for what that's worth).

-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/algol68/attachments/20260220/4ffb478e/attachment.htm>