Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

The conditional expressions "1" and "0"?

vefatica

vefatica

May
13,402
190
I haven't heard talk of these in a few years. IFF and @IF accept the conditional expressions "1" (actually any non-zero) and "0" as TRUE and FALSE, respectively. Is that WAD? Is that mentioned in the help?

Code: 
v:\> iff 1 then & echo foo & else & echo bar & endiff
foo
v:\> iff 0 then & echo foo & else & echo bar & endiff
bar
v:\> echo %@if[2,foo,bar]
foo
v:\> echo %@if[0,foo,bar]
bar
I had forgotten about that until I was playing with an experimental plugin.

Code: 
v:\> uhelp @keydown
@KEYDOWN[keys] = 1 if all keys are down, else 0
keys: A(lt), S(hift), C(trl)
Does TCC have anything built-in to tell if mod keys are down?

With it I can make a shortcut to TCC do any of four things if I wanted to write a long enough command line to test for all the combinations of CTRL and SHIFT (shortcuts use ALT for properties). I tested with the simple command line

Code: 
d:\tc13\tcc.exe /k echo %@if[%@keydown[s],foo,bar]
Is that of any value? I can't think of too many applications of it. I was thinking of adding the WIN key and of changing it to a _VARIABLE which would return a bit-map (0~15) of which of the four mod keys are down. Any thoughts? [I don't have a WIN key here so I can't test what you can/can't do while it's down.]
 
On Sun, 25 Sep 2011 00:49:21 -0400, Steve Fabian <> wrote:

|Look up internal variable _alt, _lalt, _ralt, etc. Available since 4NT 6!

Thanks (I probably knew that once upon a time). None for the WIN key?

So far I have this:

Code: 
g:\projects\4utils\release> uhelp _modkeys
bitmap (0-31) of mod keys; 1 = Shift, 2 = Ctrl, 4 = Alt, 8 = LWin, 16 = RWin

g:\projects\4utils\release> do forever ( delay 4 & echos ` `%_modkeys )
 0 1 2 4 3 5 6 7 0

That's as much as I can test it w/o a WIN key.

What's VK_APPS?
 
vefatica said:
On Sun, 25 Sep 2011 00:49:21 -0400, Steve Fabian <> wrote:

|Look up internal variable _alt, _lalt, _ralt, etc. Available since 4NT 6!

Thanks (I probably knew that once upon a time). None for the WIN key?

So far I have this:

Code: 
g:\projects\4utils\release> uhelp _modkeys
bitmap (0-31) of mod keys; 1 = Shift, 2 = Ctrl, 4 = Alt, 8 = LWin, 16 = RWin
Click to expand...
Possibly break down Alt into left and right; some localized keyboards use rAlt as a modifier.
What's VK_APPS?
Click to expand...
Isn't that a mouse right-click from the keyboard? The key that sits to the right of rAlt?
 
On Sun, 25 Sep 2011 02:17:57 -0400, Stefano Piccardi <>
wrote:

|---Quote---
|What's VK_APPS?
|---End Quote---
|Isn't that a mouse right-click from the keyboard? The key that sits to the right of rAlt?

No idea. I use a 20-yr old Gateway AnyKey keyboard.
 
On Sun, 25 Sep 2011 11:02:17 -0400, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|No idea. I use a 20-yr old Gateway AnyKey keyboard.
|---End Quote---
|http://www.norwescon.org/archives/norwescon33/vingeinterview.htm
|
|(Click on the 'workspace' picture for a closer view.)

That's the critter. I have a stash (4) of them. They get cycled regularly.
Every few years I disassemble one for cleaning. A little silicone makes the
keys tight and quiet. A few years back I dumped a glass of port squarely in the
middle of one ... it stopped working. I had to remove and clean the circuit
board (flexible plastic sandwiched between a metal plate and a hard plastic
sheet that holds the key mechanisms). I had about 400 parts scattered around my
kitchen. Amazingly, it's working again. I'm fortunate that Dell keeps putting
PS/2 ports in its workstations.
 
vefatica said:
That's the critter. I have a stash (4) of them. They get cycled regularly. Every few years I disassemble one for cleaning. A little silicone makes the keys tight and quiet. A few years back I dumped a glass of port squarely in the middle of one ... it stopped working. I had to remove and clean the circuit board (flexible plastic sandwiched between a metal plate and a hard plastic sheet that holds the key mechanisms). I had about 400 parts scattered around my kitchen. Amazingly, it's working again. I'm fortunate that Dell keeps putting PS/2 ports in its workstations.
Click to expand...

