Another spinoza challenge

[spinoza1111]

Phil Carmody said:

Only by torturing the concept of pass by reference beyond its yield
point.

Not in my opinion.

If passing the address of a variable were equivalent to
passing by reference, then the following program would print 42:

Strong assertion.

#include <stdio.h>

void byref(int *p)
{
  p = 42; /* bug - p was *not* passed by reference. */
}

And completely unfounded. There's no definition of 'pass by reference'
which would justify your claim. You've just burnt a straw man.
[Snip things dependenent upon straw man.]

He has a point (a small point, but nonetheless a point). In VB,
declaring a variable as passed by ref in the formal parameter list
doesn't give the sub or function the ability to get the address of the
variable, whereas C does, bless its black heart. In C Sharp, you must
declare the parameter as passed by reference in both the formal and
actual parameter lists (the requirement to do so in the actual
parameter list is a virtuous error checker upper onner). But you don't
get the von Neumann address because you don't need it and you will
foul things up with it were you to get it.

Therefore, to make Richard happy, we should call C's very special
variant of By Reference, which gives you the functionality of VB ByRef
and C Sharp ref PLUS the chance to make a mess of things, something
like "by reference with the chance to **** up", BRWTCTFU.

 

[spinoza1111]

Phil Carmody said: [...]
It appears that some people can't grasp the fact that one can
effect pass by reference by passing variables by address.
Only by torturing the concept of pass by reference beyond its yield
point.

Not in my opinion.

Strong assertion.

And completely unfounded. There's no definition of 'pass by reference'
which would justify your claim. You've just burnt a straw man.

[...]

The point, I think is that *just* passing the address of a variable
is insufficient to implement passing by reference in C.

To implement or emulate pass by reference in C, you have to (a)
pass the address of the object you want to pass by reference, and
(b) make sure that every reference within the function is explicitly
dereferenced.

This is to give you an extra "feature" of "knowing" the address.

Whether we call this feature "pass by reference" is a matter for a
specific community with a job to do to agree about, not a bunch of
pompous people with nothing better to do. Read Ferdinand de Saussure:
there is no magic connection between word and thing.

 

[James Kuyper]

I'm not so sure. Or perhaps I am.

I clearly remember my Trinity College interview way back where
I repeatedly used the word "weight" in the presence of the
college's applied maths tutor, and he kept "correcting" me to
use the word "mass" given the context in which I was using it.

He was of course wrong.

To you, it is "of course". We have no basis for judging your competence
at that time relative to that of the tutor, so it's not obviously true
to the rest of us. That is not meant to disparage your competence,
merely to ask for more details; could you given an example of the kind
of statements that you were making using the word "weight" that he was
objecting to? I'm not asking you to remember a specific usage, just an
example of the kind of thing he was objecting to.

 

[spinoza1111]

spinoza1111said:



Not just for me.

You have a primitive idea of language, so this debate is silly. You
can't even think unless words have simple meanings.

But, here's wikipedia:

Even among languages that don't exactly support call-by-reference,
many, including C and ML, support explicit references (objects that
refer to other objects), such as pointers (objects representing the
memory addresses of other objects), and these can be used to effect or
simulate call-by-reference (but with the complication that a
function's caller must explicitly generate the reference to supply as
an argument). Some languages straddle both worlds; for example, Java
is a call-by-value language, but since the results of most Java
expressions are references to anonymous objects, it frequently
displays call-by-reference semantics without the need for any explicit
reference syntax.

Here's the Free Online Dictionary of Computing:

call-by-reference
An argument passing convention where the address of an argument
variable is passed to a function or procedure, as opposed to where the
value of the argument expression is passed. Execution of the function
or procedure may have side-effects on the actual argument as seen by
the caller. The C language's "&" (address of) and "*" (dereference)
operators allow the programmer to code explicit call-by-reference.
Other languages provide special syntax to declare reference arguments
(e.g. ALGOL 60). See also call-by-name, call-by-value, call-by-value-
result.

No, it's a valuable simplicity.

Don't make me laugh. Aliasing is a defect.

(a) I challenge your claim - please provide statistics from an
independent study to support it;
(b) even if it /is/ true (which personally I doubt very much), so
what? "Most C programmers" don't get to decide what call by reference
means, any more than they get to decide what L2 cache means.

See above.

 

[Dik T. Winter]

> When a function parameter is passed by reference, the value of its Von
> Neumann address is passed to the function. Changes to this value are
> also lost, but it can be "dereferenced" using asterisk as a prefix
> operator to access the calling procedure's copy of the parameter to
> change this copy.

