an observation about united modes

[chris hermansen]

Jose, thank you for your careful responses to my not carefully-enough posed
points.

My point wasn't to do away with unions, it was questioning the need for
mode declarations of united modes.  I was hypothesizing that the main use
for mode foo = union (...) is to use foo as a procedure parameter
declaration.

A few further observations following yours below.

On Wed, Jun 25, 2025 at 12:41 PM Jose E. Marchesi <jemarch@gnu.org> wrote:

>
> Hello Chris.
>
> > The other day I was looking at a test routine in the GNU Algol 68
> > validation suite that declared its parameter list as a united mode.  That
> > is, there was not a prior declaration of
> >
> > mode foo = union (...)
> >
> > but rather the parameter was declared to be of mode union (...)
> >
> > I don't believe I have ever seen this before, and it struck me as
> unusual.
> > And, the more I think about it, the more I wonder if united modes truly
> > exist for any reason beyond facilitating parameter declarations.
>
> To me, the unions in the orthogonal frame of Algol 68 are one of the
> best things the language offers.  Because of orthogonality and
> structural equivalence, you can dispel with the creation of superfluous
> mode names like that "foo" above.
>

That is the essence of my point - do we really end up needing the mode
declarations themselves?

I guess maybe there is another way to look at it - declare the mode if
you're going to use it in more than one place, otherwise just use the union
(...) in its place.


>
> > The other thing that got me thinking about this is why do we allow
> operator
> > overloading but not procedure overloading?  Is at least part of the
> reason
> > because united mode parameters in procedures take the place of procedure
> > overloading?
>
> I don't think so.  AFAIK it was McCarthy who pushed for having
> overloadable operators, and they fit very well in the schema of
> coercions.
>
I seem to recall conversations in the late 1970s where someone was always
lamenting the difficulty of dealing with operator overloading and how it
should have been omitted...

Whereas I would be in favour of adding procedure overloading (in principle,
anyway)!

I guess I'm wondering if there is general equivalence between
non-overloaded operators in the presence of united modes and supporting
conformity-clauses and overloaded operators where in essence the different
cases of the conformity-clauses from the former show up in the various
operator definitions.

I don't know if that's clear!  But as a simple example, if we had

op foo = (int i, j) int: ...
op foo = (int i, real j) real: ...
op foo = (real i, int j) real: ...
op foo = (real i, real j) real: ...

vs

op foo = (union (int, real) i, j) union (int, real):
case i in
(int ii): case j in
          (int ij): ...
          (real rj): ...
etc

I guess the return type of union (int, real) could be problematic, so maybe
that throws cold water on my idea.


> > I hope this observation / question doesn't seem overly sophomoric and
> > pointless.  I have long (let's say, since 1976 or so, when I first
> started
> > seriously using Algol 68) why it's "ok" to overload operators but "not
> ok"
> > to overload procedures.  Maybe I just missed the justification for this
> in
> > the RR or in the writings of AVW or Lindsey or another Algol 68 luminary.
>
> Perhaps it is related to the fact an actual parameter must always be a
> strong context (also in identity declarations) whereas the operands of
> an operator are in a firm context.  But maybe that is a consequence,
> rather than a cause...
>

Interesting, I had not noticed that.  I wonder why that is?


>
> > In any case, in the last few days I have found myself thinking that if I
> > had procedure overloading I would not need united modes.  Is that a
> foolish
> > thought?
>
>
> I use unions very extensively in my Algol 68 code.  For example,
> consider the following, which is code of a project I have not yet
> published:
>
>   { A "symbol" is the most fundamental component of a word.  The main
>     property of a symbol is that it is different to any other symbol and
>     only equal to itself.  We also characterize them by a name and a
>     description string.  A "word" is a sequence of symbols.  A word may be
>     empty and contain no symbols.  }
>
>   mode Word = union (void,Symbol,Symbols),
>        Symbols = struct (ref Word word, Symbol symbol),
>        Symbol = struct (string name, doc);
>
> Can you think of a more compact and clear representation of the same
> data structure?  I learned this style while reading code from Steven
> Pemberton.
>

Absolutely in agreement with your points above.  And I would say your Word
union looks like it might have a greater applicability than shorthand for a
procedure parameter list.


>
> I also find unions useful in order to return errors from procedures that
> return a value in some domain in case of success, without having to
> resort to the typical clumsy "out" argument:
>
>   proc string_to_int = (string str) union (int,void): ...;
>
> The procedure above returns the integral value encoded in STR, or
> "empty" if the string doesn't denote an integer that can be stored in an
> "int".  You would call it with something like:
>
>   int num = (string_to_int (str) | (int i): i | puts ("error"); skip)
>
> or equivalent:
>
>   int num = case string_to_int (str)
>             in (int i): i
>             out puts ("error"); skip
>             esac;
>
> > Thanks in advance for any comments / illumination on the topic.
>

I see your point there, an interesting one.  Of course one can consider
following the Go approach of returning a structure with an error code as
well as the result, rather than just a result (has to be a structure, I
think, because as a general mechanism returning union (something, int)
wouldn't work if mode something was int in the first place.

Thanks for your enlightenment!


-- 
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/20250625/53b44dc9/attachment.htm>