I should try that. I have one at work (with the Windows logo and menu keys) but the action is too crunchy to be useful -- I think a previous user must've dropped soda in it.

("A Deepness in the Sky" was written on an AnyKey! A bit of irony there....)
 
On Sun, 25 Sep 2011 12:08:26 -0400, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|That's the critter. I have a stash (4) of them. They get cycled regularly. Every few years I disassemble one for cleaning. A little silicone makes the keys tight and quiet. A few years back I dumped a glass of port squarely in the middle of one ... it stopped working. I had to remove and clean the circuit board (flexible plastic sandwiched between a metal plate and a hard plastic sheet that holds the key mechanisms). I had about 400 parts scattered around my kitchen. Amazingly, it's working again. I'm fortunate that Dell keeps putting PS/2 ports in its workstations.
|---End Quote---
|I should try that. I have one at work (with the Windows logo and menu keys) but the action is too crunchy to be useful -- I think a previous user must've dropped soda in it.

The ones with the WinLogo key are different but I'm not sure of all the details.
So what I say below may not be 100% accurate. None of mine have the WinLogo
keys and they all have the big (~3/4 in.) DIN plug.

Do you know those big flat stainless steel paper clips (~5/8 in. wide and 3-5
in. long)? I bent one into a tweezer-like U-shape and bent about 1/16 in. at
the tips at right angles (toward each other). Using it like a tweezer, the bent
tips grab under the key and the key tops pop off easily. I use silicone spray
in a little cup ... apply it with a Q-tip around the plunger and wipe up the
excess when done. With 121 keys, it takes a while. The keys are slow after
this treatment, but smooth and quiet.

The big keys (space, enter, shift) have metal guides that keep them level and
square. If you indiscriminantly yank those key tops off you'll break something.
Then it's time to break out the epoxy (been there, done that).
 
> I haven't heard talk of these in a few years. IFF and @IF accept
> the conditional expressions "1" (actually any non-zero) and "0"
> as TRUE and FALSE, respectively. Is that WAD? Is that mentioned
> in the help?
Click to expand...

WAD, as it couldn't possibly behave any other way and still work with
variables. I don't know that it's documented, but OTOH I'd consider it too
obvious to need explicit documentation.
 
On Sun, 25 Sep 2011 18:18:08 -0400, rconn <> wrote:

|---Quote---
|> I haven't heard talk of these in a few years. IFF and @IF accept
|> the conditional expressions "1" (actually any non-zero) and "0"
|> as TRUE and FALSE, respectively. Is that WAD? Is that mentioned
|> in the help?
|---End Quote---
|WAD, as it couldn't possibly behave any other way and still work with
|variables. I don't know that it's documented, but OTOH I'd consider it too
|obvious to need explicit documentation.

