Assignment to pointer parameters

[August Karlstrom]

In the programming language C the pointer base type of a formal pointer
parameter can be write-protected by adding the keyword `const' before
the parameter*, for instance

typedef struct { ... } *T;

int F(const T x);

In Oberon-07/14, does the "constantness" of a formal pointer value
parameter apply only to the pointer or does it also extends to the
record it points to? For instance, in the declaration of F below, can
fields of x be assigned to from within F or do we need to make x a
variable parameter to do so?

T = POINTER TO RECORD ... END

PROCEDURE F(x: T): INTEGER


-- August


*Of course, all type rules can be violated in C if the implementor wants
to do so.

[August Karlstrom]

Post by August Karlstrom
typedef struct { ... } *T;
int F(const T x);

Correction: We want x to point to a constant object but the declaration
above says that the pointer itself is constant, so it should be

struct T { ... };

int F(const struct T *x);


-- August

[c***@gmail.com]

Post by August Karlstrom
In Oberon-07/14, does the "constantness" of a formal pointer value
parameter apply only to the pointer or does it also extends to the
record it points to? For instance, in the declaration of F below, can
fields of x be assigned to from within F or do we need to make x a
variable parameter to do so?
T = POINTER TO RECORD ... END
PROCEDURE F(x: T): INTEGER

I tested your example with Wirth's 2014 RISC5 FPGA Oberon compiler and in that implementation the "constantness" only applies to the pointer. The public fields of x can be assigned to from within F. Our Astrobe 2014 Oberon compiler behaves the same way.

Note that this assumes that x is allocated as a global variable using NEW before F is called and not within F as a local variable.

If you want to protect the fields of x you could declare T in a separate module and not mark its fields as public.

Regards,
Chris Burrows

CFB Software
Astrobe: Oberon for ARM Cortex-M3 and M4
http://www.astrobe.com

[August Karlstrom]

Post by c***@gmail.com

Post by August Karlstrom
In Oberon-07/14, does the "constantness" of a formal pointer value
parameter apply only to the pointer or does it also extends to the
record it points to? For instance, in the declaration of F below,
can fields of x be assigned to from within F or do we need to make
x a variable parameter to do so?
T = POINTER TO RECORD ... END
PROCEDURE F(x: T): INTEGER

I tested your example with Wirth's 2014 RISC5 FPGA Oberon compiler
and in that implementation the "constantness" only applies to the
pointer. The public fields of x can be assigned to from within F. Our
Astrobe 2014 Oberon compiler behaves the same way.

OK, that's what I thought. My doubt was because I was involved in a
discussion in the Astrobe forum some time ago about exported pointer
variables. The question was whether exported fields in a record pointed
at by an exported pointer be writable or not in a client module. I
reasoned that only the pointer is read-only exported but not the
exported fields. If I remember correctly you made a different
interpretation.

Post by c***@gmail.com
Note that this assumes that x is allocated as a global variable using
NEW before F is called and not within F as a local variable.

Indeed.

Post by c***@gmail.com
If you want to protect the fields of x you could declare T in a
separate module and not mark its fields as public.

Yes, of course. In this case I only needed some clarification of
language semantics.


Regards,
August

[c***@gmail.com]

Post by August Karlstrom
OK, that's what I thought. My doubt was because I was involved in a
discussion in the Astrobe forum some time ago about exported pointer
variables. The question was whether exported fields in a record pointed
at by an exported pointer be writable or not in a client module. I
reasoned that only the pointer is read-only exported but not the
exported fields. If I remember correctly you made a different
interpretation.

That is a different question. The discussion you refer to is at:

http://www.astrobe.com/forum/viewtopic.php?f=4&t=176

Attempts to *directly* modify the public fields of variable records exported from a module via a pointer result in a "read only" compile-time error in both compilers e.g.

M.x.i := 999;

where M is the module name, x is the pointer varaiable of type T and i is a record field.

However, it is possible to circumvent this protection even for exported variables by passing M.x as a value parameter to a procedure in the client module e.g.

PROCEDURE F(x: M.T);
...
...
x.i := 999;

As before, if you want to protect the record element from being modified by an importing module then don't make it public.

Regards,
Chris

[August Karlstrom]

Post by c***@gmail.com
Attempts to *directly* modify the public fields of variable records
exported from a module via a pointer result in a "read only"
compile-time error in both compilers e.g.
M.x.i := 999;
where M is the module name, x is the pointer varaiable of type T and i is a record field.
However, it is possible to circumvent this protection even for
exported variables by passing M.x as a value parameter to a procedure
in the client module e.g.
PROCEDURE F(x: M.T); ... ... x.i := 999;

Unless the read-only property of x was indeed extended to hold for the
record as well. Your example implies the usefulness of read-only records
in pointer parameter contexts (even if Wirth has not designed Oberon
this way).


-- August

[y***@z505.com]

Post by August Karlstrom
In Oberon-07/14, does the "constantness" of a formal pointer value
parameter apply only to the pointer or does it also extends to the
record it points to? For instance, in the declaration of F below, can
fields of x be assigned to from within F or do we need to make x a
variable parameter to do so?
T = POINTER TO RECORD ... END
PROCEDURE F(x: T): INTEGER

Speaking of pointers... Are pointers the new GOTO of programming... GOTO considered harmful... Pointers considered harmful? The relational model in TutorialD by Darwen and Date, tries to get rid of pointers and use high level code... should oberon be doing the same? Well I think pointers may still be needed (not sure) for systems programming. How does Go Language deal with pointers? I'm looking into it..

Are the days of dereferencing pointers over? should they be?

Should pointers be considered only part of the "system" unit and all other high level code should try to avoid pointers?

Delphi has tried to get rid of pointers by using classes on the heap that need no dereferencing.. But what you see happening is people still think about the pointers sometimes. On newsgroups and mailing lists you'll see delphi experts explaining how classes work with regards to pointers, for example when someone passes a class in as a VAR param it gets confusing (pointer to pointer to.. ). Is this all harmful stuff we should be avoiding, or are pointers a necessary evil?

I certainly enjoy pointers as a mind puzzle - but this doesn't mean they are beneficial. They could be like a mutation or a cancer that is fun to study, but bad to have...

I'm not certain, which is why I'm opening this discussion. If Dijkstra was alive right now, would he have written an article called Pointers Considered Harmful? I believe Hoare has written something on this subject, but not sure - and Date and Darwen have written about it in TutorialD.

Regards,
Z505 Software
Trying to put Rigor into computing science
Since it's not a science, it's a farce.
Computing farce is what it should be called.

[August Karlstrom]

Post by y***@z505.com
Speaking of pointers... Are pointers the new GOTO of programming...
GOTO considered harmful... Pointers considered harmful?

In Oberon (Oberon-07/15) they are restricted to point to RECORDS to
enable building
dynamic data structures like lists and trees. What alternative do you
propose for Oberon?

Post by y***@z505.com
Delphi has tried to get rid of pointers by using classes on the heap
that need no dereferencing..

I guess the dereferencing is implicit then, like in Oberon?

Post by y***@z505.com
But what you see happening is people still think about the pointers
sometimes. On newsgroups and mailing lists you'll see delphi experts
explaining how classes work with regards to pointers, for example
when someone passes a class in as a VAR param it gets confusing
(pointer to pointer to.. ). Is this all harmful stuff we should be
avoiding, or are pointers a necessary evil?

In Oberon you seldom need to define a procedure with a variable pointer
parameter.

Post by y***@z505.com
I certainly enjoy pointers as a mind puzzle - but this doesn't mean
they are beneficial. They could be like a mutation or a cancer that
is fun to study, but bad to have...

I you use an abstract data type defined as a pointer, like for instance
a list, in the "worst" case the only pointer specific operation that you
need is the predefined procedure NEW:

list: Lists.List

NEW(list);
Lists.Init(list);
Lists.Insert(37, list);
...

Post by y***@z505.com
I'm not certain, which is why I'm opening this discussion. If
Dijkstra was alive right now, would he have written an article
called Pointers Considered Harmful? I believe Hoare has written
something on this subject, but not sure - and Date and Darwen have
written about it in TutorialD.

Tony Hoare wrote about the "misstake" of inventing the NIL pointer.


-- August

[y***@z505.com]

Post by August Karlstrom

Post by y***@z505.com
Speaking of pointers... Are pointers the new GOTO of programming...
GOTO considered harmful... Pointers considered harmful?

In Oberon (Oberon-07/15) they are restricted to point to RECORDS to
enable building
dynamic data structures like lists and trees. What alternative do you
propose for Oberon?

Possibly keep pointers for when you rarely need them (but we could also argue that GOTO statement is needed sometimes... so keep it as a feature?)

With regards to data structures, trees, lists... Again sometimes this is reinventing the database (relational model). The relational model may have to be implemented using pointers, but ultimately high level programmers should be using the relational model for many data solutions instead of resorting to arrays of things, lists, xml trees... Every time I use a TStringList in delphi, I end up reinventing a database... because the database is too difficult to set up and send strings to (SQL server) hence TutorialD tries to solve this problem by allowing the relational model right inside your program itself!

This is discussed at:

http://c2.com/cgi/wiki?DatabaseType

Which is similar to TutorialD

However, likely pointers are still needed in order to implement tutorialD itself , or the relational model. But the question is, once we have implemented the relational model into our programs, do we use the pointer less and less, and relegate a lot of our datastructures over to the relational model, instead of using cavemen arrays, pointers to arrays, pointers to records, ... no more "for loops" of going through an array one by one.. you just use the relational model to access your data.

Microsoft LINQ project is a joke. That's not what I'm proposing.

It has to be based on computing science, not some marketing hype like DOT NET.

Regards,
Z505 Software
Trying to put rigor into "computing science"
There is no science right now, it's a "computing farce"