WikiDiscuss

---

wrote:

>
> --- John E Clifford wrote:
> > We seem to be at cross purposes here.
> {inaja}
> > returns True if the antecedent is False or
> the
> > consequent True. {ijo} returns True if
> antecedent
> > and consequent have the same value.
>
> No doubt.
>
> > Neither of
> > these have anything to do with imperative
> forms
> > per se.
>
> But programming languages deal basically with
> imperative
> forms. If the IF of programming languages has
> nothing
> to do with inaja or ijo then why were
> programming
> languages mentioned at all?

Programming languages also contain descriptions
of conditions, some of which are in "if... then
...." form (many are, in fact — or used to be
before some of the changes of the late eighties).
But also, even though truth functional
connectives have nothing to do with imperatives
per se, theye can be — and are used in
imperatives. and in essentially the same way as
in declaratives.
>
> > The imperative format is apparently
> > that, for IF, if the antecedent is True, then
> the
> > change commanded is made; if the antecedent
> is
> > False, the change is not made (and the whole
> in
> > any case returns True.)
>
> Correct. That matches {ijo}:
>
> go abu du li pa gi ko ciska zo coi
> IF a = 1 THEN PRINT "coi".
>
> We want for antecedent true, command carried
> out,
> for antecedent false, command not carried out.

But that is not {ijo}. At best, {ijo} would have
: condition true — commanded situation made
true, condsition false — commanded situation
made false. In the latter case, if b=0 or
whatever, the value would have to be changed.
This is not what IF does; it rather leaves the
value unchanged when the condition is false. But
still returns True to the control. I am not sure
just what IFF does (and, indeed, don't remember
IFF as a control
command, but it's been a while — except as a
version of IF...THEN...ELSE...).

> > To say that, if the
> > antecedent is False, then the change
> commanded in
> > the consequent is made is to confuse the
> truth of
> > the consequence (the conditional) with the
> truth
> > of the consequent (the second sentence).
>
> With inaja, when the antecedent is false, the
> command
> can be carried out or not to the discretion of
> the
> listener. For example if you say to someone:
>
> ganai abu du li pa gi ko ciska zo coi
> If a = 1, then write "coi".
>
> and a is not equal to 1, and the person writes
> "coi" anyway, they are carrying out the command
>
> correctly. But that is not how IF ... THEN ...
> works in programming languages.

Well, yes, the program might perfectly well do
the command though not because of the IF command,
which simply returns True when the antecedent is
False. I think that you are confusing two
things: what happens and what truth values are
moved around. With IFF, b might be set to (or
remain at) 0 even though the condition that for
that setting is false but that change would be
the result of some other factor, not that
command. To be sure, if the identification were
made _in the processing of that command_ the
process ought to return False and drop into error
chasing — a very different result from what
happens with IF.

> > And, of
> > course, is to make the change required in the
> > second sentence unconditionally (since it
> > presumably will be done if the antecedent is
> > True).
>
> You seem to be confusing what the computer
> does,
> which satisfies both {ganai ... gi ...} and
> {go ... gi ...}, with what it is commanded to
> do.
> If the computer were to randomly decide whether
>
> to carry out the consequent when the antecedent
>
> is false it would still satisfy {ganai...
> gi...},
> but not {go...gi...}.

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.... 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). IFF would take a more complex route
with different results — not the one asked for.

> > The point is that the computer evaluates
> > an IF line as True when the antecedent is
> False,
> > regardless of what happens with the
> consequent.
>
> But what happens with the consequent is
> relevant.
> When the antecedent is false, the computer must
> not
> carry out the command in the consequent.
>
> > The exact mechanism for doing this varies
> from
> > language to language, I seem to recall (I am
> not
> > generally too interested in how those
> evaluations
> > are done, so I may have the details wrong)
> > sometimes by comparison (antecedent less than
> or
> > equal to consequent), sometimes by
> artithmetical
> > moves (which my ultimately be the same
> thing).
> > In any case, the function is just material
> > implication, {inaja}.
>
> It looks like {ijo} to me.
>
> > Or was a few years ago,
> > when IF still was a respectable bit of
> > programming. (ijo) plays less of a role in
> > imperatives, of course, since it will only
> work
> > when there are exactly two possible values:
> one
> > for antecedent True and the other for
> antecedent
> > False.
>
> 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. 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. The difference is that, with IFF, we
have to check which one holds (or which is done);
with IF the command does nothing beyond
identifying the antecedent as False. There is
not further step _in that process_. With IFF
there is, the consequent has always to be dealt
with somehow. (Note, of course, that nothing
happens in a program — we hope — unless it is
commanded to happen, IF with false antecedent
commands nothing to happen, IFF with false
antecedent does command something to happen.)