From: do-not-use@swldwa.uk
On 31/10/2025 17:12, Anton Ertl wrote:
> Gerry Jackson writes:
>> Sorry Anton I read your message and was going to reply and I
>> accidentally did something that caused Thunderbird to lose your message.
>> I can't find it and it isn't in the 'deleted' folder. I'd be grateful if
>> you could repost it please.
>
> It's <2025Oct31.153524@mips.complang.tuwien.ac.at>. You can look it
> up on, e.g., .
>
>> From my memory the gist of your message was:
>> given
>>
>> my-condition [if]
>> \ I have something witty to say about [if]
>> ....
>> [else]
>> ....
>> [then]
>>
>> I think you said that if MY-CONDITION is TRUE then the first [if] let's
>> the Forth interpreter take over and so the second [IF] is ignored
>> because it's in a comment and all is good
>>
>> But if MY-CONDITION is FALSE the second [IF] is reached with unknown
>> consequences.
>
> The consequences are known, but probably unintended: the [ELSE] and
> [THEN] are perceived as belonging to the second [IF], so at the end
> one is still scanning for the [THEN] or [ELSE] that belongs to the
> first [IF].
>
>> Or are you saying that the second [if] should be found because that is
>> what is expected in a standard by the Forth standard
>
> Yes, a system that ignores [IF] in comments would not be
> standard-conforming, and not in line with existing practice in
> systems.
>
> Given that nobody will write something like the example above (if
> their system is standard-conformung), does it matter? Let's see if I
> can construct an example that might occur and where it matters:
>
> my-condition [if]
> .( a)
> [else]
> .( b)
> \ [else]
> .( c)
> [then]
> .( d)
>
> I tested on gforth 0.7, iforth-5.1 mini, lxf, sf64-4.0.0-rc89, and
> vfx64-5.43. I put the lines above into /tmp/xxx.fs.
>
> With
>
> true constant my-condition include /tmp/xxx.fs cr bye
>
> all systems except iforth output "acd", as specified by the standard.
> iforth outputs "ad", i.e., it has a scanner that treats "\"
> especially. For
>
> false constant my-condition include /tmp/xxx.fs cr bye
>
> every system outputs "bcd", as specified by the standard.
>
> Again, I doubt that anybody will use that intentionally in production
> code. There might be some opccurences by mistake, where, rather than
> fixing the problem (the [ELSE] in text that's not text-interpreted),
> some workaround was implemented. Still, these cases should be so rare
> that a change should be doable, if it was really wanted.
>
> The bigger problem is that you get the same problem with other parsing
> words. Parsing words can be user-defined, and with search order
> changes one can make things even harder for an [IF] etc. set of words
> that try to be smart about such uses. So where would we stop? Should
> we stop right at the beginning before special-casing any parsing word?
>
>> Or have I missed some nuance in your message?
>> I remember a comment about ." but don't remember anything else
>
> I gave an example where ." was used as a parsing word that parses [IF]
> and [ELSE]. But nothing fundamentally different from the cases
> involving \.
>
I removed the definition of \ from the wordlist and, as you would expect
it gets the same results as all other systems (less iforth).
So I'll leave it at that, the possibility of there being user defined
parsing words make it more trouble than it's worth fixing.
Thanks for the explanation
--
Gerry
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