Hm. So in the Fortran code:
SUBROUTINE SUB(A)
A = 1.0
RETURN
END
SUBROUTINE SUB1(C)
REAL A
CALL SUB(A)
C = A
RETURN
END
there is no pass by reference?

 

[spinoza1111]

spinoza1111said:



To you, perhaps; but then to me you appear to be ignorant full stop.
Better to stick to facts - and the fact is that C doesn't do call by
reference.

It's profound dishonesty like this that makes me glad I left the field
(after thirty years) and am now a teacher.

In a civilized environment, people who know what other people
understand to be the case, and believe, allow others to use different
"terminology".

In barbarism, *mullahs* issue *fatwas* to *taliban*: Stalinist
*apparatchiks* send *zeks* to the Gulag because of the misuse of
"terminology": Nazi thugs send people to gas chambers for not making
the Nazi salue: and people who can write and program get labeled
"trolls" and "drama queens" by assholes and thugs.

In a civilized environment, Enlightenment is describable many
different ways. In Sarajevo before Milosevic, people attended Moslem
and Christian services as a courtesy knowing that God could be in many
places at once.

In barbarism, women and children are shot by bearded thugs from hiding
as you destroy people from hiding and in the pay of your publisher,
perhaps.

Prior to the takeover of admission to programming jobs, which in the
G-8 became ever more temporary and controlled, by employment agents,
people would come to an understanding that "call by reference" has two
meanings (implicit and explicit), and wouldn't like a child insist on
being right.

I am very, very serious about the comparision to barbarism in the
large. You are, it appears, a Christian fundamentalist and as such you
are not, in my opinion, qualified to do scientific or technical work
beyond a very basic level, and you are not, in my opinion, qualified
at all to write about technology. This discussion is evidence, since
you are in fact "trolling" without hope of getting people to agree
with you, even as the Christian fundamentalist insists (in the face of
archeological and literary evidence) that the Bible must be
interpreted his way.

On the contrary, it's /broken/ tests that I don't like, because broken
tests mislead people by their results. If I can't pass a non-broken
test, and care enough, I can study harder; but if the test is broken,
I can't trust the result no matter what it is.

So find what you think is a non-broken test and pass it.

 

[Ben Bacarisse]

Ben Bacarisse said:

K&R muddied the waters themselves. bartc should have illustrated
the point with an array rather than a hypothetical struct syntax:

#include <stdio.h>

void byref(int v[])
{
v[0] = 42;
}

int main(void)
{
int vec[] = {1, 2, 3};
byref(vec);
printf("vec[0] = %d\n", vec[0]);
return 0;
}

This passes almost every test for "pass by reference" one can think
of. There is no special syntax in the called function and none
needed at the point of call.

Actually, there is. The "special syntax" in the called function is
what Chris Torek calls "The Rule" - i.e. vec is a shorthand for
&vec[0], and it is this value, the address of the first element of
the array, that is passed - by value.

I won't start c.l.c bare knuckle fight over this, but I prefer to
think of "The Rule" as semantics not syntax. I think it muddies other
waters to think of the class having "special syntax" when it is the
meaning of writing the array name that matters.

 

[Ben Bacarisse]

I won't start c.l.c bare knuckle fight over this, but I prefer to
think of "The Rule" as semantics not syntax. I think it muddies other
waters to think of the class having "special syntax" when it is the

"call"

meaning of writing the array name that matters.

Most of my typos can be corrected by guessing but that one seemed to
merit a correction.

 

[Julienne Walker]

bartc said:

Yes, bug.

And in any case what is actually passed is a value.

Right, *if* they can persuade ISO to muddy the waters in that way.

K&R muddied the waters themselves.  bartc should have illustrated the
point with an array rather than a hypothetical struct syntax:

#include <stdio.h>

void byref(int v[])
{
  v[0] = 42;

}

int main(void)
{
  int vec[] = {1, 2, 3};
  byref(vec);
  printf("vec[0] = %d\n", vec[0]);
  return 0;

}

This passes almost every test for "pass by reference" one can think
of.  There is no special syntax in the called function and none
needed at the point of call.  The parameter declaration can even look
like an array.

The only test it fails is that C does not have pass by reference!

That particular test fails completely in my opinion. For true pass-by-
reference to be present, regardless of syntax, I would expect to
receive an object that's functionally identical to the original
object. Even when hiding the pointer away with array notation, it
still isn't pass-by-reference simply because one can't get the size of
the array with any meaningful result.

A better test would pass a pointer to the array:

#include <stdio.h>

