Foundation for [non]/boolean flow control?
NoHtmlMailsPlease
But unix-scripts and derivatives use:
<operationSucceeded> = 0,
<variousPossibleOperationfailureCauses> != 0
Why are there 2 different approaches?
First let's consider the historic background:
at asm/machine level, the ALU provided register comparison.
The simplest being <EQUALS>.
With integers, <EQUALS> suffices, since <Less> and <More>
can be handled by <value +1> and <EQUALS>.
In an un-typed forth-like scripting language, which
approach is recommended?
== Chris Glur.
PS.
Consider testing file-conditions from boolean-PointOfView
=> must use predicate
relational-ops are also predicatesOf2Args
=> Apparently 2arg-predicates are the core of control-flow
=> Asking the question "is it" leads to a boolean pov: yes/no?
=> Asking the question "what relation value applies to A,B"
leads to {one of: =,#,<,>= ..}
The reasoning, based on machine instructions testing a flag,
plus the binary mature of computers, lead to a boolean pov.
It's looking as if <multiple value predicate> is better?
Martin Brown
> Traditional languages use booleans for flow control.
I don't think this statement is true.
The oldest computer languages used the CPU arithmetic result flags for
three way branched flow control and also had computed jump tables.
For example in FORTRAN
IF (arithmetic_expression) 1,2,3
Would go to label 1 if negative, 2 if zero and 3 if positive
And also the computed goto
GOTO (10,20,30,40), I
which would jump to the label indexed by I.
Logical IF was also available. But the older coding style persisted.
Atlas autocode had roughly similar constructs in 1965. I was surprised
on checking the coding manual to see the keyword "switch" had already
appeared by then. Manual is online at:
paras 2.8, 2.9 are relevant.
This old clunky style may have faded out but it was traditional.
Regards,
Martin Brown
> But unix-scripts and derivatives use: <operationSucceeded> = 0,
> <variousPossibleOperationfailureCauses> != 0
>
> Why are there 2 different approaches?
Sometimes it is useful to distinguish between for instance a soft or
temporary failure that may only require a retry to succeed and a hard
failure with no hope of recovery.
Ed Prochak
> Traditional languages use booleans for flow control.
>
> But unix-scripts and derivatives use:
> <operationSucceeded> = 0,
> <variousPossibleOperationfailureCauses> != 0
>
> Why are there 2 different approaches?
>
Boolean: TRUE/FALSE equivalent to 1/0 or 5V/0V or Closed/Open
or nonZero/0
> First let's consider the historic background:
> at asm/machine level, the ALU provided register comparison.
> The simplest being <EQUALS>.
Equals is a compirson operator and requires an opcode. Simplest is
using the flags set on the ALU on the last value loaded/computed into
the accumulator.
This usually included at least a ZERO flag and a NEGATIVE flag.
The Zero flag makes Boolean decisions easy. So even the low level
hardware supports NonZero/0 Boolean values.
>
> In an un-typed forth-like scripting language, which
> approach is recommended?
If you are in a typeless language, I would expect something like the
shell boolean notation:
0/nonzero.
>
> == Chris Glur.
>
> PS.
> Consider testing file-conditions from boolean-PointOfView
> => must use predicate
Aren't all file tests Boolean? (does file exist? is file readable?)
> relational-ops are also predicatesOf2Args
also? File tests are usually only one argument, the name of the file
to test.
> => Apparently 2arg-predicates are the core of control-flow
NO. They are the core of basic mathematical operations.
> => Asking the question "is it" leads to a boolean pov: yes/no?
> => Asking the question "what relation value applies to A,B"
> leads to {one of: =,#,<,>= ..}
> The reasoning, based on machine instructions testing a flag,
> plus the binary mature of computers, lead to a boolean pov.
> It's looking as if <multiple value predicate> is better?
Okay, sounds like you are arguing for syntax like
y = compare(A, B)
switch Y
case = do P() /* equal in type and value */
case < do Q() /* A is smaller in value */
case > do R() /* A is larger in value */
case # do S() /* invalid compare, incompatable types */
case % do T() /* A is smaller than B, but there was a type conversion
*/
. . .
end
is better. Am I understanding you right?
I think your initial premise is false so I don't buy you conclusion
(if I understand it correctly.)
ED
NoHtmlMailsPlease
"Ed Prochak" <edpr...@gmail.com> wrote in message
news:a32f03b5-f93d-4de1...@k15g2000yqd.googlegroups.com...
>> => Asking the question "is it" leads to a boolean pov: yes/no?
>> => Asking the question "what relation value applies to A,B"
>> leads to {one of: =,#,<,>= ..}
>> The reasoning, based on machine instructions testing a flag,
>> plus the binary mature of computers, lead to a boolean pov.
>> It's looking as if <multiple value predicate> is better?
>
> Okay, sounds like you are arguing for syntax like
> y = compare(A, B)
> switch Y
> case = do P() /* equal in type and value */
> case < do Q() /* A is smaller in value */
> case > do R() /* A is larger in value */
> case # do S() /* invalid compare, incompatable types */
> case % do T() /* A is smaller than B, but there was a type conversion
> */
> . . .
> end
>
> is better. Am I understanding you right?
>
> I think your initial premise is false so I don't buy you conclusion
> (if I understand it correctly.)
>
> ED
the server-function, you avoid doing the test later.
OTOH if you want to do boolean-algebra with the returned
value of several functions, like: (color=OK)AND(price < limit),
how would you handle that?
Elementary boolean calculations can be simulated by:
0 => pass; NOT(0) => fail=NOT(pass) since
<testA + testB + testC> simulates:
passA AND passB AND passC.
I'm surprised that no one here can point to a theoretical
publication on this topic.
Ed Prochak
I'm still not sure I underrstand what TOPIC you are interested in.
I'm guessing at this point PROGRAM FLOW CONTROL.
If so, the fundamentals are:
processors have an instruction pointer register (IP) containing the
address of the next instruction to execute.
there are two possible things that can happen when an instruction
executes:
1. the value of IP is incremented to point to the next instruction
2. the value of IP is updated with some other value pointing to the
next instruction.
in case 2 changing IP may be due to executing opcodes similar to BASIC
instructions:
GOTO
CALL
RETURN
IF THEN
Some instruction sets might have combined versions of instructions
(e.g. Arithmetic IF).
So control is fundamentally binary based on the IF. You goto the
target address or not.
So again I say your premise:
<quote>
Traditional languages use booleans for flow control.
But unix-scripts and derivatives use:
<operationSucceeded> = 0,
<variousPossibleOperationfailureCauses> != 0
Why are there 2 different approaches?
</quote>
is flawed.
Back to your question:
In an un-typed forth-like scripting language, which
approach is recommended?
===========
if perhaps you are writing such a language, I suggest some topics that
might help. Look for "programming language structures", because the
answer to your question is:
whatever style of conditional statements fit with the rest of the
language.