Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #391294 > unrolled thread

Bart's Language

Back to article view | Back to comp.lang.c

Contents

  Bart's Language bart <bc@freeuk.com> - 2025-03-17 23:51 +0000
    Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 12:17 +0000
      Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 13:54 +0000
        Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-18 15:10 +0000
          Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 15:45 +0000
            Re: Bart's Language David Brown <david.brown@hesbynett.no> - 2025-03-18 17:31 +0100
              int a = a (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-18 18:04 +0000
                Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 19:36 +0100
                  Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-18 19:11 +0000
                  Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 15:56 +0100
                    Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-19 16:38 +0000
                      Re: int a = a (Was: Bart's Language) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-03-19 14:29 -0700
                        Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 09:39 +0100
                          Re: int a = a (Was: Bart's Language) bart <bc@freeuk.com> - 2025-03-20 11:59 +0000
                            Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:46 +0100
                              Re: int a = a (Was: Bart's Language) wij <wyniijj5@gmail.com> - 2025-03-20 23:13 +0800
                      Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:02 -0700
                        Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-20 15:57 +0100
                    Re: int a = a (Was: Bart's Language) Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-19 17:07 +0000
                    Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 13:34 -0700
                      Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 02:54 -0700
                        Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 03:20 -0700
                          Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 16:22 +0100
                            Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 12:46 -0700
                              Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 10:44 +0100
                                Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-21 12:23 -0700
                                  Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-21 21:46 +0100
                                  Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 13:59 -0700
                                    Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-22 15:37 -0700
                                      Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-28 09:39 -0700
                          Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-29 13:12 -0700
                            Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-29 13:34 -0700
                      Re: int a = a David Brown <david.brown@hesbynett.no> - 2025-03-20 15:42 +0100
                Re: int a = a (Was: Bart's Language) scott@slp53.sl.home (Scott Lurndal) - 2025-03-18 19:37 +0000
                Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-18 20:51 +0100
                  Re: int a = a (Was: Bart's Language) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-03-18 23:27 +0100
                    Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:40 +0100
                Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-18 23:52 -0700
                  Re: int a = a Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-19 01:55 -0700
                    Re: int a = a Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 13:41 -0700
                  Re: int a = a (Was: Bart's Language) David Brown <david.brown@hesbynett.no> - 2025-03-19 11:43 +0100
                  Re: int a = a (Was: Bart's Language) Rosario19 <Ros@invalid.invalid> - 2025-03-19 13:23 +0100
                    Re: int a = a (Was: Bart's Language) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-20 01:32 -0700
            Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:55 +0000
              Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-20 16:22 -0700
                Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 14:37 +0000
                  Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 11:41 -0400
                    Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-22 16:52 +0000
                      Re: Bart's Language James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-22 20:12 -0400
                    By definition... (Was: Bart's Language) gazelle@shell.xmission.com (Kenny McCormack) - 2025-03-23 17:20 +0000
                Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 11:53 -0700
                  Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-27 14:29 -0700
                    Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 14:04 -0800
                      Re: Bart's Language Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-06 17:12 -0800
                        Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-06 09:04 -0800
          Re: Bart's Language bart <bc@freeuk.com> - 2025-03-18 22:19 +0000
            Re: Bart's Language antispam@fricas.org (Waldek Hebisch) - 2025-03-20 22:38 +0000
              Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-20 23:45 +0000
                Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:56 +0000
                  Re: Bart's Language Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-21 17:47 +0000
                    Re: Bart's Language Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-22 07:12 -0700
              Re: Bart's Language bart <bc@freeuk.com> - 2025-03-21 00:33 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#391344 — Re: int a = a (Was: Bart's Language)

On 19/03/2025 07:52, Tim Rentsch wrote:
> gazelle@shell.xmission.com (Kenny McCormack) writes:
> 
>> In article <vrc75b$2r4lt$1@dont-email.me>,
>> David Brown  <david.brown@hesbynett.no> wrote:
>> ...
>>
>>>> gcc won't warn until you say '-Wextra', and then only for:
>>>>
>>>>     int a = a + 1;
>>>
>>> People would not normally write "int a = a;".  It is used as a
>>> common idiom meaning "I know it is not clear to the compiler that
>>> the variable is always initialised before use, but /I/ know it is -
>>> so disable the use-without-initialisation warnings for this
>>> variable".  So it makes perfect sense for the compiler not to warn
>>> about it!
> 
> An addle-brained view.  Anyone who thinks that should be forcibly
> removed from any activity involving software development.
> 

I think this is the first time in years that you have quoted me, keeping 
the attribution in place, and replied to directly to the quoted part. 
Unsurprisingly, it looks like you put more effort into thinking up a 
"cool" insult than into reading what I actually wrote.

I look forward to your next well-considered reply, perhaps some time in 
the autumn.

[toc] | [prev] | [next] | [standalone]

#391347 — Re: int a = a (Was: Bart's Language)

On Tue, 18 Mar 2025 23:52:20 -0700, Tim Rentsch  wrote:

>(Kenny McCormack) writes:
>
>> David Brown wrote:
>> ...
>>
>>>> gcc won't warn until you say '-Wextra', and then only for:
>>>>
>>>>    int a = a + 1;
>>>
>>> People would not normally write "int a = a;".  It is used as a
>>> common idiom meaning "I know it is not clear to the compiler that
>>> the variable is always initialised before use, but /I/ know it is -
>>> so disable the use-without-initialisation warnings for this
>>> variable".  So it makes perfect sense for the compiler not to warn
>>> about it!
>
>An addle-brained view.  Anyone who thinks that should be forcibly
>removed from any activity involving software development.
>
>> Wouldn't it just be easier and clearer to write:  int a = 0;
>> and be done with it?
>
>There are two problems:  one, the semantics are different;  and two,
>the impression given of the author's intent is different.  It's kind
>of like saying "isn't it just easier and clearer to write 'red'
>rather than 'yellow'?"  Writing 'int a = 0;' might be better or it
>might be worse, depending on one's point of view, but it shouldn't
>be considered either more clear or less clear, because it isn't
>saying the same thing.

int a=a;
for me initialize "a" variable with a value the compiler found right
as in
 
int a;

only possibly silence compiler warning for variable not initializated

[toc] | [prev] | [next] | [standalone]

#391386 — Re: int a = a (Was: Bart's Language)

Rosario19 <Ros@invalid.invalid> writes:

> On Tue, 18 Mar 2025 23:52:20 -0700, Tim Rentsch  wrote:
>
>> (Kenny McCormack) writes:
>>
>>> David Brown wrote:
>>> ...
>>>
>>>>> gcc won't warn until you say '-Wextra', and then only for:
>>>>>
>>>>>    int a = a + 1;
>>>>
>>>> People would not normally write "int a = a;".  It is used as a
>>>> common idiom meaning "I know it is not clear to the compiler
>>>> that the variable is always initialised before use, but /I/
>>>> know it is - so disable the use-without-initialisation warnings
>>>> for this variable".  So it makes perfect sense for the compiler
>>>> not to warn about it!
>>
>> An addle-brained view.  Anyone who thinks that should be forcibly
>> removed from any activity involving software development.
>>
>>> Wouldn't it just be easier and clearer to write:  int a = 0;
>>> and be done with it?
>>
>> There are two problems:  one, the semantics are different;  and
>> two, the impression given of the author's intent is different.
>> It's kind of like saying "isn't it just easier and clearer to
>> write 'red' rather than 'yellow'?"  Writing 'int a = 0;' might be
>> better or it might be worse, depending on one's point of view,
>> but it shouldn't be considered either more clear or less clear,
>> because it isn't saying the same thing.
>
> int a=a;
> for me initialize "a" variable with a value the compiler found
> right as in
>
> int a;
>
> only possibly silence compiler warning for variable not
> initializated

If you want to take it that way, there is nothing wrong with
that.

But it's a mistake to assume everyone else will also take it to
mean the same thing that you do.

[toc] | [prev] | [next] | [standalone]

#391447

bart <bc@freeuk.com> wrote:
> On 18/03/2025 15:10, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 18/03/2025 12:17, Waldek Hebisch wrote:
> 
>> I see.  So your feature conflicts with C feature "variable which is
>> initialized at declaration time is always used initialized".
> 
> That doesn't happen here:
> 
>   int a = a;
> 
> gcc (with no extra options) tcc and bcc both put some undefined value in a.
> 
> gcc won't warn until you say '-Wextra', and then only for:
> 
>   int a = a + 1;

Well, it is rather easy to see if variable is used within its
own initialization, so practically it is minor gap.  Of course,
there is problem with C standard: IIUC depending on rest of
the code declarations as above are merely undefined behaviour
or even produce unspecified value.  So C compiler is
forbidden to stop compilation are report compile time error.

However, your language has no constrains that C has, so you
could do better.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#391450

antispam@fricas.org (Waldek Hebisch) writes:
[...]
> Well, it is rather easy to see if variable is used within its
> own initialization, so practically it is minor gap.  Of course,
> there is problem with C standard: IIUC depending on rest of
> the code declarations as above are merely undefined behaviour
> or even produce unspecified value.  So C compiler is
> forbidden to stop compilation are report compile time error.

Valid responses to undefined behavior include "terminating a translation
or execution (with the issuance of a diagnostic message)".  In other
words, if a compiler is able to prove that a program has undefined
behavior (that will occur on each execution), it can reject it at
compile time.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#391510

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
> [...]
>> Well, it is rather easy to see if variable is used within its
>> own initialization, so practically it is minor gap.  Of course,
>> there is problem with C standard: IIUC depending on rest of
>> the code declarations as above are merely undefined behaviour
>> or even produce unspecified value.  So C compiler is
>> forbidden to stop compilation are report compile time error.
> 
> Valid responses to undefined behavior include "terminating a translation
> or execution (with the issuance of a diagnostic message)".  In other
> words, if a compiler is able to prove that a program has undefined
> behavior (that will occur on each execution), it can reject it at
> compile time.

This was probably subject to previous disscussion here,  IIRC
some posters here claimed that even in such case implementation
is supposed to produce an executable.  However, certainly
implementation must accept the program when code that would
exhibit undefined behaviour is not executed.  And in practice
when using separate compilation compiler normally is not
able to decide if a function will be called or not (and even
when whole program is available compiler still have halting
problem to solve).  So cases when compiler is allowed to report
compilation error are quite limite in practice.

So, putting a constraint on self reference in initialization
would improve error detection in C compilers.  And of course
languages that what to be better than C should avoid C
mistake.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#391512

On 3/22/25 10:37, Waldek Hebisch wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
...
>> Valid responses to undefined behavior include "terminating a translation
>> or execution (with the issuance of a diagnostic message)".  In other
>> words, if a compiler is able to prove that a program has undefined
>> behavior (that will occur on each execution), it can reject it at
>> compile time.
> 
> This was probably subject to previous disscussion here,  IIRC
> some posters here claimed that even in such case implementation
> is supposed to produce an executable.

There is no such requirement. Could you identify who made such a claim,
when, with what arguments? My newserver's archives only go back three
months, and if the claim was made by somebody I've got killfiled, I
won't be able to see it even during that time period. Google Groups
stopped archiving new messages quite a while ago. Therefore, it might be
best to quote the relevant text, rather than merely identifying it.

>  However, certainly
> implementation must accept the program when code that would
> exhibit undefined behaviour is not executed.  And in practice
> when using separate compilation compiler normally is not
> able to decide if a function will be called or not (and even
> when whole program is available compiler still have halting
> problem to solve).  So cases when compiler is allowed to report
> compilation error are quite limite in practice.

Keep in mind that the Halting problem is difficult only because the
decider must handle every case. Compilers are, in practice, able to
detect many cases of undefined behavior, even though they are not
capable of detecting them all.

[toc] | [prev] | [next] | [standalone]

#391516

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 3/22/25 10:37, Waldek Hebisch wrote:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> ...
>>> Valid responses to undefined behavior include "terminating a translation
>>> or execution (with the issuance of a diagnostic message)".  In other
>>> words, if a compiler is able to prove that a program has undefined
>>> behavior (that will occur on each execution), it can reject it at
>>> compile time.
>> 
>> This was probably subject to previous disscussion here,  IIRC
>> some posters here claimed that even in such case implementation
>> is supposed to produce an executable.
> 
> There is no such requirement. Could you identify who made such a claim,
> when, with what arguments? My newserver's archives only go back three
> months, and if the claim was made by somebody I've got killfiled, I
> won't be able to see it even during that time period. Google Groups
> stopped archiving new messages quite a while ago. Therefore, it might be
> best to quote the relevant text, rather than merely identifying it.

Sorry, is would be quite a lot of work to find relevant messages.
 
-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#391531

On 3/22/25 12:52, Waldek Hebisch wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 3/22/25 10:37, Waldek Hebisch wrote:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> ...
>>>> Valid responses to undefined behavior include "terminating a translation
>>>> or execution (with the issuance of a diagnostic message)".  In other
>>>> words, if a compiler is able to prove that a program has undefined
>>>> behavior (that will occur on each execution), it can reject it at
>>>> compile time.
>>>
>>> This was probably subject to previous disscussion here,  IIRC
>>> some posters here claimed that even in such case implementation
>>> is supposed to produce an executable.
>>
>> There is no such requirement. Could you identify who made such a claim,
>> when, with what arguments? My newserver's archives only go back three
>> months, and if the claim was made by somebody I've got killfiled, I
>> won't be able to see it even during that time period. Google Groups
>> stopped archiving new messages quite a while ago. Therefore, it might be
>> best to quote the relevant text, rather than merely identifying it.
> 
> Sorry, is would be quite a lot of work to find relevant messages.

Then I will go ahead with the assumption that those arguments are
invalid until they are identfied.

[toc] | [prev] | [next] | [standalone]

#391545 — By definition... (Was: Bart's Language)

In article <vrmln3$7dks$1@dont-email.me>,
James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
...
>There is no such requirement. Could you identify who made such a claim,
>when, with what arguments? My newserver's archives only go back three
>months, and if the claim was made by somebody I've got killfiled, ...

If it was by somebody you've KF'd, then, by definition, you don't want to
read it.  So, we are all doing you a favor by not identifying the post.

Wouldn't want you to hurt your tender eyes.
-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/ThePublicGood

[toc] | [prev] | [next] | [standalone]

#392923

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> antispam@fricas.org (Waldek Hebisch) writes:
> [...]
>
>> Well, it is rather easy to see if variable is used within its
>> own initialization, so practically it is minor gap.  Of course,
>> there is problem with C standard:  IIUC depending on rest of
>> the code declarations as above are merely undefined behaviour
>> or even produce unspecified value.  So C compiler is
>> forbidden to stop compilation are report compile time error.
>
> Valid responses to undefined behavior include "terminating a translation
> or execution (with the issuance of a diagnostic message)".

That's true, but doing so is allowed only if the circumstances
of undefined behavior have occurred.  In the case of compiling
a declaration such as

    int a = a;

no undefined behavior has as yet occurred.

> In other
> words, if a compiler is able to prove that a program has undefined
> behavior (that will occur on each execution), it can reject it at
> compile time.

The program can be rejected, but not because of the rule about
terminating a translation.  The program can be rejected because
the program is not strictly conforming, and implementations are
not required to accept programs that are not strictly conforming.

[toc] | [prev] | [next] | [standalone]

#392928

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> antispam@fricas.org (Waldek Hebisch) writes:
>> [...]
>>> Well, it is rather easy to see if variable is used within its
>>> own initialization, so practically it is minor gap.  Of course,
>>> there is problem with C standard:  IIUC depending on rest of
>>> the code declarations as above are merely undefined behaviour
>>> or even produce unspecified value.  So C compiler is
>>> forbidden to stop compilation are report compile time error.
>>
>> Valid responses to undefined behavior include "terminating a translation
>> or execution (with the issuance of a diagnostic message)".
>
> That's true, but doing so is allowed only if the circumstances
> of undefined behavior have occurred.  In the case of compiling
> a declaration such as
>
>     int a = a;
>
> no undefined behavior has as yet occurred.

N3096 6.3.2.1p2 (lvalue conversion):

    If the lvalue designates an object of automatic storage duration
    that could have been declared with the register storage class (never
    had its address taken), and that object is uninitialized (not
    declared with an initializer and no assignment to it has been
    performed prior to use), the behavior is undefined.

Strictly speaking, `a` doesn't meet the definition of
"uninitialized", since it is declared with an initializer, but
its value is accessed before the initialization has been executed.
I'm not entirely certain that `int a = a;` has undefined behavior,
but it's unclear that the behavior is defined.

>> In other
>> words, if a compiler is able to prove that a program has undefined
>> behavior (that will occur on each execution), it can reject it at
>> compile time.
>
> The program can be rejected, but not because of the rule about
> terminating a translation.  The program can be rejected because
> the program is not strictly conforming, and implementations are
> not required to accept programs that are not strictly conforming.

I disagree, but we've gone over this before with no resolution.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#396234

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> antispam@fricas.org (Waldek Hebisch) writes:
>>> [...]
>>>
>>>> Well, it is rather easy to see if variable is used within its
>>>> own initialization, so practically it is minor gap.  Of course,
>>>> there is problem with C standard:  IIUC depending on rest of
>>>> the code declarations as above are merely undefined behaviour
>>>> or even produce unspecified value.  So C compiler is
>>>> forbidden to stop compilation are report compile time error.
>>>
>>> Valid responses to undefined behavior include "terminating a translation
>>> or execution (with the issuance of a diagnostic message)".
>>
>> That's true, but doing so is allowed only if the circumstances
>> of undefined behavior have occurred.  In the case of compiling
>> a declaration such as
>>
>>     int a = a;
>>
>> no undefined behavior has as yet occurred.
>
> N3096 6.3.2.1p2 (lvalue conversion):
>
>     If the lvalue designates an object of automatic storage duration
>     that could have been declared with the register storage class (never
>     had its address taken), and that object is uninitialized (not
>     declared with an initializer and no assignment to it has been
>     performed prior to use), the behavior is undefined.
>
> Strictly speaking, `a` doesn't meet the definition of
> "uninitialized", since it is declared with an initializer, but
> its value is accessed before the initialization has been executed.
> I'm not entirely certain that `int a = a;` has undefined behavior,
> but it's unclear that the behavior is defined.

Clearly the term "uninitialized" is meant to refer to a dynamic
property, not a static property.  At the point on the right side
of the '=' where the access is performed, the object designated
by 'a' has not been initialized.

>>> In other
>>> words, if a compiler is able to prove that a program has undefined
>>> behavior (that will occur on each execution), it can reject it at
>>> compile time.
>>
>> The program can be rejected, but not because of the rule about
>> terminating a translation.  The program can be rejected because
>> the program is not strictly conforming, and implementations are
>> not required to accept programs that are not strictly conforming.
>
> I disagree, but we've gone over this before with no resolution.

Have you ever offered reasoning to explain your belief, or
did you give just an unsupported conclusion?  Can you explain
the reasoning that underlies your disagreement?

[toc] | [prev] | [next] | [standalone]

#396240

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>>> The program can be rejected, but not because of the rule about
>>> terminating a translation.  The program can be rejected because
>>> the program is not strictly conforming, and implementations are
>>> not required to accept programs that are not strictly conforming.
>>
>> I disagree, but we've gone over this before with no resolution.
>
> Have you ever offered reasoning to explain your belief, or
> did you give just an unsupported conclusion?  Can you explain
> the reasoning that underlies your disagreement?

I believe I have.  I'm not interested in resurrecting that old
debate.  Past experience indicates that no meaningful resolution
will be reached.

I'll note that you've posted a followup to something I wrote more
than eight months ago.  That's one of several reasons I'm not
interested in a discussion.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#396828

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> I'll note that you've posted a followup to something I wrote more
> than eight months ago.

I respond to postings when I think I have something relevant
to say.  That some of the postings I respond to were not
posted in the recent past is an accident of history, not
more than that.

[toc] | [prev] | [next] | [standalone]

#391317

On 18/03/2025 15:10, Waldek Hebisch wrote:
> bart <bc@freeuk.com> wrote:
>> On 18/03/2025 12:17, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>>
>>>> This is the document I produced:
>>>>
>>>> https://github.com/sal55/langs/blob/master/MFeatures.md
>>>>
>>>> A couple of more substantial demo programs are here:
>>>> https://github.com/sal55/langs/tree/master/MExamples
>>>>
>>>> (The bignum.m file was ported - by hand - to the bignum.c version that I
>>>> posted recently.)
>>>
>>> Looking at features, can you say if the program below works?
>>> And if it works, what is retrun value of foo?  "Equvalent" can
>>> be written in C, but in C you have to keep sane order.
>>
>>
>> There were some tweaks needed; it indicates some basic info missing from
>> my write-up! (For example, that the function call needs to be bar() not
>> bar; 'const' is only for compile-time expressions; and that C's 'const'
>> doesn't exist - it only briefly mentions an attempt at 'let'.)
>>
>> The revised code is shown below, with what I assumed were your
>> intentions.
> 
> Well, my intentions beter correspond to the C version below:
> 
> int foo() {
>      const int c = c1(10);
>      const int b = c + c2(2);
>      const int a = b+c3(c);
>      bar();
>      baz();
>      return c;
> }


In this case, just write it like that, and only adjust it for the 
somewhat different syntax:

   func foo:int =
       let int c := c1(10)
       let int b := c + c2(2)
       let int a := b+c3(c)
       bar()
       baz()
       return c
   end

'let' seems to still work, and will do the job of C's const in simple 
cases like this.

Versions in both languages now report Lines 5 3 1 2 4.

The 'let' here is enforced more strongly that C's 'const', in that it 
/has/ to be initialised. C needs the right compiler and the right options
to complain about it.










> 
> Part of the question was if "execution" of declarations is
> interleaved with execution of code or if declarations go
> before the code.
> 
> I am not saying that you should implement this, rejecting the
> code as insane would be fine for me.
> 
>> And below that is that code ported to C. Both versions
>> produce this output:
>>
>>   Line 1
>>   Line 2
>>   Line 3
>>   Line 4
>>   Line 5
>>   10
>>   Line 1
>>   Line 2
>>   Line 3
>>   Line 4
>>   Line 5
>>   10
>>
>> Note that both 'b' and 'c' in foo() are used uninitialised. I couldn't
>> apply 'const' to those, as the const declaration would be separate from
>> the assignment, and the later assignment is then not possible.
>>
>> (To answer your presumably implied point, in:
>>
>>       print a
>>       int a:=100
>>
>> the assignment is done at that place in the code (after print), but the
>> scope of 'a' is function-wide. My compiler doesn't detect accesses to
>> unitialised variables, but I could add a debug option to clear
>> stack-frame variables on function entry.)
> 
> I see.  So your feature conflicts with C feature "variable which is
> initialized at declaration time is always used initialized".
> 

[toc] | [prev] | [next] | [standalone]

#391446

bart <bc@freeuk.com> wrote:
> On 18/03/2025 15:10, Waldek Hebisch wrote:
>> bart <bc@freeuk.com> wrote:
>>> On 18/03/2025 12:17, Waldek Hebisch wrote:
>>>> bart <bc@freeuk.com> wrote:
>>>>>
>>>>> This is the document I produced:
>>>>>
>>>>> https://github.com/sal55/langs/blob/master/MFeatures.md
>>>>>
>>>>> A couple of more substantial demo programs are here:
>>>>> https://github.com/sal55/langs/tree/master/MExamples
>>>>>
>>>>> (The bignum.m file was ported - by hand - to the bignum.c version that I
>>>>> posted recently.)
>>>>
>>>> Looking at features, can you say if the program below works?
>>>> And if it works, what is retrun value of foo?  "Equvalent" can
>>>> be written in C, but in C you have to keep sane order.
>>>
>>>
>>> There were some tweaks needed; it indicates some basic info missing from
>>> my write-up! (For example, that the function call needs to be bar() not
>>> bar; 'const' is only for compile-time expressions; and that C's 'const'
>>> doesn't exist - it only briefly mentions an attempt at 'let'.)
>>>
>>> The revised code is shown below, with what I assumed were your
>>> intentions.
>> 
>> Well, my intentions beter correspond to the C version below:
>> 
>> int foo() {
>>      const int c = c1(10);
>>      const int b = c + c2(2);
>>      const int a = b+c3(c);
>>      bar();
>>      baz();
>>      return c;
>> }
> 
> 
> In this case, just write it like that, and only adjust it for the 
> somewhat different syntax:
> 
>   func foo:int =
>       let int c := c1(10)
>       let int b := c + c2(2)
>       let int a := b+c3(c)
>       bar()
>       baz()
>       return c
>   end

In your description you wrote that declarations can be written
"out of order" and compiler will rearrange them in correct
order.  That looked like great opportunity to write obfuscated
code.  As you explained, it works differently, but I think
already the fixed version of code I gave shows potential.
And the following seem to satisfy your restriction that
'const' is compile time constant and what happens is
puzzling to the reader (better than goto-s used to confuse
control flow):

func foo:int =
    const a = b + c
    let int cc := c1(a)
    const b = c + 2
    let int bb := c2(b) + cc
    const c = 10
    bb + c
end

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#391451

On 2025-03-20, Waldek Hebisch <antispam@fricas.org> wrote:
> bart <bc@freeuk.com> wrote:
>> On 18/03/2025 15:10, Waldek Hebisch wrote:
>>> bart <bc@freeuk.com> wrote:
>>>> On 18/03/2025 12:17, Waldek Hebisch wrote:
>>>>> bart <bc@freeuk.com> wrote:
>>>>>>
>>>>>> This is the document I produced:
>>>>>>
>>>>>> https://github.com/sal55/langs/blob/master/MFeatures.md
>>>>>>
>>>>>> A couple of more substantial demo programs are here:
>>>>>> https://github.com/sal55/langs/tree/master/MExamples
>>>>>>
>>>>>> (The bignum.m file was ported - by hand - to the bignum.c version that I
>>>>>> posted recently.)
>>>>>
>>>>> Looking at features, can you say if the program below works?
>>>>> And if it works, what is retrun value of foo?  "Equvalent" can
>>>>> be written in C, but in C you have to keep sane order.
>>>>
>>>>
>>>> There were some tweaks needed; it indicates some basic info missing from
>>>> my write-up! (For example, that the function call needs to be bar() not
>>>> bar; 'const' is only for compile-time expressions; and that C's 'const'
>>>> doesn't exist - it only briefly mentions an attempt at 'let'.)
>>>>
>>>> The revised code is shown below, with what I assumed were your
>>>> intentions.
>>> 
>>> Well, my intentions beter correspond to the C version below:
>>> 
>>> int foo() {
>>>      const int c = c1(10);
>>>      const int b = c + c2(2);
>>>      const int a = b+c3(c);
>>>      bar();
>>>      baz();
>>>      return c;
>>> }
>> 
>> 
>> In this case, just write it like that, and only adjust it for the 
>> somewhat different syntax:
>> 
>>   func foo:int =
>>       let int c := c1(10)
>>       let int b := c + c2(2)
>>       let int a := b+c3(c)
>>       bar()
>>       baz()
>>       return c
>>   end
>
> In your description you wrote that declarations can be written
> "out of order" and compiler will rearrange them in correct
> order.  That looked like great opportunity to write obfuscated
> code.

I made a language feature like that: mlet.

https://www.nongnu.org/txr/txr-manpage.html#N-2B3072E9

This allows for circular references in order to support
the construction of lazy objects:

1> (mlet ((a (lcons 1 b))
          (b (lcons 0 a)))
    (take 20 a))
(1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0)

If we use the regular cons function, rather than the
lcons lazy cons macro operator:

2> (mlet ((a (cons 1 b))
          (b (cons 0 a)))
    (take 20 a))
** expr-1:1: force: recursion forcing delayed form (cons 1 b) (expr-1:1)

When there isn't circularity, the expressions can be in
any order; the lazy machinery will force the evaluation
of everything in the correct order:

2> (mlet ((x (+ y 3))
          (z (+ x 1))
          (y 4))
     (+ z 4))
12

First y gets 4, so (+ y 3) can initialize x to 7,
after which z can take (+ x 1) to get 8. Then
the body evaluates (+ z 4) to 12.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#391459

On 20/03/2025 23:45, Kaz Kylheku wrote:
> On 2025-03-20, Waldek Hebisch <antispam@fricas.org> wrote:
>> bart <bc@freeuk.com> wrote:

>>> In this case, just write it like that, and only adjust it for the
>>> somewhat different syntax:
>>>
>>>    func foo:int =
>>>        let int c := c1(10)
>>>        let int b := c + c2(2)
>>>        let int a := b+c3(c)
>>>        bar()
>>>        baz()
>>>        return c
>>>    end
>>
   >> In your description you wrote that declarations can be written
>> "out of order" and compiler will rearrange them in correct
>> order.  That looked like great opportunity to write obfuscated
>> code.
> 
> I made a language feature like that: mlet.
> 
> https://www.nongnu.org/txr/txr-manpage.html#N-2B3072E9
> 
> This allows for circular references in order to support
> the construction of lazy objects:
> 
> 1> (mlet ((a (lcons 1 b))
>            (b (lcons 0 a)))
>      (take 20 a))
> (1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0)

I don't understand what's going on above; the example here is a bit 
clearer, other than that z at the end:

   (mlet ((x (+ y 1))
          (y (+ z 1))
          (z (+ x 1)))
     z)

But this looks like something that goes on at runtime. In the language 
above, it's all dealt with at compile time. If I create a similar example:

  const x = y + 1,
        y = z + 1,
        z = x + 1

then it is the compiler that reports a circular reference.

Otherwise, in my dynamic (and non-lazy) language, circular references 
are allowed at runtime, but it is object references rather than names:

    a ::= (1,2,3)   # create two short lists (::= makes a mutable copy)
    b ::= (4,5,6)

    a &:= b         # append each to the other (concatenate is
    b &:= a         # well-behaved)

    println a
    println b

Shows two now infinite lists:

   (1,2,3,(4,5,6,(1,2,3,(4,5,6,...))))
   (4,5,6,(1,2,3,(4,5,6,(1,2,3,...))))

(An attempt to deep-copy one of those will end badly.)

[toc] | [prev] | [next] | [standalone]

#391476

On 2025-03-21, bart <bc@freeuk.com> wrote:
> On 20/03/2025 23:45, Kaz Kylheku wrote:
>> On 2025-03-20, Waldek Hebisch <antispam@fricas.org> wrote:
>>> bart <bc@freeuk.com> wrote:
>
>>>> In this case, just write it like that, and only adjust it for the
>>>> somewhat different syntax:
>>>>
>>>>    func foo:int =
>>>>        let int c := c1(10)
>>>>        let int b := c + c2(2)
>>>>        let int a := b+c3(c)
>>>>        bar()
>>>>        baz()
>>>>        return c
>>>>    end
>>>
>    >> In your description you wrote that declarations can be written
>>> "out of order" and compiler will rearrange them in correct
>>> order.  That looked like great opportunity to write obfuscated
>>> code.
>> 
>> I made a language feature like that: mlet.
>> 
>> https://www.nongnu.org/txr/txr-manpage.html#N-2B3072E9
>> 
>> This allows for circular references in order to support
>> the construction of lazy objects:
>> 
>> 1> (mlet ((a (lcons 1 b))
>>            (b (lcons 0 a)))
>>      (take 20 a))
>> (1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0)
>
> I don't understand what's going on above; the example here is a bit 
> clearer, other than that z at the end:

What's going on is that 

1. A variable that is not accessed is not initialized at all.
   When a variable is used for the first time (dynamically;
   determined at run time as you correcly observe) the
   initializing expression is evaluated then. Here, we don't
   see the (print 42) side effedt in the case where x is not
   used:

     1> (mlet ((x (prinl 42))) x)
     42
     42
     2> (mlet ((x (prinl 42))))
     nil

2. lcons is also a lazy construct; it is not a function but
   a macro operator. It constructs and returns a lazy cons
   cell which is associated with a lambda function that will
   fill the car and cdr of the lazy cons cell when either of
   those fields are accessed for the first time.
   So (lcons 1 b) returns a lazy cons which is uninitialized.
   When we access it, 1 is put into the car, and b is evaluated
   and put into the cdr.

3. The first thing to be evaluated is the body expression (take 20 a).
   This causes (lcons 1 b) to be evaluated and a to take on that
   value. The take function will traverse into that cell, triggering
   b's initializer (lcons 0 a) being evaluated. 
   When the take function steps into that second cell, triggering
   its lazy initialization, variable a already has a value,
   pointing to the first cell. So the circular list is closed.
   take then just keeps walking the finished circular list, until
   it obtains 20 items.

>    (mlet ((x (+ y 1))
>           (y (+ z 1))
>           (z (+ x 1)))
>      z)
>
> But this looks like something that goes on at runtime. In the language 
> above, it's all dealt with at compile time. If I create a similar example:

Serious functional languages which are single-mindedly dedicated to lazy
semantics will hoist a lot of this kind of processing to compile time.

I could make a non-lazy binding macro which determines the dependencies among
the expressions, detects and diagnoses cycles, and then emits a regular let
based on a topological sort of the dependencies.

The tools are there; there is an API by which a macro can ask what are the free
variable references emanating from a piece of code, so we can know exactly
which of the variables in the circular let construct are being referenced by
which initializing expressions, and build a graph from that.

There is just not use for such a thing. Programs already require us to jump
backwards and forwards to understand the flow due to the presence of functiond
definitions, and looping constructs; we don't need that at the statement level.

mlet allows any order because that's a side effect of handling the mutually
referencing lazy definitions, not because that's the motivating use case.
>
>   const x = y + 1,
>         y = z + 1,
>         z = x + 1
>
> then it is the compiler that reports a circular reference.
>
> Otherwise, in my dynamic (and non-lazy) language, circular references 
> are allowed at runtime, but it is object references rather than names:
>
>     a ::= (1,2,3)   # create two short lists (::= makes a mutable copy)
>     b ::= (4,5,6)
>
>     a &:= b         # append each to the other (concatenate is
>     b &:= a         # well-behaved)

So, if you had a category of list cells that are lazy, you could
bring about this circularity without ever perpetrating a mutating
assignment. (Because it's hidden in the implementation: when the lazy
cell is accessed, its fields are de facto assigned then, but in the abstract
semantics, it's understood as not being initialized.)

  1> (let (a b)
       (set a (lcons 1 b))
       (set b (lcons 0 a))
       (take 20 a))
  (1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0)

Here we still have assignments to bring about the circularity, but the
assignments are just of lexical variables, not of the list structure.

The mlet solves the problem of hiding the variable assignments,
in its own way.

There is a cheaper way to solve the problem for the above case;
we can have a "letrec" construct (similar to what exists in Scheme) which
literally does what we did above; i.e. one which takes:

  (letrec ((a (lcons 1 b))
           (b (lcons 0 a))
    ...body...)

and writes, effectively, this code:

  (let (a b)
    (set a (lcons 1 b))
    (set b (lcons 0 a))
    ...body...)

that is to say, the initializing forms have all the variables in scope, and are
evaluated from left to right. An earlier initform evaluating a later variable
will see a nil value. But here the lcons forms are lazy, and so do not evaluate
the variables.  In other words, we don't need the laziness of mlet; lcons is
enough.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web