On Apr 15, 10:31 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Perhaps we should say that R1,R2,R3 are relation symbols within the RA
expression, and under an interpretation these symbols are given
relation values. In that context, it appears that an RA expression is
treated just like an FOL term.

Indeed to highlight the potential confusion consider this. One could
write the following formula in a FOL with equality:

for all R1, R2, R1 join R2 = R2 join R1

and in that formula R1,R2 are (bound) FOL variables and the FOL terms
on the two sides of '=' are RA expressions. So even though on the one
hand we often think of a correspondence between RA expressions and FOL
formulas, within this FOL formula they are instead FOL terms. One
presumably might refer to R1 and R2 as "relation variables".

So it seems that "relation variable" can be overloaded for two
distinct purposes. When I see "relvar" I assume there is a physical
database that holds particular named relation values at each moment in
time. In that case we have a concept of assignable relvars accessible
by some imperative language. The language is necessarily at least
partly imperative because an assignment statement is by definition
imperative.

I'm not sure what you mean by saying that a relvar is a pointer. What
does it point at? Or do you mean a relvar name is like a pointer that
points at an assignable variable within a physical database?


Yes by treating relation names as either FOL function symbols or FOL
variables and by treating RA expressions as FOL terms.

David BL wrote:
....
Nor I you. As I said, a relvar is a pointer, so not it's confusing to
say it's 'like' one. I thought it 'pointed' to a value, maybe there is
some cultural language nuance that I'm not able to comprehend that
somehow makes a difference in the eyes of some beholder or othe. Maybe
Bob B can explain the difference between a relational pointer and some
other kind of pointer but I would have thought the difference was patent
regardless of context. (I think 'assignment' is a difficult notion but
am glad you mentioned it.) Personally, for practial reasons if none
other, I would prefer to think of a pointer as being a pointer,
regardless of cultural context.

On Apr 16, 10:52 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Below 'variable' is restricted to something that can be accessed by
imperative statements, and not to be confused with a FOL variable.

I don't say a variable points at a value. I say a variable *holds* a
value. I restrict my usage of the word "pointer" to mean a *value*
that represents an address or you could say an identifier for a
variable. So a pointer points at a variable, not directly at a
value.

E.g. In C++

int x = 10;
int* p = &x;

x is not a pointer. x is a variable that holds the value 10. p is a
pointer variable that holds a pointer value. The pointer value points
at the variable named x. There is no concept of a pointer value that
points at the value 10. I don't understand what that could mean.
Note that C++ outlaws the expression &10.

David BL wrote:
....
What has C++ got to do with any algebraic language? What does
assignment have to do with any algebraic language?

(Regarding C++ I would say a more apt comparison with algebra symbols
would be "const int x = 10;").

On Apr 17, 8:14 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
Nothing, as also "pointer" has nothing to do with any algebraic
language.

My interpretation of the conversation is:

1) As far as RA being a pure algebra is concerned I incorrectly stated
that R1,R2,R3 were relvar names. I acknowledged that in a subsequent
post where I instead suggested R1,R2,R3 represent FOL function symbols
or else FOL variables. In the case that they are function symbols, it
can be the case that the intention is for them to be given the current
values of the physical database relvars of the same name under
interpretation.

2) You corrected me, but in doing so incorrectly claimed that relvars
are pointers, when really they are just assignable variables that hold
relation values in the context of an imperative language.

3) I proceeded to talk about what "pointer" means (a value that
identifies a variable in the context of an imperative language).

4) You appear to think incorrectly that I'm talking about pointers in
the context of an algebra.


I wasn't making any comparison with algebra symbols.

David BL wrote:

Good point. (You must be a good pointer.)

Meanwhile, in Algol 68,

INT x := 10

is a shorthand for

REF INT x = LOC INT; x := 10

i.e. a variable is of type reference to integer (Algol 68 doesn't use
the term 'pointer'.) This is because

INT x = 10

defines a *constant* x with the value 10. (The original C doesn't have
constants.) So Algol 68 essentially agrees with paul's terminology,
except that it uses 'reference' for 'pointer'.

--
Reinier

Reinier Post wrote:
Yes, if you change the terms of reference, I'd bet you could always turn
the meaning of a term into something that is contrary on some surface or
other. It always seemed to me that a C "variable" had effectively the
same result as a pointer did, perhaps because in my case the programming
background was assembler, so even when I look at C code, I see the
registers being loaded, either by an interpreter or effectively by a
compiler. If I had started with C, maybe my life would have been more
complicated because instead of registers I'd have a whole bunch of other
concepts to master, such as "holding a value"! Can't prove it but I
suspect most problems of this kind will be solved when enough
generations pass, even if others arise.

On Apr 21, 8:39 am, r... (AT) raampje (DOT) lan (Reinier Post) wrote:
In C: There is the necessity of sprinkling "salt" and "pepper" over C
code in the form of the "*" and "&" operators in order to get the
dereferencing "just right". See code specimens included below for a
comparison....

Algol68 has endeavored to minimise the condiments in the actual code,
and - typically - automatically dereferences "pointers" to the actual
data.

But A68 still needs some condiments, eg Compare the specimen code
extracts where a "pointer" is dereferenced for assignment.
C: ***r = 666; /* C needs to be instructed how to
dereference to the get the right outcome. */
A68: REF INT(r):=666; ¢ In this case Algol68 needs to be told what
outcome "type" is required for the LHS ¢

[ Imagine doing this in C: *(int*)r = 666; /* a big contrast with no
warning msg! */ ]

Ironically GCC actually knows what type is required and warns the
coder if the "***r=10" is incorrectly coded as "r=10". But things can
get spicy in C if there is not enough salt. :-) eg:


In A68, if the "REF INT(" condiment is missing on the assignment then
the coder would get the following "type syntax error" message, eg:
r := 666;
Code specimens with output:
code: - - - - 8>< - - - - - - - -
$ cat is.c
#include <stdio.h>
main(){
int x;
int *p = &x;
int **q = &p;
int ***r = &q;

x=10;
***r = 666;

if(*p == x ) printf("*p == x\n");
if(**q == x ) printf("**q == x\n");
if(***r == x ) printf("***r == x\n");
if(**r == &x ) printf("**r is x\n");
}

output: - - - - 8>< - - - - - - - -
$ gcc is.c -o is; ./is
*p == x
**q == x
***r == x
**r is x

code: - - - - 8>< - - - - - - - -
$ cat ./is.a68
main
INT x;
REF INT p := x;
REF REF INT q := p;
REF REF REF INT r := q;

x:=10; ¢ OK ¢
REF INT(r) := 666; ¢ dereference required ¢

IF p = x THEN printf($"p = x"l$) FI;
IF q = x THEN printf($"q = x"l$) FI;
IF r = x THEN printf($"r = x"l$) FI;
IF r IS x THEN printf($"r IS x"l$) FI
)

output: - - - - 8>< - - - - - - - -
$ a68g ./is.a68
p = x
q = x
r = x
r IS x

--
To download Linux's Algol68 Compiler, Interpreter & Runtime:
* http://sourceforge.net/projects/algol68