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

Groups > comp.lang.forth > #134167 > unrolled thread

0 vs. translate-none

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

Contents

  0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-17 16:53 +0000
    Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-19 12:24 +0200
      Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-19 15:45 +0000
        Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-19 19:39 +0200
          Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-20 07:25 +0000
            Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-20 10:34 +0200
              Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-20 16:08 +0000
                Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-20 19:08 +0200
                  Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-20 17:57 +0000
                    Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-20 20:55 +0200
                      Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-21 12:33 +0000
                        Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-21 18:39 +0200
                          Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-23 17:25 +0000
                            Re: 0 vs. translate-none peter <peter.noreply@tin.it> - 2025-09-23 22:25 +0200
                              Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-24 01:15 +0200
                              Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-24 06:26 +0000
              Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-21 10:37 +0200
                Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-21 13:56 +0200
                  Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-21 14:44 +0200
                    Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-21 17:46 +0200
                  Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-23 17:23 +0000
                    Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-23 22:38 +0200
                      Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-24 06:38 +0000
                        Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-24 09:39 +0200
                        Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-24 10:28 +0200
                          Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-24 10:44 +0200
                        Re: 0 vs. translate-none minforth <minforth@gmx.net> - 2025-09-24 10:36 +0200
                Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-21 12:50 +0000
                  Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-21 21:39 +0200
                    Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-22 06:56 +0000
                      Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-22 10:09 +0200
                        Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-22 08:39 +0000
                          Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-22 23:03 +0200
                            Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-23 17:00 +0000
                              Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-24 00:41 +0200
                                Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-24 13:57 +1000
                                Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-24 06:45 +0000
                                  Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-25 15:22 +1000
                                    Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-25 06:36 +0000
                                      Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-25 13:00 +0200
                                        Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-29 05:54 +0000
                                          Re: 0 vs. translate-none albert@spenarnc.xs4all.nl - 2025-09-29 11:03 +0200
                                            Re: 0 vs. translate-none anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-09-29 16:27 +0000
                                      Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-26 10:56 +1000
                                    Re: 0 vs. translate-none Hans Bezemer <the.beez.speaks@gmail.com> - 2025-09-26 17:09 +0200
                                      Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-09-29 00:42 +1000
                                        Re: 0 vs. translate-none Hans Bezemer <the.beez.speaks@gmail.com> - 2025-09-30 18:15 +0200
                                          Re: 0 vs. translate-none dxf <dxforth@gmail.com> - 2025-10-01 14:10 +1000
                                            Re: 0 vs. translate-none Hans Bezemer <the.beez.speaks@gmail.com> - 2025-10-02 15:48 +0200
    Re: 0 vs. translate-none Ruvim <ruvim.pinka@gmail.com> - 2025-09-26 02:19 +0400
      Re: 0 vs. translate-none Ruvim <ruvim.pinka@gmail.com> - 2025-09-27 13:43 +0400

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

#134193

minforth <minforth@gmx.net> writes:
>FWIW I also use suffixes for recognizers:
>let M be a matrix
>M´  auto-transposed
>M~  auto-inverted

Can you give an example of a matrix with your matrix recognizer?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134196

Am 23.09.2025 um 19:23 schrieb Anton Ertl:
> minforth <minforth@gmx.net> writes:
>> FWIW I also use suffixes for recognizers:
>> let M be a matrix
>> M´  auto-transposed
>> M~  auto-inverted
> 
> Can you give an example of a matrix with your matrix recognizer?
> 

To be fair, here MinForth displays the matrix/vector stack in the
QUIT prompt:

MinForth 3.6 (64 bit) (fp matrix)
# 0 0 matrix mat  ok
# m[ 1 2 3 ; 4 5 6 ]  ok
M: <1>
[ 1 2 3 ; 4 5 6 ]
# to mat  ok
# mat'  ok
M: <1>
[ 1 4 ; 2 5 ; 3 6 ]
# m[ 1 2 3 ; 4 5 6 ; 4 3 -2 ] := mat  ok
M: <1>
[ 1 4 ; 2 5 ; 3 6 ]
# mat~  ok
M: <2>
[ -2.333333 1.083333 -0.25 ; 2.666667 -1.166667 0.5 ; -0.6666667 
0.4166667 -0.25 ]
[ 1 4 ; 2 5 ; 3 6 ]
# m.
[ -2.33333 1.08333 -0.25
   2.66667 -1.16667 0.5
   -0.666667 0.416667 -0.25 ] ok
M: <1>
[ 1 4 ; 2 5 ; 3 6 ]
#

The implementation won't help you at all because I use my own 
recognisers. Tt's an eye sore ;-)

\ ------ Matrix/Vector Indexing ------

