[RFC 0/9] GNU Algol 68 extension: fixety in modes
Paul Leyland
paul.leyland@gmail.com
Sun Sep 20 15:32:40 GMT 2026
Chris: I like your emendation / correction to my proposal.
Agreed that a number of different modes will be required. I do not
reject the idea of having a bunch of different operators but personally
think that operator overloading is the cleaner more elegant approach.
Certainly
WordReal foo = WORD 3;
should do The Right Thing through a widening coercion.
Paul
On 20/09/2026 15:34, algol68-request@gcc.gnu.org wrote:
> Today's Topics:
>
> 1. Re: [RFC 0/9] GNU Algol 68 extension: fixety in modes
> (Paul Leyland)
> 2. Re: [RFC 0/9] GNU Algol 68 extension: fixety in modes
> (chris hermansen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 20 Sep 2026 14:54:55 +0100
> From: Paul Leyland <paul.leyland@gmail.com>
> To: algol68@gcc.gnu.org
> Subject: Re: [RFC 0/9] GNU Algol 68 extension: fixety in modes
> Message-ID: <b52fc5b2-1c3d-463d-8da3-1f8f399f3f40@gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> Not keen, to be honest.
>
> I understand the desirability of being able to specify a constant value
> to a word--sized object but am leery of extending the syntax of the
> language unless there is overriding value in doing so.
>
> How about the idea of Word being a mode, as in the earlier proposal, and
> `word' being an OP or PROC (my preference is for an OP) defined in the
> standard prelude?
>
> Thus one would write
>
> ? ? Word base = word 16r0;
>
> Paul
>
> On 20/09/2026 13:59, algol68-request@gcc.gnu.org wrote:
>> 1. [RFC 0/9] GNU Algol 68 extension: fixety in modes
>> (Jose E. Marchesi)
>> 2. [RFC 1/9] a68: add syntax for non-cummulative fixetys
>> (Jose E. Marchesi)
>> 3. [RFC 2/9] a68: introduce word sized int, bits, bytes and real
>> types (Jose E. Marchesi)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 20 Sep 2026 14:58:51 +0200
>> From: "Jose E. Marchesi"<jemarch@gnu.org>
>> To:algol68@gcc.gnu.org
>> Subject: [RFC 0/9] GNU Algol 68 extension: fixety in modes
>> Message-ID:<20260920125900.5965-1-jemarch@gnu.org>
>>
>> Hello people!
>>
>> The way Algol 68 provides support for multiple "precision" modes is by
>> allowing to specify a "longsety" or a "shortsety" as part of integral, bits,
>> bytes and real modes, where a longsety is zero or more `long' and a shortsety
>> is zero or more `short'. At some point, depending on the target, adding
>> additional longs or shorts stop increasing or decreasing the precision on of
>> the mode.
>>
>> For example, `int' is an integral mode with default precision, whereas `short
>> int' is an integral mode with less than default precision, and `long int' is
>> an integral mode with more than default precision.
>>
>> The particular precision assigned to a "sizety" (either a longsety or a
>> shortsety) is up to the compiler and, in principle, none of the business of
>> the programmer. The programmer can check the range of values allowed by each
>> mode by using environment enquiries like max_int, short_short_min_int or
>> long_max_real.
>>
>> Now, the GNU Algol 68 compiler provides some guarantees about the precision of
>> the modes, in order to ease integration in the system and communicating with
>> programs written in other programming languages:
>>
>> - The precision of `short short int' is the same than the precision of C
>> `unsigned char'.
>> - The precision of `int' is the same than the C int.
>> - The precision of `long int' is the same than the precision of the next C
>> type with higher precision than `int'.
>> - The precision of `real' is the same than the C `float'.
>> - The precision of `long real' is the same than the C `doubled'.
>> - The precision of `long long real' is the same than the C `long double'.
>> - etc
>>
>> This works well. However, there is still the need for modes with the same
>> precision than the target's word size, or memory address.
>>
>> An alternative that we have considered at some point is to make the compiler
>> define an additional standard mode like:
>>
>> mode Word = long int; { Or short int, or int, or long long int,
>> depending on the target. }
>>
>> This approach wouldn't require extending the language itself, but it has the
>> big problem of denotations which, in Algol 68, also contain sizetys.
>> Depending on the target, you might have to write:
>>
>> Word base = 16r0;
>>
>> or
>>
>> Word base = long 16r0;
>>
>> or even
>>
>> Word base = short 16r0;
>>
>> This patch series implements an alternative approach: rather than having the
>> compiler defining an additional standard modes for word sized bits, ints,
>> reals, etc, the syntax of the language is expanded to allow specifying `word'
>> as a sizety, and so:
>>
>> word bits base = word 16r0;
>>
>> The above will work in any target. Corresponding integral, real and bytes
>> modes of size `word' are also available, and the whole plethora of standard
>> (and extended standard) identifier, operators and procedures are also
>> available:
>>
>> word int counter = word 0;
>> word real num = 1.23;
>> word bits numbits = BIN 1.23;
>>
>> This new `word' size is one of potentially multiple "fixety". The same
>> strategy can be used in order to provide modes of a fixed size independently
>> of the target, like `byte' or others.
>>
>> A possible caveat, however, is that fixetys are not accumulative, unlike
>> longsetys and shortsetys. Therefore LENG and SHORTEN operators don't make
>> sense for values of these modes. This means that it is not possible to
>> convert, say, a `word int' to a `long long int'. This might or might not be a
>> problem in practice.
>>
>> Opinions?
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 20 Sep 2026 16:34:28 +0200
> From: chris hermansen <clhermansen@gmail.com>
> To: Paul Leyland <paul.leyland@gmail.com>
> Cc: algol68@gcc.gnu.org
> Subject: Re: [RFC 0/9] GNU Algol 68 extension: fixety in modes
> Message-ID:
> <CACc2_6-i1XWgA9dfUWJMs4g8Zr_xpy0ENqsBWdWS4U9eZoKwqw@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> not against this approach Paul, a comment below nevertheless
>
> On Sun, Sep 20, 2026, 15:55 Paul Leyland <paul.leyland@gmail.com> wrote:
>
>> Not keen, to be honest.
>>
>> I understand the desirability of being able to specify a constant value
>> to a word--sized object but am leery of extending the syntax of the
>> language unless there is overriding value in doing so.
>>
>> How about the idea of Word being a mode, as in the earlier proposal, and
>> `word' being an OP or PROC (my preference is for an OP) defined in the
>> standard prelude?
>>
>> Thus one would write
>>
>> Word base = word 16r0;
>>
>> Paul
>>
> I think the "problem" here is that a bunch of different modes will be needed
>
> mode WordInt = ..., WordReal = ..., WordBits =...
>
> but your operator will still be WORD, overloaded. So not as symmetric. Or I
> guess you could define more operators WORDREAL, WORDINT etc.
>
> Also, I guess you could end up with
>
> WordReal foo = WORD 3
>
> where the expression on the right would deliver a value of WordInt which
> would then be widened to WordReal. Would this happen the same way with
> Jose's alternative proposal? Ie could we expect to be able to write
>
> word real foo = word 3
>
> ?? I should think so...
>
>
>
>> On 20/09/2026 13:59, algol68-request@gcc.gnu.org wrote:
>>> 1. [RFC 0/9] GNU Algol 68 extension: fixety in modes
>>> (Jose E. Marchesi)
>>> 2. [RFC 1/9] a68: add syntax for non-cummulative fixetys
>>> (Jose E. Marchesi)
>>> 3. [RFC 2/9] a68: introduce word sized int, bits, bytes and real
>>> types (Jose E. Marchesi)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Sun, 20 Sep 2026 14:58:51 +0200
>>> From: "Jose E. Marchesi"<jemarch@gnu.org>
>>> To:algol68@gcc.gnu.org
>>> Subject: [RFC 0/9] GNU Algol 68 extension: fixety in modes
>>> Message-ID:<20260920125900.5965-1-jemarch@gnu.org>
>>>
>>> Hello people!
>>>
>>> The way Algol 68 provides support for multiple "precision" modes is by
>>> allowing to specify a "longsety" or a "shortsety" as part of integral,
>> bits,
>>> bytes and real modes, where a longsety is zero or more `long' and a
>> shortsety
>>> is zero or more `short'. At some point, depending on the target, adding
>>> additional longs or shorts stop increasing or decreasing the precision
>> on of
>>> the mode.
>>>
>>> For example, `int' is an integral mode with default precision, whereas
>> `short
>>> int' is an integral mode with less than default precision, and `long
>> int' is
>>> an integral mode with more than default precision.
>>>
>>> The particular precision assigned to a "sizety" (either a longsety or a
>>> shortsety) is up to the compiler and, in principle, none of the business
>> of
>>> the programmer. The programmer can check the range of values allowed by
>> each
>>> mode by using environment enquiries like max_int, short_short_min_int or
>>> long_max_real.
>>>
>>> Now, the GNU Algol 68 compiler provides some guarantees about the
>> precision of
>>> the modes, in order to ease integration in the system and communicating
>> with
>>> programs written in other programming languages:
>>>
>>> - The precision of `short short int' is the same than the precision of
>> C
>>> `unsigned char'.
>>> - The precision of `int' is the same than the C int.
>>> - The precision of `long int' is the same than the precision of the
>> next C
>>> type with higher precision than `int'.
>>> - The precision of `real' is the same than the C `float'.
>>> - The precision of `long real' is the same than the C `doubled'.
>>> - The precision of `long long real' is the same than the C `long
>> double'.
>>> - etc
>>>
>>> This works well. However, there is still the need for modes with the
>> same
>>> precision than the target's word size, or memory address.
>>>
>>> An alternative that we have considered at some point is to make the
>> compiler
>>> define an additional standard mode like:
>>>
>>> mode Word = long int; { Or short int, or int, or long long int,
>>> depending on the target. }
>>>
>>> This approach wouldn't require extending the language itself, but it has
>> the
>>> big problem of denotations which, in Algol 68, also contain sizetys.
>>> Depending on the target, you might have to write:
>>>
>>> Word base = 16r0;
>>>
>>> or
>>>
>>> Word base = long 16r0;
>>>
>>> or even
>>>
>>> Word base = short 16r0;
>>>
>>> This patch series implements an alternative approach: rather than having
>> the
>>> compiler defining an additional standard modes for word sized bits, ints,
>>> reals, etc, the syntax of the language is expanded to allow specifying
>> `word'
>>> as a sizety, and so:
>>>
>>> word bits base = word 16r0;
>>>
>>> The above will work in any target. Corresponding integral, real and
>> bytes
>>> modes of size `word' are also available, and the whole plethora of
>> standard
>>> (and extended standard) identifier, operators and procedures are also
>>> available:
>>>
>>> word int counter = word 0;
>>> word real num = 1.23;
>>> word bits numbits = BIN 1.23;
>>>
>>> This new `word' size is one of potentially multiple "fixety". The same
>>> strategy can be used in order to provide modes of a fixed size
>> independently
>>> of the target, like `byte' or others.
>>>
>>> A possible caveat, however, is that fixetys are not accumulative, unlike
>>> longsetys and shortsetys. Therefore LENG and SHORTEN operators don't
>> make
>>> sense for values of these modes. This means that it is not possible to
>>> convert, say, a `word int' to a `long long int'. This might or might
>> not be a
>>> problem in practice.
>>>
>>> Opinions?
>>
> 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/20260920/404ba8be/attachment.htm>
>
> ------------------------------
>
> Subject: Digest Footer
>
> Algol68 mailing list
> Algol68@gcc.gnu.org
> https://gcc.gnu.org/mailman/listinfo/algol68
>
>
> ------------------------------
>
> End of Algol68 Digest, Vol 19, Issue 25
> ***************************************
More information about the Algol68
mailing list