WikiDiscuss

---

> As noted, you are leaving out the control issues
> — the value returned — which would be False
> with IFF (and error-chasing) but true in the IF
> case. I suppose we could insert a randomizer for
> the False antecedent case, but that would not be
> IF but rather IF...THEN...ELSE....

IF...THEN...ELSE... is a three-way conective, so it couldn't
correspond to {inaja} or {ijo}, which are both two-way.
In fact, I think there is no way to do IF...THEN...ELSE...
in Lojban without reapeating one of the connectands.

> The point is
> that the work if IF is done correctly as soon as
> either the antecdent is found to be False or the
> state demanded in the consequent is True (and the
> check is made in that order in most familiar
> systems).

How the computer goes about carrying out the instruction
is not relevant here. The question is whether the meaning
of the programming language instruction "IF...THEN..."
corresponds or not to the meaning of {inaja}. It's a
linguistic question. From the point of view of this analysis
we don't care whether or how the computer carries it out,
just what it is that we are instructing. A computer that
carries out the instruction in the consequent when the
antecedent is false is malfunctioning wrt how we want
the instruction to work, but it would be correctly
carrying out the command {ganai ... gi ko ...} from
a lingustic point of view.

> > There are always exactly two possible values
> > for the consequent too: one is to carry out the
> > command
> > and the other is to not carry it out.
> Well, maybe — often there are a range of
> possible ways not to carry out the command: if
> the command is to make b=0 then the alternatives
> are to make b=1, or 2 or .... or to leave it with
> whatever value it has.

No, from the point of view that matters here, the
only two alternatives are make b = 0 or do nothing
(including leaving b = 0 if that was its value).

> Which of these is what is
> triggered by False antecedent? Any one of them
> would do until we have some convention (which
> returns True to control). To be sure — as I
> suppose you will say — with IF any one of these
> alternatives could be true with a False
> antecedent.

There is only one command at stake, namely "set b = 0".
With that command, there are only two things the computer
can do: carry it out, or not carry it out. Carrying it
out corresponds to True, not carrying it out corresponds
to False. Other commands such as "set b = 1" are
irrelevant for this instruction. The only way the consequent
can be false is by NOT carrying out the command, irrespective
of the value that the variable b has.

If we were to write a programming language in Lojban,
the usual instruction IF...THEN... would have to be
go...gi...

mu'o mi'e xorxes

__
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com