void notbyref ( int v[] )
{
printf ( "%lu\n", (unsigned long)sizeof v );
v[0] = 42;
}

void bysimref ( int (*v)[3] )
{
printf ( "%lu\n", (unsigned long)sizeof *v );
(*v)[0] = 24;
}

int main ( void )
{
int vec[] = { 1, 2, 3 };

notbyref ( vec );
printf ( "vec[0] = %d\n", vec[0] );
bysimref ( &vec );
printf ( "vec[0] = %d\n", vec[0] );

return 0;
}

At least this way one can argue that the original object is available
such that after dereferencing the pointer, you have the functionally
identical behavior required to be called pass-by-reference. Though it
still requires pointer syntax, the syntax is especially awkward for
this case, and the size of the array needs to be specified explicitly
[1].

Personally, I have no problem with calling C's simulated reference
"pass-by-reference" as long as all parties understand that what really
happens is a pointer is passed by value. I believe that this is an
important distinction to make, and clears up several misconceptions
that result in broken code.

[1] Prior to C99. A VLA in C99 would remove the restriction of an
explicit array size at the function definition level.

 

[Nick Keighley]

spinoza1111 said:


(a) I challenge your claim - please provide statistics from an
independent study to support it;

Anecdotes:

I sometimes talk at a "design level" where I'm expressing my intent.
But "by reference" isn't high enough level for me!

Consider
success_t search (int *index, Dictionary *dict, Value val);

I'd quite happily say "A Dictionary is passed to the search function,
if the
search suceeds the function returns true and also returns the index
of the value found".

See no pointers or references

I quite like Ada's in, out and inout parameters. Though in practice I
don't use the terms. I suppose I still think in a Pascal-like way
and just treat C's pointers and The Rule as its slightly excentric
of providing me with what I want.

I've never found
swap (&a, &b);

either natural or elegant. I *might* say a and b were passed by
reference.

I want to pass an array so I use array notation
double sum (double vector[], size_t size);

even though some people would say it confuses things to
hide the pointer

 

[Richard Tobin]

Sure, to modify a variable set up as what is commonly referred to as
"by reference" in C, you must use a special notation.

Not merely to modify it, but to get its value, and to pass it to
the function in the first place.

Note that several languages provide pass-by-reference as an option
invoked by a special notation *at the interface definition*, but
simulating it in C requires a special notation at the interface,
at every call, and at every reference or modification of the
value. That seems to be going too far to call it pass-by-reference.

You could simulate it in Lisp by putting every variable in a cons;
would you call that pass-by-reference?

This is a
limitation of C, since the fact that you have to dereference gives you
a false power, eg., you can also get the address, and REALLY screw
EVERYTHING up.

You can take the address of any variable, and really screw things up.
That's just a consequence of C being a systems programming language.

Nonetheless, most C programmers call passing the variable with the
asterisk in the formal parameters as "by reference".

I've never heard anyone call it that except in arguments on
comp.lang.c. C provides you with the mechanism to achieve the effect
of pass-by-reference without providing it directly in the language.

-- Richard

 

[Ben Bacarisse]

On Aug 25, 7:16 am, Ben Bacarisse <[email protected]> wrote:

K&R muddied the waters themselves.  bartc should have illustrated the
point with an array rather than a hypothetical struct syntax:

#include <stdio.h>

void byref(int v[])
{
  v[0] = 42;

}

int main(void)
{
  int vec[] = {1, 2, 3};
  byref(vec);
  printf("vec[0] = %d\n", vec[0]);
  return 0;

}

This passes almost every test for "pass by reference" one can think
of.  There is no special syntax in the called function and none
needed at the point of call.  The parameter declaration can even look
like an array.

The only test it fails is that C does not have pass by reference!

That particular test fails completely in my opinion. For true pass-by-
reference to be present, regardless of syntax, I would expect to
receive an object that's functionally identical to the original
object. Even when hiding the pointer away with array notation, it
still isn't pass-by-reference simply because one can't get the size of
the array with any meaningful result.

Good point. I covered myself with "almost every test" but I had
forgotten about the size.

A better test would pass a pointer to the array:

Well then we are back to simulated pass by reference. I was going to
add "in my option" but I see it is yours too from the function name
"bysimref".

Personally, I have no problem with calling C's simulated reference
"pass-by-reference" as long as all parties understand that what really
happens is a pointer is passed by value. I believe that this is an
important distinction to make, and clears up several misconceptions
that result in broken code.

