[RFC] Symbol mangling schema

[Jose E. Marchesi]

> On Sun, Nov 09, 2025 at 10:01:32PM +0100, Jose E. Marchesi wrote:
>> 
>> > I propose to have `ga68_' or `GA68_' prefix for all module symbols.
>> > Also I'd suggest to have a compiler option to overwrite this, so if a user
>> > want an empty string, be able achieve it with ease.
>> >
>> > The good thing about this is that, if in future, we want to change the mangling
>> > scheme, we can easily change `ga68_' to something like `ga682_', and no headache
>> > after that. Versioning of interfaces is important and is my main motivation here.
>> >
>> > So we'll have `GA68_JSON_jsonnewobj' or `ga68_JSON_jsonnewobj' by default.
>> 
>> One of the goals for the mangling schema is to be compiler independent.
>
>
> It is compiler-independent. The symbols can be generated by any compiler.
> But GNU Algol 68 implementation decides to generate types/functions that
> are C-compatible as much as possible.  This is your decision as the implementer.
> Someday LLVM may decided to have Algol68 front-end and they
> may want to offer a different ABI for whatever reason.
> Having `GA68_' prefix just emphasize that this symbol is adhering to
> GNU Algol 68 way of generating code.

Sorry but I don't follow.

A C variable foo uses symbol foo.
A Fortran variable foo uses symbol foo, and sometimes foo_ for
historical reasons.

Why would we prefix our symbols with the compiler name, or some other
string?

>> 
>> The identification of the module (versioning) is done better in the
>> interface definition.  The mangled symbols do not need to convey
>> information that is in the module definition interface.
>
>
> I didn't mean versioning of module, it's not our business; I meant versioning
> of "how ga68 compiler is generating symbols for the linker".
> E.g., right now, Algol68's `int' is C's `int', if you decide to change
> it (e.g., to `int64_t' for whatever reason), then new compiler should generate
> symbols with a different name to prevent ABI-incompatibility hell. It can use
> a new prefix `GA682_' for example.

Changing the size of int would be a quite dramatic change and not
something we should do once we release, not even once if we can avoid
it.  The hell that such a thing would unleash would go way beyond any
ABI-incompatibility hell, really.  That is why the size of an Algol 68
int (and long int, etc) is determined by the target.

>
>
>> 
>> 
>> >> 7. Operator symbols, the monads and nomads, are mangled to letter codes
>> >>    symbolizing the symbols:
>> >> 
>> >>      %    (p)ercentage
>> >>      ^    (c)aret
>> >>      &    (a)mpersand
>> >>      +    (p)lus
>> >>      -    (m)inus
>> >>      ~    (t)ilde
>> >>      !    (b)ang
>> >>      ?    (q)uestion mark
>> >>      >    bi(g)ger than
>> >>      <    (l)ess than
>> >>      /    (s)lash
>> >>      =    (e)qual
>> >>      :    c(o)lon
>> >>      *    sta(r)
>> >> 
>> >>    Each letter code is followed by a single underscore character.  So
>> >>    for example, in the following module:
>> >> 
>> >>      module Foo =
>> >>      def
>> >>          int ss;
>> >>          op // = (int a, b) int: a + b;
>> >>          ...
>> >>      fed
>> >> 
>> >>    The identifier ss will mangle to a symbol FOO_ss.
>> >>    The operator // will mangle to a symbol FOO_s_s_.
>> >> 
>> >
>> >
>> > The tricky part here is overloading. Operators can be overloaded for different
>> > modes, and those modes should somehow be reflected in the name.
>> 
>> I don't think so.  Again, there is the interface definition.  The only
>> requirement for the mangled name in that sense is to serve as a key to
>> find the corresponding operator extract in the interface definition,
>> which contains full mode information.
>
>
> Imagine this:
>
> ```algol68
> module Foo =
> def
>   op // = (int a, b) int: a + b;
>   op // = (real a, b) real: a + b;
>   op // = (struct(int a, b) a, struct(int a, b) b) int: a of a + b of b;
>   prio // = 1;
> fed
> ```
>
> How do you call these operators in C?

Oh I see.  In that the symbols should be different, yes.

Well, the only requirement for them is to be different, so we could use
a per-module counter. FOO_s_s_1, FOO_s_s_2, etc.  That is what the
compiler currently uses for non-publicized operators.

Algol 68 uses structural mode equivalence, so encoding the mode in the
symbols in an intelligible way would lead to huge symbols.  Encoding the
mode in a no-intelligible but compact way would be worse than using a
counter.