\ Syntax: <name>( for positional indexing
D: _[MVAL] i" mfmx=(mfMx*)mfpop(), mfmd=mfpop();" ;
D: _MVAL   [,] depth i" mfpush(mfmx);" [,] literal [,] _[mval] ;

\ Syntax: <name>^ for heap addressing
: _MVAL^   i" mfpush(mfmx->dat);" ;
: _[MVAL^] _mval^ [,] literal ;

\ Syntax: <name>' for implicit transposing
: _MVAL'   i" mfmup, mfm_set(mfmtos,mfmx), mfm_trans(mfmtos);" ;
: _[MVAL'] _mval [,] _mval' ;

\ Syntax: <name>~ for implicit inversion
: _MVAL~   i" mfmup, mfm_set(mfmtos,mfmx), mfm_inv(mfmtos);" ;
: _[MVAL`] _mval [,] _mval~ ;

: __MXLITERAL?  \ ( -- .. t | f ) recognize different matrix calls
    _parsed 2@ 1- _find-word IF dup cell+ @ _vmxmethods = IF
C  mfmx=(mfMx*)((mfpop())+2*MFSIZE), mfmd=mfsp-mfstk;
    _parsed 2@ 1- + c@
    dup '(' = IF drop ['] noop   ['] _mval    true EXIT THEN
    dup '^' = IF drop ['] _mval^ ['] _[mval^] true EXIT THEN
    dup ''' = IF drop ['] _mval' ['] _[mval'] true EXIT THEN
        '~' = IF      ['] _mval~ ['] _[mval~] true EXIT THEN
    ELSE drop THEN THEN deferred _literal? ;
IS _LITERAL?

\ ------

_LITERAL? is a deferrable element in the recognizer chain which
is called in the INTERPRET loop (it is also used to recognize
floats and complex numbers).

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

#134201

minforth <minforth@gmx.net> writes:
>Am 23.09.2025 um 19:23 schrieb Anton Ertl:
>> minforth <minforth@gmx.net> writes:
>>> FWIW I also use suffixes for recognizers:
>>> let M be a matrix
>>> M´  auto-transposed
>>> M~  auto-inverted
>> 
>> Can you give an example of a matrix with your matrix recognizer?
>> 
>
>To be fair, here MinForth displays the matrix/vector stack in the
>QUIT prompt:
>
>MinForth 3.6 (64 bit) (fp matrix)
># 0 0 matrix mat  ok
># m[ 1 2 3 ; 4 5 6 ]  ok

Given this syntax, a parsing word M[ suggests itself to me (although I
generally dislike parsing words and probably would choose a different
syntax); or maybe a word that switches to a matrix interpreter
(possibly implemented using the recognizer words, with ] switching
back.  Why did you choose to use a recognizer?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134203

Am 24.09.2025 um 08:38 schrieb Anton Ertl:
> minforth <minforth@gmx.net> writes:
>> Am 23.09.2025 um 19:23 schrieb Anton Ertl:
>>> minforth <minforth@gmx.net> writes:
>>>> FWIW I also use suffixes for recognizers:
>>>> let M be a matrix
>>>> M´  auto-transposed
>>>> M~  auto-inverted
>>>
>>> Can you give an example of a matrix with your matrix recognizer?
>>>
>>
>> To be fair, here MinForth displays the matrix/vector stack in the
>> QUIT prompt:
>>
>> MinForth 3.6 (64 bit) (fp matrix)
>> # 0 0 matrix mat  ok
>> # m[ 1 2 3 ; 4 5 6 ]  ok
> 
> Given this syntax, a parsing word M[ suggests itself to me (although I
> generally dislike parsing words and probably would choose a different
> syntax); or maybe a word that switches to a matrix interpreter
> (possibly implemented using the recognizer words, with ] switching
> back.  Why did you choose to use a recognizer?

I use MARKER to unload libraries when they have served their purpose.
MARKER also resets the recognizer chain.

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

#134204

In article <2025Sep24.083826@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>minforth <minforth@gmx.net> writes:
>>Am 23.09.2025 um 19:23 schrieb Anton Ertl:
>>> minforth <minforth@gmx.net> writes:
>>>> FWIW I also use suffixes for recognizers:
>>>> let M be a matrix
>>>> M´  auto-transposed
>>>> M~  auto-inverted
>>>
>>> Can you give an example of a matrix with your matrix recognizer?
>>>
>>
>>To be fair, here MinForth displays the matrix/vector stack in the
>>QUIT prompt:
>>
>>MinForth 3.6 (64 bit) (fp matrix)
>># 0 0 matrix mat  ok
>># m[ 1 2 3 ; 4 5 6 ]  ok
>
>Given this syntax, a parsing word M[ suggests itself to me (although I
>generally dislike parsing words and probably would choose a different
>syntax); or maybe a word that switches to a matrix interpreter
>(possibly implemented using the recognizer words, with ] switching
>back.  Why did you choose to use a recognizer?

WORDLIST suggest a different solution with a wordlist MATRIX
MAT( adds MATRIX to the search order
)MAT removes MATRIX from the search order

Circumstances may prevent this, but I think that is the situation
where wordlists are intended for, create a different interpretation/compile
environment.

>
>- anton

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134206

Am 24.09.2025 um 10:28 schrieb albert@spenarnc.xs4all.nl:
> In article <2025Sep24.083826@mips.complang.tuwien.ac.at>,
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> minforth <minforth@gmx.net> writes:
>>> Am 23.09.2025 um 19:23 schrieb Anton Ertl:
>>>> minforth <minforth@gmx.net> writes:
>>>>> FWIW I also use suffixes for recognizers:
>>>>> let M be a matrix
>>>>> M´  auto-transposed
>>>>> M~  auto-inverted
>>>>
>>>> Can you give an example of a matrix with your matrix recognizer?
>>>>
>>>
>>> To be fair, here MinForth displays the matrix/vector stack in the
>>> QUIT prompt:
>>>
>>> MinForth 3.6 (64 bit) (fp matrix)
>>> # 0 0 matrix mat  ok
>>> # m[ 1 2 3 ; 4 5 6 ]  ok
>>
>> Given this syntax, a parsing word M[ suggests itself to me (although I
>> generally dislike parsing words and probably would choose a different
>> syntax); or maybe a word that switches to a matrix interpreter
>> (possibly implemented using the recognizer words, with ] switching
>> back.  Why did you choose to use a recognizer?
> 
> WORDLIST suggest a different solution with a wordlist MATRIX
> MAT( adds MATRIX to the search order
> )MAT removes MATRIX from the search order
> 
> Circumstances may prevent this, but I think that is the situation
> where wordlists are intended for, create a different interpretation/compile
> environment.
In principle yes, but wordlists don't hook themselves into the Forth 
interpreter. IMO this is the only novelty of recognizers.

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

#134205

Am 24.09.2025 um 08:38 schrieb Anton Ertl:
> minforth <minforth@gmx.net> writes:
>> Am 23.09.2025 um 19:23 schrieb Anton Ertl:
>>> minforth <minforth@gmx.net> writes:
>>>> FWIW I also use suffixes for recognizers:
>>>> let M be a matrix
>>>> M´  auto-transposed
>>>> M~  auto-inverted
>>>
>>> Can you give an example of a matrix with your matrix recognizer?
>>>
>>
>> To be fair, here MinForth displays the matrix/vector stack in the
>> QUIT prompt:
>>
>> MinForth 3.6 (64 bit) (fp matrix)
>> # 0 0 matrix mat  ok
>> # m[ 1 2 3 ; 4 5 6 ]  ok
> 
> Given this syntax, a parsing word M[ suggests itself to me (although I
> generally dislike parsing words and probably would choose a different
> syntax); or maybe a word that switches to a matrix interpreter
> (possibly implemented using the recognizer words, with ] switching
> back.  Why did you choose to use a recognizer?

M[ ... pushes a matrix literal onto the matrix stack.
MATRIX (or VECTOR) define a persistent matrix/vector value.

M[ is not really parsing, it just sets a flag for the forth
interpreter. You could write
M[ 1 fdup ] instead of M[ 1 1 ] or M[ 1. 1. ] or M[ 1e 1e ]

IOW M[ does not use a recognizer.

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

#134184

albert@spenarnc.xs4all.nl writes:
>It is believable that the system presented above is more powerful,
>but I love to see examples what it can do that warrant the
>complexity. Also I love to see if the examples can't be
>done with my simpler setup.
>Recently I presented the Roman number prefix. How does
>that look in the recognizer presented.

I have already presented a recognizer for roman numerals in
<2025Jun8.183524@mips.complang.tuwien.ac.at>, along with .ROMAN in
<2025Jun9.082338@mips.complang.tuwien.ac.at> and variations on
ROMAN>N? used for the recognizer in
<2025Jun9.091538@mips.complang.tuwien.ac.at>.  The examples are:

MCMXLVIII .               \ 1948
mcmxlviii .               \ error: undefined word
MIM                       \ error: undefined word
L .                       \ 50
LLL                       \ error: undefined word
MCMXLVIII LXXVII + .      \ 2025
MCMXLVIII LXXVII + .roman \ MMXXV

Unlike your approach, one can write roman numerals in the same way
that we learned in school.  Does it warrant the complexity?  I think
that already the benefit of not having to FIND-NAME for all prefixes
of a word we search for is a good reason to avoid your approach.

The interface to the recognizer proposal has seen some renaming and
other changes in the recent committee meeting, and you find the
updated code for recognizing and printing roman numerals in:

https://www.complang.tuwien.ac.at/forth/programs/roman-numerals.4th

The recognizer stuff conforms with the recent proposal, the rest of
the code uses Gforth extensions.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134187

In article <2025Sep21.145014@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Unlike your approach, one can write roman numerals in the same way
>that we learned in school.

I think that it is good that the roman numerals are distinguished.
VI M L X become suddenly reserved words. There is a reason that we
prefer $CD and $DEADBEEF. If I drop the requirement of a uniform
prefix, I can simplify my approach too.
On the other hand you are certainly able to prefix the roman numerals
if you wish with recognizers. So there is not much difference.

>Does it warrant the complexity?  I think
>that already the benefit of not having to FIND-NAME for all prefixes
>of a word we search for is a good reason to avoid your approach.

That is probably a misunderstanding of my approach.
I understand that in your recognizer system all recognizers are tried
in succession.
Using a prefix like 0x for hex, the lookup for 0x is the same
as the lookup for  `` 1 CONSTANT 0x '' , so no separate mechanism is
needed.
Only after the word is found, a prefix is handled differently, compare
immediate words. Such lookup is probably even less effort.

Assume we have a PREFIX $ for hex.
Think of a unix environment, where $ is used for environment variables
and we want 0x for hex.

NAMESPACE unix  \ That is VOCABULARY with a built-in ALSO
unix DEFINITIONS
' $ ALIAS 0x

\ Warning: is not unique.
: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ;  IMMEDIATE PREFIX

...
...
PREVIOUS DEFINITIONS
As soon as you kick unix out of the search order, $ is again the
prefix for hex and 0xCD is no more recognized.
In my opinion, using the regular search order for prefixes is
probably an advantage.

P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that
$XXXX can be used in compilation mode.

>The interface to the recognizer proposal has seen some renaming and
>other changes in the recent committee meeting, and you find the
>updated code for recognizing and printing roman numerals in:
>
>https://www.complang.tuwien.ac.at/forth/programs/roman-numerals.4th
>
>The recognizer stuff conforms with the recent proposal, the rest of
>the code uses Gforth extensions.
>
>- anton

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134188

albert@spenarnc.xs4all.nl writes:
>In article <2025Sep21.145014@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Unlike your approach, one can write roman numerals in the same way
>>that we learned in school.
>
>I think that it is good that the roman numerals are distinguished.
>VI M L X become suddenly reserved words.

No, they become numbers. However, vi Vi vI m l x are not recognized as
numbers, and you can use them to invoke the word.  In Gforth, you can
also use

roman?L
name?L

to distinguish them.

>There is a reason that we
>prefer $CD and $DEADBEEF.

Yes, the number prefixes have advantages when writing programs.  I
don't think I am going to be writing programs with roman numerals.

>>Does it warrant the complexity?  I think
>>that already the benefit of not having to FIND-NAME for all prefixes
>>of a word we search for is a good reason to avoid your approach.
>
>That is probably a misunderstanding of my approach.
>I understand that in your recognizer system all recognizers are tried
>in succession.
>Using a prefix like 0x for hex, the lookup for 0x is the same
>as the lookup for  `` 1 CONSTANT 0x '' , so no separate mechanism is
>needed.
>Only after the word is found, a prefix is handled differently, compare
>immediate words. Such lookup is probably even less effort.

My understaning is that if the user types

123456789

into the text interpreter, your text interpreter will search for

123456789
12345678
1234567
123456
12345
1234
123
12
1

and fail at the first 8 attempts, and finally match the ninth, and
only then try to convert the string into a number.  By contrast, with
recognizers, every recognizer (including REC-NAME) only has to deal
with the full string, and most other recognizers have simpler and
cheaper checks than REC-NAME.

>Assume we have a PREFIX $ for hex.
>Think of a unix environment, where $ is used for environment variables
>and we want 0x for hex.
>
>NAMESPACE unix  \ That is VOCABULARY with a built-in ALSO
>unix DEFINITIONS
>' $ ALIAS 0x
>
>\ Warning: is not unique.
>: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ;  IMMEDIATE PREFIX
>
>...
>...
>PREVIOUS DEFINITIONS
>As soon as you kick unix out of the search order, $ is again the
>prefix for hex and 0xCD is no more recognized.

Gforth has REC-ENV and that is active by default, and there is usually
no reason to eliminate it from the system recognizer sequence.  You
write ${HOME}.

>P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that
>$XXXX can be used in compilation mode.

It seems that your approach embraces state-smartness.  By contrast,
one benefit of recognizers is that they make it unnecessary to use
words like S" or TO that often are implemented as state-smart words,
or require unconventional mechanisms to avoid that.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134189

In article <2025Sep22.085631@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>
>>Only after the word is found, a prefix is handled differently, compare
>>immediate words. Such lookup is probably even less effort.
>
>My understaning is that if the user types
>
>123456789
>
>into the text interpreter, your text interpreter will search for
>
>123456789
>12345678
>1234567
>123456
>12345
>1234
>123
>12
>1
>
>and fail at the first 8 attempts, and finally match the ninth, and
>only then try to convert the string into a number.  By contrast, with
>recognizers, every recognizer (including REC-NAME) only has to deal
>with the full string, and most other recognizers have simpler and
>cheaper checks than REC-NAME.

No. 123456789 is looked up in the Forth wordlist, fails, then in the
minimum search wordlist.

'   &   ^   0   1   2   3   4   5   6   7
8   9   -   +   "   FORTH

1234556789 matches the prefix 1. Then 1 does its thing,
recognizes the number, and decides to leave it on the stack or
compile code for it. Isn't that smart? (or is it the way Forth
works from day one?)

>
>>Assume we have a PREFIX $ for hex.
>>Think of a unix environment, where $ is used for environment variables
>>and we want 0x for hex.
>>
>>NAMESPACE unix  \ That is VOCABULARY with a built-in ALSO
>>unix DEFINITIONS
>>' $ ALIAS 0x
>>
>>\ Warning: is not unique.
>>: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ;  IMMEDIATE PREFIX
>>
>>...
>>...
>>PREVIOUS DEFINITIONS
>>As soon as you kick unix out of the search order, $ is again the
>>prefix for hex and 0xCD is no more recognized.
>
>Gforth has REC-ENV and that is active by default, and there is usually
>no reason to eliminate it from the system recognizer sequence.  You
>write ${HOME}.

Does that invalidate the example?

>
>>P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that
>>$XXXX can be used in compilation mode.
>
>It seems that your approach embraces state-smartness.  By contrast,
>one benefit of recognizers is that they make it unnecessary to use
>words like S" or TO that often are implemented as state-smart words,
>or require unconventional mechanisms to avoid that.

No I don't. Numbers have always been state-smart, although you
won't admit to it.
In my system you can't postpone numbers, so that cannot lead to
problems. "AAP" is recognized but
POSTPONE "AAP"
POSTPONE 12345
is rejected.
So "AAP" is a generalised number and share the property that it
may be state-smart but like numbers there are no evil consequences.
Not by clever planning, but by sound design.

P.S. I don't intend to present or defend PREFIX as an alternative to
the recognizer proposals, but it is more sound than people think.
Also it is lean, so advantageous for vintage systems.

>
>- anton

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134190

albert@spenarnc.xs4all.nl writes:
>In article <2025Sep22.085631@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
><SNIP>
>>>Only after the word is found, a prefix is handled differently, compare
>>>immediate words. Such lookup is probably even less effort.
>>
>>My understaning is that if the user types
>>
>>123456789
>>
>>into the text interpreter, your text interpreter will search for
>>
>>123456789
>>12345678
>>1234567
>>123456
>>12345
>>1234
>>123
>>12
>>1
>>
>>and fail at the first 8 attempts, and finally match the ninth, and
>>only then try to convert the string into a number.  By contrast, with
>>recognizers, every recognizer (including REC-NAME) only has to deal
>>with the full string, and most other recognizers have simpler and
>>cheaper checks than REC-NAME.
>
>No. 123456789 is looked up in the Forth wordlist, fails, then in the
>minimum search wordlist.
>
>'   &   ^   0   1   2   3   4   5   6   7
>8   9   -   +   "   FORTH
>
>1234556789 matches the prefix 1.

How so?  Linear search through the wordlist, with prefix matching?
That's even slower than the approach outlined above (when that
approach is implemented using hash tables).

And how does matching "0r" for your roman numerals work, if "0rM"
matches the prefix "0"?

>>>Assume we have a PREFIX $ for hex.
>>>Think of a unix environment, where $ is used for environment variables
>>>and we want 0x for hex.
>>>
>>>NAMESPACE unix  \ That is VOCABULARY with a built-in ALSO
>>>unix DEFINITIONS
>>>' $ ALIAS 0x
>>>
>>>\ Warning: is not unique.
>>>: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ;  IMMEDIATE PREFIX
>>>
>>>...
>>>...
>>>PREVIOUS DEFINITIONS
>>>As soon as you kick unix out of the search order, $ is again the
>>>prefix for hex and 0xCD is no more recognized.
>>
>>Gforth has REC-ENV and that is active by default, and there is usually
>>no reason to eliminate it from the system recognizer sequence.  You
>>write ${HOME}.
>
>Does that invalidate the example?

It means that we can mix standard syntax for hex numbers and
environment variables freely, without having to shadow one with the
other, or kicking one to be able to use the other.

>>>P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that
>>>$XXXX can be used in compilation mode.
>>
>>It seems that your approach embraces state-smartness.  By contrast,
>>one benefit of recognizers is that they make it unnecessary to use
>>words like S" or TO that often are implemented as state-smart words,
>>or require unconventional mechanisms to avoid that.
>
>No I don't. Numbers have always been state-smart, although you
>won't admit to it.

A state-smart 123 would behave like

: 123
  123 state @ if postpone literal then ; immediate

By contrast, a normal 123 behaves like

: 123
  123 ;

Here is a test

: p123 postpone 123 ; : test [ p123 ] ; test .

Let's see how it works (outputs are shown with preceding "\ "):

: 123 \ compiling 
  123 state @ if postpone literal then ; immediate 
\ *terminal*:2:40: warning: defined literal 123 as word ok
: p123 postpone 123 ; : test [ p123 ] ; test . 
\ *the terminal*:3:39: error: Control structure mismatch
\ : p123 postpone 123 ; : test [ p123 ] >>>;<<< test

Now with a freshly started system:

: 123 \ compiling 
  123 ; 
\ *terminal*:2:7: warning: defined literal 123 as word ok
: p123 postpone 123 ; : test [ p123 ] ; test . \ 123  ok

Now with a freshly started system:

: p123 postpone 123 ; : test [ p123 ] ; test . \ 123  ok

The last example uses REC-NUM to recognize 123.  It behaves like the
normal (not state-smart) word 123, showing that numbers are not
state-smart.

You may say that in a traditional system the last test will not work,
because POSTPONE does not work with numbers.  That's true, but not
proof of any state-smartness.  It just means that we have to look at
the implementation to decide it.  And in the traditional
implementation the text interpreter decides whether to perform the
interpretation or compilation semantics of a number, whereas in a
state-smart word, these two semantics are the same (immediate), and
the word itself decides when it is run what to do, based on STATE.  No
such thing happens with numbers, so they are not state-smart, not even
in a traditional system.

>In my system you can't postpone numbers, so that cannot lead to
>problems.

That is certainly a good idea if you have made the mistake of
embracing state-smartness in your system, but it is another
disadvantage of your approach compared to recognizers.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134191

In article <2025Sep22.103934@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
>>In article <2025Sep22.085631@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>><SNIP>
>>>>Only after the word is found, a prefix is handled differently, compare
>>>>immediate words. Such lookup is probably even less effort.
>>>
>>>My understaning is that if the user types
>>>
>>>123456789
>>>
>>>into the text interpreter, your text interpreter will search for
>>>
>>>123456789
>>>12345678
>>>1234567
>>>123456
>>>12345
>>>1234
>>>123
>>>12
>>>1
>>>
>>>and fail at the first 8 attempts, and finally match the ninth, and
>>>only then try to convert the string into a number.  By contrast, with
>>>recognizers, every recognizer (including REC-NAME) only has to deal
>>>with the full string, and most other recognizers have simpler and
>>>cheaper checks than REC-NAME.
>>
>>No. 123456789 is looked up in the Forth wordlist, fails, then in the
>>minimum search wordlist.
>>
>>'   &   ^   0   1   2   3   4   5   6   7
>>8   9   -   +   "   FORTH
>>
>>1234556789 matches the prefix 1.
>
>How so?  Linear search through the wordlist, with prefix matching?
>That's even slower than the approach outlined above (when that
>approach is implemented using hash tables).

I use a simple Forth and there linear search is acceptable for me.

>
>And how does matching "0r" for your roman numerals work, if "0rM"
>matches the prefix "0"?

Normal precedence rules for Forth. 0r is later defined so it is
probed earlier.

>
>>>>Assume we have a PREFIX $ for hex.
>>>>Think of a unix environment, where $ is used for environment variables
>>>>and we want 0x for hex.
>>>>
>>>>NAMESPACE unix  \ That is VOCABULARY with a built-in ALSO
>>>>unix DEFINITIONS
>>>>' $ ALIAS 0x
>>>>
>>>>\ Warning: is not unique.
>>>>: $ PARSE-NAME GET-ENV POSTPONE DLITERAL ;  IMMEDIATE PREFIX
>>>>
>>>>...
>>>>...
>>>>PREVIOUS DEFINITIONS
>>>>As soon as you kick unix out of the search order, $ is again the
>>>>prefix for hex and 0xCD is no more recognized.
>>>
>>>Gforth has REC-ENV and that is active by default, and there is usually
>>>no reason to eliminate it from the system recognizer sequence.  You
>>>write ${HOME}.
>>
>>Does that invalidate the example?
>
>It means that we can mix standard syntax for hex numbers and
>environment variables freely, without having to shadow one with the
>other, or kicking one to be able to use the other.

>
>>>>P.S. GET-ENV leaves a double. Adding POSTPONE DLITERAL makes that
>>>>$XXXX can be used in compilation mode.
>>>
>>>It seems that your approach embraces state-smartness.  By contrast,
>>>one benefit of recognizers is that they make it unnecessary to use
>>>words like S" or TO that often are implemented as state-smart words,
>>>or require unconventional mechanisms to avoid that.
>>
>>No I don't. Numbers have always been state-smart, although you
>>won't admit to it.
>
>A state-smart 123 would behave like
>
>: 123
>  123 state @ if postpone literal then ; immediate
>
>By contrast, a normal 123 behaves like
>
>: 123
>  123 ;
>
>Here is a test
>
>: p123 postpone 123 ; : test [ p123 ] ; test .
>
>Let's see how it works (outputs are shown with preceding "\ "):
>
>: 123 \ compiling
>  123 state @ if postpone literal then ; immediate
>\ *terminal*:2:40: warning: defined literal 123 as word ok
>: p123 postpone 123 ; : test [ p123 ] ; test .
>\ *the terminal*:3:39: error: Control structure mismatch
>\ : p123 postpone 123 ; : test [ p123 ] >>>;<<< test
>
>Now with a freshly started system:
>
>: 123 \ compiling
>  123 ;
>\ *terminal*:2:7: warning: defined literal 123 as word ok
>: p123 postpone 123 ; : test [ p123 ] ; test . \ 123  ok
>
>Now with a freshly started system:
>
>: p123 postpone 123 ; : test [ p123 ] ; test . \ 123  ok
>
>The last example uses REC-NUM to recognize 123.  It behaves like the
>normal (not state-smart) word 123, showing that numbers are not
>state-smart.
>
>You may say that in a traditional system the last test will not work,
>because POSTPONE does not work with numbers.  That's true, but not
>proof of any state-smartness.  It just means that we have to look at
>the implementation to decide it.  And in the traditional
>implementation the text interpreter decides whether to perform the
>interpretation or compilation semantics of a number, whereas in a
>state-smart word, these two semantics are the same (immediate), and
>the word itself decides when it is run what to do, based on STATE.  No
>such thing happens with numbers, so they are not state-smart, not even
>in a traditional system.

You have tried to explain this to me several times, but this is the clearest.

I terminate denotation words with [COMPILE] LITERAL or [COMPILE] DLITERAL.
Suppose I change it to a system where INTERPRET checks whether an
immediate word left something on the stack ( assuming a separate
compilation check) and only in compilation mode adds a LITERAL
(compiles LIT and the number).
In that case denotations doesn't end with [COMPILE] LITERAL/DLITERAL.
Would that be an acceptable implementation?

>
>>In my system you can't postpone numbers, so that cannot lead to
>>problems.
>
>That is certainly a good idea if you have made the mistake of
>embracing state-smartness in your system, but it is another
>disadvantage of your approach compared to recognizers.

To end the controversy, maybe I have to admit I have smart numbers,
but I manage to be ISO-94 compliant.

"AAP"
 OK
 POSTPONE "AAP"
 POSTPONE "AAP" ? ciforth ERROR # 15 : CANNOT FIND WORD TO BE POSTPONED

Maybe not ISO-2012 compliant.

>
>- anton

Groetjes Albert
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134192

albert@spenarnc.xs4all.nl writes:
>In article <2025Sep22.103934@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@spenarnc.xs4all.nl writes:
>>>1234556789 matches the prefix 1.
>>
>>How so?  Linear search through the wordlist, with prefix matching?
>>That's even slower than the approach outlined above (when that
>>approach is implemented using hash tables).
>
>I use a simple Forth and there linear search is acceptable for me.

That's fine for you, but some of us compile substantial programs
and/or use lots of lookups in wordlists at run time, and therefore
need dictionary search to be fast.

>>And how does matching "0r" for your roman numerals work, if "0rM"
>>matches the prefix "0"?
>
>Normal precedence rules for Forth. 0r is later defined so it is
>probed earlier.

So defining a prefix "0r" shadows all earlier-defined words starting
with "0r"?  One has to choose the prefixes well, but the same is true
for what recognizers should recognize.

>>You may say that in a traditional system the last test will not work,
>>because POSTPONE does not work with numbers.  That's true, but not
>>proof of any state-smartness.  It just means that we have to look at
>>the implementation to decide it.  And in the traditional
>>implementation the text interpreter decides whether to perform the
>>interpretation or compilation semantics of a number, whereas in a
>>state-smart word, these two semantics are the same (immediate), and
>>the word itself decides when it is run what to do, based on STATE.  No
>>such thing happens with numbers, so they are not state-smart, not even
>>in a traditional system.
>
>You have tried to explain this to me several times, but this is the clearest.
>
>I terminate denotation words with [COMPILE] LITERAL or [COMPILE] DLITERAL.
>Suppose I change it to a system where INTERPRET checks whether an
>immediate word left something on the stack ( assuming a separate
>compilation check) and only in compilation mode adds a LITERAL
>(compiles LIT and the number).
>In that case denotations doesn't end with [COMPILE] LITERAL/DLITERAL.
>Would that be an acceptable implementation?

Given that you make it impossible to use the prefixes in a way where
the problems with state-smartness show up (by disallowing to tick or
postpone the prefixed words), even a state-smart implementation is
acceptable.

However, LITERAL is a standard word that a conforming implementation
cannot implement in a state-smart way.

: lit, postpone literal ;
: foo [ 1 lit, ] ;
foo . \ 1

(Gforth, iForth, SwiftForth64, and VFX64 process this example correctly).

>To end the controversy, maybe I have to admit I have smart numbers,
>but I manage to be ISO-94 compliant.
>
>"AAP"
> OK
> POSTPONE "AAP"
> POSTPONE "AAP" ? ciforth ERROR # 15 : CANNOT FIND WORD TO BE POSTPONED
>
>Maybe not ISO-2012 compliant.

Forth-2012 does not include recognizers, much less a string
recognizer.  And the result of the recent meeting is that the proposal
does not include a string recognizer, either (but it provides words
that allow one to add a string recognizer).  BTW, Forth-2012 is not an
ISO standard.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134197

In article <2025Sep23.190034@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl writes:
>>In article <2025Sep22.103934@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>albert@spenarnc.xs4all.nl writes:

>So defining a prefix "0r" shadows all earlier-defined words starting
>with "0r"?  One has to choose the prefixes well, but the same is true
>for what recognizers should recognize.

A more realistic example is $ for hex numbers. A sensible implementation
is to define that in the minimum search order, such that words added to
Forth itself can start with $ e.g. $= to compare two strings.

<SNIP>

>
>However, LITERAL is a standard word that a conforming implementation
>cannot implement in a state-smart way.
>
>: lit, postpone literal ;
>: foo [ 1 lit, ] ;
>foo . \ 1

This shows me how to Lift this defect. Rename LITERAL to (LIT) and
define
: LITERAL 'LIT , , ;  IMMEDIATE
Then the above test succeeds.
The interpretation syntax of LITERAL is undefined.
LIT, is a sneaky way to have an interpretation syntax.
Normal is
   : foo [ 1 ] LITERAL ;

In the standard:
LITERAL :
Interpretation: Interpretation syntax for this word is undefined.

What if the standard says
   execution of this word while in interpret mode is an ambiguous condition

then I would gladly throw an exception if anybody tries it and the examples
wouldn't fly.

>
>(Gforth, iForth, SwiftForth64, and VFX64 process this example correctly).
>
>>To end the controversy, maybe I have to admit I have smart numbers,
>>but I manage to be ISO-94 compliant.

In view of the above, not yet.

>
>- anton
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

#134199

On 24/09/2025 8:41 am, albert@spenarnc.xs4all.nl wrote:
> In article <2025Sep23.190034@mips.complang.tuwien.ac.at>,
> ... 
>>
>> However, LITERAL is a standard word that a conforming implementation
>> cannot implement in a state-smart way.
>>
>> : lit, postpone literal ;
>> : foo [ 1 lit, ] ;
>> foo . \ 1
> 
> This shows me how to Lift this defect. Rename LITERAL to (LIT) and
> define
> : LITERAL 'LIT , , ;  IMMEDIATE
> Then the above test succeeds.
> The interpretation syntax of LITERAL is undefined.
> LIT, is a sneaky way to have an interpretation syntax.
> Normal is
>    : foo [ 1 ] LITERAL ;
> 
> In the standard:
> LITERAL :
> Interpretation: Interpretation syntax for this word is undefined.
> 
> What if the standard says
>    execution of this word while in interpret mode is an ambiguous condition
> 
> then I would gladly throw an exception if anybody tries it and the examples
> wouldn't fly.

Agreed.  But the loophole frequently argued by parties since Forth-94 is that
it was a 'minimum specification' supported by 'ambiguous conditions'.  The
latter ought not be seen as eternal damnation, rather the potential for more
heavenly rewards.

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

#134202

albert@spenarnc.xs4all.nl writes:
>This shows me how to Lift this defect. Rename LITERAL to (LIT) and
>define
>: LITERAL 'LIT , , ;  IMMEDIATE

Looks good.

>In the standard:
>LITERAL :
>Interpretation: Interpretation syntax for this word is undefined.

Has ISO changed the text?  Forth-94 and Forth-2012 say:

|Interpretation:
|Interpretation semantics for this word are undefined.

>What if the standard says
>   execution of this word while in interpret mode is an ambiguous condition

It does not, and that's a good thing.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134207

On 24/09/2025 4:45 pm, Anton Ertl wrote:
> albert@spenarnc.xs4all.nl writes:
>> This shows me how to Lift this defect. Rename LITERAL to (LIT) and
>> define
>> : LITERAL 'LIT , , ;  IMMEDIATE
> 
> Looks good.
> 
>> In the standard:
>> LITERAL :
>> Interpretation: Interpretation syntax for this word is undefined.
> 
> Has ISO changed the text?  Forth-94 and Forth-2012 say:
> 
> |Interpretation:
> |Interpretation semantics for this word are undefined.
> 
>> What if the standard says
>>   execution of this word while in interpret mode is an ambiguous condition
> 
> It does not, and that's a good thing.

"ambiguous condition:
A circumstance for which this Standard does not prescribe a specific behavior
for Forth systems and programs."

"undefined" and "not prescribe a specific behavior" seem much alike to me.
Either way, the Standard is saying don't do this thing.  It's not as if
they'd said nothing about it and left it up to you.

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

#134208

dxf <dxforth@gmail.com> writes:
>"ambiguous condition:
>A circumstance for which this Standard does not prescribe a specific behavior
>for Forth systems and programs."
>
>"undefined" and "not prescribe a specific behavior" seem much alike to me.
>Either way, the Standard is saying don't do this thing.

Not really.  The standard just does not specify what happens in this
case.

>It's not as if
>they'd said nothing about it and left it up to you.

It's exactly that.

As a programmer, if you know how the systems you are interested in
behave, you can make use of that knowledge; the program will then not
conform to the current standard, but still work as intended on these
systems.  In a standard based on common practice, that's the only
way to achieve progress.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: https://forth-standard.org/
EuroForth 2025 CFP: http://www.euroforth.org/ef25/cfp.html
EuroForth 2025 registration: https://euro.theforth.net/

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

#134209

In article <2025Sep25.083640@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>dxf <dxforth@gmail.com> writes:
>>"ambiguous condition:
>>A circumstance for which this Standard does not prescribe a specific behavior
>>for Forth systems and programs."
>>
>>"undefined" and "not prescribe a specific behavior" seem much alike to me.
>>Either way, the Standard is saying don't do this thing.
>
>Not really.  The standard just does not specify what happens in this
>case.
>
>>It's not as if
>>they'd said nothing about it and left it up to you.
>
>It's exactly that.
>
>As a programmer, if you know how the systems you are interested in
>behave, you can make use of that knowledge; the program will then not
>conform to the current standard, but still work as intended on these
>systems.  In a standard based on common practice, that's the only
>way to achieve progress.

That is for unsafe languages like Forth or Fortran. For Algol / Pascal
program' s behave the same for all systems, except for restrictions
due to the program environment like "memory exhausted" " too many
nesting levels", " floating point overflow" for the language model
is based on infinite resources.
The language definition is nailed down from day one and there is no
ambiguous holes to be filled.

Floating point is a slight exception. Programs can give
different answers due to precision.

>- anton
-- 
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

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

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

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

csiph-web