Agreed. Knowing how and when to use language informally is all part
of good communication. Even when teaching beginners I think one can
use the term provided that it is clear what it is a shorthand for. I
am pretty sure that I've told a student to "pass that by reference
because you need to the result out of the function". But I hope I'd
only say that sort of thing once it was clear that, in C, only values
are ever passed.

This is one of the those odd c.l.c debates where I don't think anyone
is disputing facts but simply disputing if the facts support a
particular turn of phrase.

<snip>

 

[Beej Jorgensen]

I've never heard anyone call it that except in arguments on
comp.lang.c. C provides you with the mechanism to achieve the effect
of pass-by-reference without providing it directly in the language.

I've heard instructors call it that while teaching... but I don't think
I've ever heard it in the working wild.

That being said, every C programmer I know would know exactly what you
were talking about if you mentioned "call by reference" in a C context.
If that ever happened.

Personally, I use the word "pointer" when talking about pointer
arguments to functions, but that's just my preference.

-Beej

 

[Richard Bos]

I'm not so sure. Or perhaps I am.

I clearly remember my Trinity College interview way back where
I repeatedly used the word "weight" in the presence of the
college's applied maths tutor, and he kept "correcting" me to
use the word "mass" given the context in which I was using it.

He was of course wrong. And I'm prepared to summon Usenet's
units troll if anyone dare disagree.

Were you applying for a science, a literature, or a sociology degree? If
the first, he was both correct and justified. If the second, he was
wrong. If the last, neither of you could possibly have been wrong,
because in that subject, anything goes.

Richard

 

[Phil Carmody]

Phil Carmody said: [...]
It appears that some people can't grasp the fact that one can
effect pass by reference by passing variables by address.

Only by torturing the concept of pass by reference beyond its yield
point.

Not in my opinion.

If passing the address of a variable were equivalent to
passing by reference, then the following program would print 42:

Strong assertion.

#include <stdio.h>

void byref(int *p)
{
p = 42; /* bug - p was *not* passed by reference. */
}

And completely unfounded. There's no definition of 'pass by reference'
which would justify your claim. You've just burnt a straw man.

[...]

The point, I think is that *just* passing the address of a variable
is insufficient to implement passing by reference in C.

You can never implement it, as you can't syntactically express it.
You can, however, emulate it.

To implement or emulate pass by reference in C, you have to (a)
pass the address of the object you want to pass by reference, and
(b) make sure that every reference within the function is explicitly
dereferenced.

(a) I agree with, but where on earth did (b) come from?
Why can't the callee use the address of the object it has been given
access to? All languages that I know which have a meaningful concept
of an address and which have pass by reference permit the callee to
have access to that address.

In languages that actually do implement pass by reference, you can
just pass the name of the object as an argument, and refer to the
parameter by name inside the function.

That's not pass by reference, that's pass by name. Some languages
implement both, and call them both pass by reference, but they are
clearly different mechanisms with clearly different syntax both at
the caller and the callee.

You've completely muddied the waters by going off in that direction.

Phil

 

[Chris M. Thomasson]

Phil Carmody said:





Only by torturing the concept of pass by reference beyond its yield
point. If passing the address of a variable were equivalent to
passing by reference, then the following program would print 42:

#include <stdio.h>

void byref(int *p)
{
p = 42; /* bug - p was *not* passed by reference. */

}

This might be a better "representation" of references:
______________________________________________________
#define ref *
#define toref &


void inc(int ref self)
{
int ref r1 = self;
int prev = ref r1;

ref self = 5;
assert(ref r1 == 5);

ref r1 = 6;
assert(ref self == 6);

ref self = prev + 1;
}


void foo()
{
int v = 0;

inc(toref v);
assert(v == 1);
}
______________________________________________________




lol.

 

[Keith Thompson]

Phil Carmody said: [...]
It appears that some people can't grasp the fact that one can
effect pass by reference by passing variables by address.

Only by torturing the concept of pass by reference beyond its yield
point.

Not in my opinion.

If passing the address of a variable were equivalent to
passing by reference, then the following program would print 42:

Strong assertion.

#include <stdio.h>

void byref(int *p)
{
p = 42; /* bug - p was *not* passed by reference. */
}

And completely unfounded. There's no definition of 'pass by reference'
which would justify your claim. You've just burnt a straw man.

[...]

The point, I think is that *just* passing the address of a variable
is insufficient to implement passing by reference in C.

You can never implement it, as you can't syntactically express it.
You can, however, emulate it.

Ok. It depends on what you mean by "implement" in this context, but I
won't get into that; I agree that "emulate" is a more apt word.

