From: anton@mips.complang.tuwien.ac.at
Hans Bezemer writes:
>On 16-04-2025 23:26, Anton Ertl wrote:
>> OTOH, Forth is worse suited to deal with dial-your-language-version
>> options: C uses separate compilation, so if the main program uses some
>> version of the standard, and a library uses a different version,
>> that's typically no problem, because they are both compiled with
>> different compiler calls (which may have different options).
>>
>> Forth, OTOH, compiles all the sources in one compilation run, and any
>> choices you dial at one point tend to affect all the rest of the
>> compilation, even if it compiles some independently developed library.
>> One could dream up ways to deal with that problem, but given past
>> experience, I doubt such ideas would find enough support; some would
>> call that "WIBNI"s, while others would point out that Chuck Moore did
>> not bring these ideas down from the mountain.
>>
>> - anton
>
>I don't think so. Using K&R prototypes is significantly different from
>ANSI prototypes. That must have broken quite some code - unless specific
>measures were taken to allow "old format" codes as well.
They certainly were, and still are. E.g, for the following function
definition in pre-C89 style:
foo(x)
int x;
{
return bar(x);
}
gcc-12 produces some warnings:
xxx.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | foo(x)
| ^~~
xxx.c: In function ‘foo’:
xxx.c:4:10: warning: implicit declaration of function ‘bar’
-Wimplicit-function-declaration]
4 | return bar(x);
| ^~~
but it compiles the code. In the old times the calling conventions
were designed to work for undeclared functions, so the compiled code
also worked. Things like the I32LP64 mistake and newer calling
conventions were designed for programs with fully-blown prototypes, so
on newer platforms some of the old code does not work (in particular,
when passing a double or an undeclared pointer), but that's the choice
of the implementors, not due to the C standard introducing an
incompatible requirement.
>restrict,
>nullptr, inline, bool - the list of added keywords is endless.
The number of keywords is finite (to be exact, C23 has 59 keywords,
including 5 obsolescent keywords), which means that the number of
added keywords is finite, too.
>BTW, so
>is the list of deprecated keywords, like "_Bool" with was replaced by
>the far less ugly "bool" in 2023.
The number of obsolescent keywords in C23 is 5. Endless?
>And I don't think the argument that "Forth compiles in one go" holds up
>as an argument to avoid cleaning up historical clutter. The different
>versions of a "keyword" could be created as their names, followed by a
>postfix of the standard, e.g. DO_79, DO_82, DO_94. Let's call 'em
>"version words".
There are no keywords in Forth, which makes changes less problematic
than in C. And names can be redefined in Forth, which also makes
changes less problematic.
As for introducing changes that are so disruptive that you would then
need dial-your-standard features to provide backwards compatibility
(e.g., stuff like the Forth-83 disruptions to Forth-79, e.g., the
changes to NOT and PICK), yes, one could propose technical workarounds
for that. It's just that the Forth community and the Forth-200x will
not find a consensus for taking such measures.
E.g., consider requiring the text interpreter of Forth systems to
treat 1.0 as FP value; currently this is not standardized, but common
practice (gforth, iForth, lxf, SwiftForth, VFX) is to treat it as
equivalent to 10., i.e., a double-cell integer.
One way to keep backwards compatibility with the current common
practice would be to require having a word FORTH-2030-FP-SYNTAX (or
maybe just FORTH-2030) in every file that uses the new FP syntax
before the use of that syntax. If that word does not appear in that
file, "1.0" would still be non-standardized.
Next: "1.". If we had such declarations, we could even support "1."
(standardized as double-cell in Forth-94 and Forth-2012) as FP number.
The alternative would be to treat "1." as double-cell and 1.0 as FP
value, which IMO is even worse than requiring an "e" in every FP
value.
But back to the dial-a-standard things: I have never seen such a
proposal that limits the dialing to one file. Instead, the proposals
and existing practice is to dial for the rest of text interpretation
(or until somthing else is dialed). That would mean that previously
working files might no longer work when included after dialing the new
FP syntax. E.g., all versions of the recognizer proposal have been
along these lines, and Bernd Paysan has actually proposed allowing to
treat "1." as FP value by swapping the integer and FP recognizer in
the recognizer order, which would have exactly this effect. And Bernd
Paysan is not the only one: Among other dialing features that all are
not limited to the file, VFX supports disabling the recognition of
"1." as double, which then leads to its recognition as FP number; but
that disabling is not limited to a file, but extends to the rest of
the text interpretation.
Here's the example for VFX:
',' dp-char 1+ c! ok
1. ok F:-1
f. 1. ok
So you could try to propose a word like FORTH-2030-FP-SYNTAX, but I
expect that the reactions would be along the following lines (in the
community and in the standardization committee):
1) A number of people consider this completely unnecessary, and
actually heretical, because Chuck Moore came down from the mountain
with doubles, not floats, so that's the way it was always meant to
be. Some would argue that treating "1.0" or "1." as FP number is
proposed just to cater to C programmers, and that Forthers should
take pride in deviating from the beaten path.
2) A number of people would argue against the limitation to a specific
file because of "complexity" (meaning implementation complexity),
"WIBNI", or because Chuck Moore came down from the mountain without
that idea, and that Chuck Moore has argued against libraries, that
he has argued against saving and restoring state, and instead has
argued for always setting it. And that the common practice (e.g.,
in VFX) is to just set the state, and never
3) And if you changed your proposal to just affect the rest of text
interpretation (and include another word FORTH-2012-FP-SYNTAX or
somesuch to switch back), some people (including me) would argue
that this variant of FORTH-2030-FP-SYNTAX would break existing
code, and that introducing FORTH-2012-FP-SYNTAX is a poor and
error-prone substitute for defining FORTH-2030-FP-SYNTAX properly.
Word counters would dislike this variant because it introduces an
[continued in next message]
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
