albertvanderhorst / ciforth

A generic system for creating i86 implementations of the language Forth.
https://forth.hcc.nl/producten/ciforth.html
GNU General Public License v2.0
59 stars 7 forks source link

case-insensitivity for `[if]` #12

Open ruv opened 3 weeks ago

ruv commented 3 weeks ago

ciforth version 5.5.1

It seems, [if] [else] [then] are still case-sensitive even though "CASE-INSENSITIVE" WANTED.

The command:

echo '0 [if] 1 . [else] 0 . [then]' | ./lina64 -f ' "AUTOLOAD" WANTED  "CASE-INSENSITIVE" WANTED CR '

Prints nothing instead of 0.

Actual output:

 "AUTOLOAD" WANTED  "CASE-INSENSITIVE" WANTED CR
[if] : (WARNING) NOT PRESENT, THOUGH WANTED
 WANT [if]

Expected output:

[if] : (WARNING) NOT PRESENT, THOUGH WANTED
 WANT [if]
0
ruv commented 3 weeks ago

If ciforth provides the standard word wordlist, a reference implementation for [if], [else], [then] can be used.

albertvanderhorst commented 2 weeks ago

It cannot be argued that the supplied solution is non-standard, because [THEN] is not supposed to be a Forth word. It violates the principle of least surprises, though. All uses of [IF] are a mine field, anyway and I will not recommend it. I'll put this matter in the FAQ.

ruv commented 2 weeks ago

Yes, if you say that the system supports the case-insensitive mode, the user expects that the words [if], [else], [then] can be used in lower case too. Why not implement this?

albertvanderhorst commented 1 week ago

Op 29-08-2024 15:34 CEST schreef ruv @.***>:

Yes, if you say that the system supports the case-insensitive mode, the user expects that the words [if], [else], [then] can be used in lower case too. Why not implement this?

I don't want to promote conditional compilation by [IF] where WANTED is more superior, anyway. I don't subscribe to the notion that everything must be added that is convenient to some. Where Forth has never been designed in the first place, this is a recipee for disaster. If lina is in case-insensitive mode, words can be found in the dictionary. [THEN] is not a dictionary word. Full stop. You must get used to it that [THEN] will be recognized in comment and strings. See the comment from Bernc Paysan. gforth went into the rabbit hole of ignoring [THEN] in comments, but retraced it.

Groetjes Albert

— Reply to this email directly, view it on GitHub (https://github.com/albertvanderhorst/ciforth/issues/12#issuecomment-2317675675), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AF6Y53JHBBYOXOBEXN22ALLZT4PNZAVCNFSM6AAAAABM65S6LCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMJXGY3TKNRXGU). You are receiving this because you commented.Message ID: @.***>

ruv commented 1 week ago

I don't want to promote conditional compilation by [IF] where WANTED is more superior, anyway.

That's fine, no problem. JFYI, WANTED does not help in portable code when you check what words are available and use different implementations depending on that. For example, if the system provides find-name, you use find-name, otherwise you use find.

[THEN] is not a dictionary word

There is a [THEN] word. See 15.6.2.2533 [THEN].

You must get used to it that [THEN] will be recognized in comment and strings.

This is irrelevant to the initial problem.

Anyway, yes, you cannot wrap a string literal in [IF] [THEN] if that string literal contains the substring "[THEN]" or "[IF]". This is by design. The same problem exists in many programming languages. For example, in C, you cannot wrap a string literal in a multi-line comment if that string literal contains "*/". The same in Forth multi-line comments.