(a) I agree with, but where on earth did (b) come from?
Why can't the callee use the address of the object it has been given
access to? All languages that I know which have a meaningful concept
of an address and which have pass by reference permit the callee to
have access to that address.

Consider the following C++ code that uses pass-by-reference (using
printf rather than cout<< to keep the code as close to C as possible):

void foo(int& param) {
printf("Previous value of parameter is %d\n", param);
param = 42;
}
...
int x = 10;
foo(x);

Now consider the following nearly equivalent C code that emulates
pass-by-reference:

void foo(int *param) {
printf("Previous value of parameter is %d\n", *param);
*param = 42;
}
...
int x = 10;
foo(&x);

To emulate pass-by-reference, I had to (a) pass the address of x
rather than just x (more precisely, the address of x rather than
the value of x) and (b) inside foo, replace each occurrence of
``param'' by ``*param''. Certainly foo can examine the address
that was passed in; I didn't mean to imply that it couldn't.

That's not pass by reference, that's pass by name. Some languages
implement both, and call them both pass by reference, but they are
clearly different mechanisms with clearly different syntax both at
the caller and the callee.

You've completely muddied the waters by going off in that direction.

No, pass by name (or call by name) is a very different mechanism.
If a parameter is passed by name, then the argument *expression* is
re-evaluated each time the function refers to it; any side effects
of the argument expression may occur 0, 1, or arbitrarily many
times for a single call. This is typically implemented by passing
(a reference to) a chunk of code called a "thunk".

But that's not at all what I was talking about. All I meant was
that, in a language that directly implements pass by reference,
you can use the name of the object as an argument, as in the C++
example above.

 

[Flash Gordon]

I use __LINE__ in my code

Now try defining a variable named __LINE__...

for it to be "valid" they have to define what "valid" means.

Yes, and I've been saying that there is a reasonable definition of valid
which excludes it. Others seem to be saying that any reasonable
definition of valid would include it, and I obviously disagree with that.

 

[Flash Gordon]

It's a variable, and the name is syntactically valid.

Yes, but that is syntactic validity rather than validity in general.

A translation unit containing only the line...
int main;
is syntactically valid. However, try writing a program for a hosted
implementation where that is one of the translation units.

Of course.

OK, so on such an implementation, is _MAX_POWER valid as a variable
name? Just to avoid any get-out you might think of, the implementation
behaves as if that #define has been provided to all translation units
(which it is allowed to) and aborts compilation on any attempt to either
undefine or redefine it (which it is also allowed to).

Remember, the question simply asked about valid identifiers.
It should be pretty clear that it is, reserved for the implementation
because of the leading _, but it is a valid identifier.

Yes, which make it not unambiguously valid, since it might not be valid
(as in an attempt to use it as an identify might cause compilation to
abort with an error).

Onky if you read in more that what is being asked.

No, I think it is a perfectly reasonable interpretation of the word
valid in the context of a test on C. To the point where on a
non-multiple choice test where the question was...
Is _MAX_VALUE a valid identifier?
I would mark as "fail" an answer of "yes", even if the test was given to
a beginner. An answer of "no" would not get full marks either, but would
get some!

<snip>

I still say my interpretation is reasonable.

 

[Dennis \(Icarus\)]

OK, so on such an implementation, is _MAX_POWER valid as a variable name?
Just to avoid any get-out you might think of, the implementation
Sure.

behaves as if that #define has been provided to all translation units
(which it is allowed to) and aborts compilation on any attempt to either
undefine or redefine it (which it is also allowed to).

Didn't say it was a #define.

Yes, which make it not unambiguously valid, since it might not be valid
(as in an attempt to use it as an identify might cause compilation to
abort with an error).

Only if there is a conflict. That could hapen if the symbol is defined twice
or in conflicting ways, which is true of...well..any identifier. Whether
beginning with an underscore or not.

No, I think it is a perfectly reasonable interpretation of the word valid
in the context of a test on C. To the point where on a non-multiple choice
test where the question was...
Is _MAX_VALUE a valid identifier?
I would mark as "fail" an answer of "yes", even if the test was given to a
beginner. An answer of "no" would not get full marks either, but would get
some!

By failing "yes", you're saying no one can use it for defnition/declaration,
lhs, rhs- that there is no validity for such an identifier AT ALL. And that
is wrong. If you want to restrict validity to be what should be defined by
an application (keying off the identifies beginning with _ belonging to
implementation or all caps typically referring to macros) then that should
be part of the question. Otherwise, you're just asking what's a valid
identifer - regardless of context.

<snip>

I still say my interpretation is reasonable.

Never said it wasn't. But it does read more into the question that what was
asked.

Dennis