I don't know what your first sentence abive means. It's a fairly new feature,
isn't it ... within the last 5-6 years. Without documentation, one might not
know it's there; it doesn't fit any of the definitions of "conditional
expression". And knowing about it, one might think it applies to IF as well
(which, I think, it doesn't).
 
|| I haven't heard talk of these in a few years. IFF and @IF accept
|| the conditional expressions "1" (actually any non-zero) and "0"
|| as TRUE and FALSE, respectively. Is that WAD? Is that mentioned
|| in the help?
|
| WAD, as it couldn't possibly behave any other way and still work with
| variables. I don't know that it's documented, but OTOH I'd consider
| it too obvious to need explicit documentation.

Actually, this was an issue many years ago. The statement
IF %_echo echo echo is on
used to return a syntax error message. One had had to use
IF %_echo GT 0 echo echo is on
to avoid the error message. After receiving my and others' complaints the logic was changed to imitate C's definition of true / false.
--
Steve
 
On Sun, 25 Sep 2011 21:10:02 -0400, Steve Fabian <> wrote:

|Actually, this was an issue many years ago. The statement
| IF %_echo echo echo is on
|used to return a syntax error message. One had had to use
| IF %_echo GT 0 echo echo is on

|to avoid the error message. After receiving my and others' complaints the logic was changed to imitate C's definition of true / false.

It still gives a syntax message. It doesn't work with IF. Do you see the
confusion?
 
On Sun, 25 Sep 2011 21:29:00 -0400, vefatica <> wrote:

|On Sun, 25 Sep 2011 21:10:02 -0400, Steve Fabian <> wrote:
|
||Actually, this was an issue many years ago. The statement
|| IF %_echo echo echo is on
||used to return a syntax error message. One had had to use
|| IF %_echo GT 0 echo echo is on
|
||to avoid the error message. After receiving my and others' complaints the logic was changed to imitate C's definition of true / false.
|
|It still gives a syntax message. It doesn't work with IF. Do you see the
|confusion?

P.S. It was never meant to work with IF.
 
| It still gives a syntax message. It doesn't work with IF. Do you see
| the confusion?

After testing, I agree - it is confusing. IFF and @IF accept a numeric value as a conditional expression, and consider only 0 as false. Cf. IF - it still gives a syntax message! I wonder how "DO WHILE" and "DO UNTIL" treat a numeric expression... I did not test them.

IMHO wherever a conditional expression is expected, a numeric-valued expression should be accepted, and interpreted as TRUE if its value is other than zero, and FALSE if its is zero. An "almost zero" value of a floating point expression should be considered TRUE, only exactly zero considered FALSE.
--
Steve
 
vefatica said:
I don't know what your first sentence abive means.
It's a fairly new feature, isn't it ... within the last 5-6 years.
Click to expand...

Not new behavior. (Nothing like a new version to get people to discover old features!)

"IFF %a then ..." is a valid test (and a lot more useful than hard-coding a 0 or 1 there).

Hard coding a 0 or 1 is a logical expression (see the docs). A dumb and completely useless relational expression, but nevertheless.

I don't feel a strong need to document dumb and useless syntax.

And knowing about it, one might think it applies to IF as well
(which, I think, it doesn't).
Click to expand...

It cannot apply to IF unless you want to toss CMD compatibility out the window.
 
On Sun, 25 Sep 2011 22:21:27 -0400, rconn <> wrote:

|Hard coding a 0 or 1 is a logical expression (see the docs).

I can't find anything about it.

Where exactly? I found

Code: 
Logical Expression
A logical expression is one of the following:

a relational expression
a status test
the unary logical operator NOT followed by a logical expression
two logical expressions connected by a binary logical operator

It doesn't seem to a relational expression or a status test. If it's really a
logical expression, the 4th point above suggests (wrongly) that "1 .and. 1" is
also a logical expression.
 
From: rconn
...
| "IFF %a then ..." is a valid test

Not documented.

| (and a lot more useful than hard-coding a 0 or 1 there).

That was just for experimenting. Nobody who spends the effort to use TCC instead of CMD would do that in code designed to do something useful.

| Hard coding a 0 or 1 is a logical expression (see the docs). A dumb
| and completely useless relational expression, but nevertheless.

I don't see that in the "Conditional Expressions" topic! None of the formats listed in the definitions of logical expression, nor of relational expression, show a format consisting of a single numeric literal.

| I don't feel a strong need to document dumb and useless syntax.

You stated above "IFF %a" is a valid test. It is not documented! The leading paragraph of "Conditional Expressions" enumerates where they can be used. None of the topics on the referenced commands and function modify the common definition. It ought to be added! It makes coding many tests much simpler - there are many internal variables and environment functions that return a zero vs. non-zero result. All my most recent code still compares such results with 0, it turns out unnecessarily - unless using IF.

| It cannot apply to IF unless you want to toss CMD compatibility out
| the window.

AFAIK applying it (i.e., interpreting a numeric value as TRUE or FALSE as in C/C++) to IF would just accept syntax that CMD rejects, thus the only additional incompatiblity would be to refuse to report an error where CMD would report one, just like a hundred other cases. IMHO not a bar to making it apply in all cases!

Also, I did not test, but is "DO WHILE %_LALT" and its DO UNTIL variant legal? In other words, when is a numeric expression valid as a conditional expression? It ought to be everywhere!

Note: The Help topic for the IF command, Usage section, 2nd paragraph contains the phrase "conditional expression operators (II or &&)". IIRC the phrase ought to be "conditional command operators (II or &&)."
--
Steve
 
rconn said:
It cannot apply to IF unless you want to toss CMD compatibility out the window.
Click to expand...

I suppose you could permit something like

Code: 
IF numeric THEN command...

CMD.EXE wouldn't grok it, but we're all used to that by now.
 
> | It cannot apply to IF unless you want to toss CMD compatibility out
> | the window.
>
> AFAIK applying it (i.e., interpreting a numeric value as TRUE or FALSE
> as in C/C++) to IF would just accept syntax that CMD rejects, thus the
> only additional incompatiblity would be to refuse to report an error
> where CMD would report one, just like a hundred other cases.
Click to expand...

No, it can never work, in ANY of the cases.

IFF knows that when it sees a THEN, that the conditional expression has
ended. There is no trailing keyword in IF, so even the DWIM parser cannot
automagically decide that the first argument is an expression and the second
argument is a command.
 
> Also, I did not test, but is "DO WHILE %_LALT" and its DO UNTIL
> variant legal? In other words, when is a numeric expression
> valid as a conditional expression? It ought to be everywhere!
Click to expand...

It's valid everywhere that a trailing keyword terminates the expression.

I.e., in IFF. (Unless you're suggesting breaking existing batch files by
changing the DO syntax?)
 
From: rconn
...
| No, it can never work, in ANY of the cases.
|
| IFF knows that when it sees a THEN, that the conditional expression
| has ended. There is no trailing keyword in IF, so even the DWIM parser
| cannot automagically decide that the first argument is an expression and the
| second argument is a command.

| ESF:
|| Also, I did not test, but is "DO WHILE %_LALT" and its DO UNTIL
|| variant legal? In other words, when is a numeric expression
|| valid as a conditional expression? It ought to be everywhere!
|
| It's valid everywhere that a trailing keyword terminates the
| expression.
|
| I.e., in IFF. (Unless you're suggesting breaking existing batch files
| by changing the DO syntax?)


I see that the key issue is parsing - determining where the conditional expression ends and other command elements begin.
As you stated, in IFF the keyword THEN is a valid separator. Not reported in this thread, but presumably the comma separating the first and second parameters of @IF is its unambiguous separator. This leaves the DO and IF. I suggest that in the command
DO WHILE %_lalt
(and similarly in DO UNTIL) the conditional expression MUST be followed by the end of line, which could act as an unambiguous terminator, so these commands could easily accomodate numeric valued conditionals. This leaves only the IF command requiring the DWIM parser (which is coming in the next release, right?). Analogously to the single-line (interactive) DO command, you could require that the command be enclosed in parentheses, as a command group. This would make parsing possible: the conditional expression is everything between the IF keyword and the command group; the latter starting with the left parenthesis that matches the terminating right parenthesis.

Until such time as the numeric-valued conditional expression is accepted in all places where a conditional expression is expected, it should be documented in the conditional expression topic as one valid only in specified contexts.
--
Steve
 
rconn said:
It's valid everywhere that a trailing keyword terminates the expression.

I.e., in IFF. (Unless you're suggesting breaking existing batch files by
changing the DO syntax?)
Click to expand...

As Steve said, DO has a reliable newline in a batch file and a reliable '(' at the command line. I wasn't lobbying for "IF %var ..." (gave up on IF a long time ago. But it would be nice if the construction were thoroughly documented and behaved as logical expressions behave ... i.e., be combinable with .AND., .OR., and .XOR. and work in "DO WHILE/UNTIL".
 
vefatica said:
As Steve said, DO has a reliable newline in a batch file and a reliable '(' at the command line. I wasn't lobbying for "IF %var ..." (gave up on IF a long time ago. But it would be nice if the construction were thoroughly documented and behaved as logical expressions behave ... i.e., be combinable with .AND., .OR., and .XOR. and work in "DO WHILE/UNTIL".
Click to expand...

I must retract part of that. On the command line, '(' may be encountered as part of the WHILE/UNTIL condition itself.
 
> Rex, I can't *resist* asking. If that is the case for "IFF", why *isn't*
Click to expand...
that

> the case for "IF"?
Click to expand...

As I said in a previous message, it cannot work for IF because (1) it would
break compatibility with CMD, and (2) there isn't any trailing keyword in
IF, so the parser cannot know where the expression ends and the command
begins.
 
You must log in or register to reply here.
Back
Top
[FOX] Ultimate Translator
Translate