on changing paradigm of assign call

[fir]

i tried to "design" well a function definition
and meed terrible stall i would say in thsi - dont know how to
do it though i think few years on this

(the probl;ematic is especially this returned values part)

as its go so hard i began to think if this paradigm of calls is not just
wrong and some somewhat new idea come to me (though partially i was
thinking on it)

in fact i fint annoying this form

int x = foo()

annoying is especially this "=" sign as this is not quite assignment imo

other annoying think is thet you need to define x at all
and maybe this is a problem or its part

instead of

int x = add(2,3)
print(x)

maybe it should be

add(2,3)
print(add)


i mean the function name without the () should just represent the
return value so you no need to asign it

present c allows print(add(2,3))
but disalows to reuste it (and assign etc/et more

im close to think it definitely should

i mean

strlen("sjsbsjbhs"")
printf("%d", strlen)

obviously some names could maybe not fit like

find_character_position(txt, 'x');
print(find_character_position);

it should be moer lieke "found"

but i think it could be resolved by allowing to define this


int found find_character_position(char* txt, char c);
{
//...
// or return int found; //something liek that liek defining
structure neme
}

then this found name should be avaliable to caller



so

find_character_position(txt, 'x');
if(found>=0)....

or
sumarize(2,3,3,2,2,3)
if(sum<10) ...

those function call asigments are probably some kind pf mistake
(though it looks a bit weird not to do that)

[fir]

Post by fir
find_character_position(txt, 'x');
if(found>=0)....

wel in fact this should set a boolean "found" and unsigned "position"

find_character_position(txt, 'x');
if(found) printf("found at %d", position);

it looks weird as soem must know thet {find_character_position, found,
position} is a set of names provided by thsi function not only the
name but coders are expected to know function name so they could be
expected to know whole set...

[Lawrence D'Oliveiro]

Post by fir
int x = foo()
annoying is especially this "=" sign as this is not quite assignment imo

The original symbol as used in Algol-like languages was “:=”. While C
copies quite a few features from the Algol family, it made the
questionable decision to shorten the assignment operator to “=”,
ostensibly to save typing. Which meant they had to invent a different
symbol, “==”, to denote an equality comparison.

[Bart]

Post by Lawrence D'Oliveiro

Post by fir
int x = foo()
annoying is especially this "=" sign as this is not quite assignment imo

The original symbol as used in Algol-like languages was “:=”. While C
copies quite a few features from the Algol family, it made the
questionable decision to shorten the assignment operator to “=”,
ostensibly to save typing. Which meant they had to invent a different
symbol, “==”, to denote an equality comparison.

The original symbol in FORTRAN, which came before Algol, was "=" for
assignment (and .EQ. for equality)

BASIC, which came long before C, used "=" for both. It could do that
because it didn't allow assignment inside an expression.

(Meanwhile I use '=' for equality, for defining new named entities, and
for compile-time assignments. Runtime assignments used ':=':

static int a = 100 # inside function
int b := 200

The line is blurred a little in dynamic code when some '=' assignments
need to be done as execution starts.

In C though it gets confusing using the same symbol for each;

static int a = 100; // Initialised once only (and likely before
// execution starts)
int b = 200; // Initialised every time it is encountered)

[Janis Papanagnou]

Post by Lawrence D'Oliveiro

Post by fir
int x = foo()
annoying is especially this "=" sign as this is not quite assignment imo

The original symbol as used in Algol-like languages was “:=”.

Well, for assignments that's true. But the '=' symbol has also been
used in Algol 68 as an identity operator (to define constants), and
above int x = foo() can be interpreted as such.

Janis

Post by Lawrence D'Oliveiro
[...]