further questions about Oberon-07

[nojb]

Hello,

More questions about he Oberon-07 report:

1. Consider:

MODULE M;
VAR
P : PROCEDURE;
Q : PROCEDURE;
BEGIN
P := Q
END M.

I guess this means that P becomes Q, but just syntactically it looks
like we are actually calling Q (never mind is undefined in this
particular program).
This means that the meaning of "Q" depends on what "P" is?

2. Since by Oberon-07 report the only allowed variable access is
global and strictly local, why are function pointers
restricted to global procedures? It would seem that there would be
absolutely no problem implementing function pointers to
nested procedures as well, since there is no need to carry non-local
variables along...

Thanks!
N

[Pascal J. Bourguignon]

Post by nojb
MODULE M;
VAR
P : PROCEDURE;
Q : PROCEDURE;
BEGIN
P := Q
END M.
I guess this means that P becomes Q, but just syntactically it looks
like we are actually calling Q (never mind is undefined in this
particular program).
This means that the meaning of "Q" depends on what "P" is?
2. Since by Oberon-07 report the only allowed variable access is
global and strictly local, why are function pointers
restricted to global procedures? It would seem that there would be
absolutely no problem implementing function pointers to
nested procedures as well, since there is no need to carry non-local
variables along...

That's the reason why! Because they need to carry local variables
along. I don't know what you mean by "strictly local". My copy of
Oberon07.Report.pdf says that:

In addition to its formal parameters and locally declared objects,
the objects declared in the environment of the procedure are also
visible in the procedure (with the exception of variables and of
those objects that have the same name as an object declared
locally).

Namely, the variables local to their englobing function(s), but not
local to themselves. What would be needed for this, is a closure.
These free variables would have to be allocated somewhere else than on
the stack, since they would be created and used dynamically, when the
function(s) that uses them are returned and called. Therefore you'd
need a garbage collector and you'd find yourself on the slippery
slope toward lisp (or haskell).

[Chris Burrows]

Post by Pascal J. Bourguignon
I don't know what you mean by "strictly local". My copy of
In addition to its formal parameters and locally declared objects,
the objects declared in the environment of the procedure are also
visible in the procedure (with the exception of variables and of
those objects that have the same name as an object declared
locally).

Non-global variables can either be declared in an enclosing procedure or
declared in the procedure itself. If they are declared in a procedure itself
then they are "strictly local" to that procedure.

In the document:

http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/OberonSummary.pdf

it states: "No access to variables that are neither global nor strictly
local." I can understand how the quoted section of the Oberon-07 report
could be misinterpreted. Perhaps it should have been written as:

... are also visible in the procedure (with the exception of variables and
with the exception of those objects that have the same name as an object
declared locally).

Regards,
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07 Development System
http://www.astrobe.com

[nojb]

Dear Pascal,

Thank you for your answer. Somehow I still do not understand.
Procedure bodies in Oberon-07 can only refer to local variables
of itself (which are always allocated on the stack)
or global variables (which are global), so there doesn't seem to
be a need to dynamically allocate anything...

Sorry; I know I am probably missing something, but I can't see it
right now.

To make sure that we are talking about the same thing, here is an
example I would like to understand:

MODULE M;

VAR
H : PROCEDURE (VAR A : INTEGER; B : INTEGER);
X : INTEGER;

PROCEDURE F : PROCEDURE (VAR A : INTEGER; B : INTEGER);

PROCEDURE G (VAR A : INTEGER; B : INTEGER);
BEGIN
A := B
END G;

BEGIN
RETURN G
END F;

BEGIN
H := F;
H (X, 123)
END M.

Why is this not allowed?

Also, this is also a good example for my question 1 in the previous
message:
If it were legal, how do we know wether H := F; means to assign F to
the
procedure variable H or to invoke F and assign its result to H ?

Thank you very much for your help!
N

Post by nojb
MODULE M;
VAR
  P : PROCEDURE;
  Q : PROCEDURE;
BEGIN
  P := Q
END M.
I guess this means that P becomes Q, but just syntactically it looks
like we are actually calling Q (never mind is undefined in this
particular program).
This means that the meaning of "Q" depends on what "P" is?
2. Since by Oberon-07 report the only allowed variable access is
global and strictly local, why are function pointers
restricted to global procedures? It would seem that there would be
absolutely no problem implementing function pointers to
nested procedures as well, since there is no need to carry non-local
variables along...

That's the reason why!  Because they need to carry local variables
along.  I don't know what you mean by "strictly local".  My copy of
    In addition to its formal parameters and locally declared objects,
    the objects declared in the environment of the procedure are also
    visible in the procedure (with the exception of variables and of
    those objects that have the same name as an object declared
    locally).
Namely, the variables local to their englobing function(s), but not
local to themselves.  What would be needed for this, is a closure.
These free variables would have to be allocated somewhere else than on
the stack, since they would be created and used dynamically, when the
function(s) that uses them are returned and called.  Therefore you'd
need a garbage collector and  you'd find yourself on the slippery
slope toward lisp (or haskell).
--
__Pascal Bourguignon__                    http://www.informatimago.com/

[y***@z505.com]

Post by Pascal J. Bourguignon
Namely, the variables local to their englobing function(s), but not
local to themselves. What would be needed for this, is a closure.
These free variables would have to be allocated somewhere else than on
the stack, since they would be created and used dynamically, when the
function(s) that uses them are returned and called. Therefore you'd
need a garbage collector and you'd find yourself on the slippery
slope toward lisp (or haskell).
--
__Pascal Bourguignon__ http://www.informatimago.com/

Conspiracy theory Begin

Hmm, I'm wondering if you're trying to convert more people over to Lisp, by cleverly hanging out on these mailing lists/groups pretending you are an oberon programmer, but, every time someone comes up with a shortfall of oberon... You play along and say just write an oberon library, ... only for the person to eventually figure out that Lisp is superior because it allows you to do everything including the kitchen sink (like Emacs). This reminds me of someone who hangs around Vi mailing lists trying to secretly convert people to Emacs when those vi users figure out the limitatons of Vi.

Conspiracy theory End.

Regards,
Z505 Software
Skeptic of Human Intentions

[Chris Burrows]

Post by nojb
Hello,
MODULE M;
VAR
P : PROCEDURE;
Q : PROCEDURE;
BEGIN
P := Q
END M.
I guess this means that P becomes Q, but just syntactically it looks
like we are actually calling Q (never mind is undefined in this
particular program).
This means that the meaning of "Q" depends on what "P" is?

If it is a procedure call then you need the empty parentheses. The following
alternative example should help to illustrate the difference. This compiles
OK:

MODULE M;
VAR
P : PROCEDURE(): INTEGER;
Q : PROCEDURE(): INTEGER;
I : INTEGER;
BEGIN
P := Q;
I := Q()
END M.

However, both of the statements:

P := Q();
I := Q;

would result in an "incompatible assignment" error.

Regards,
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07
http://www.astrobe.com

[nojb]

Post by Chris Burrows

Post by nojb
Hello,
MODULE M;
VAR
 P : PROCEDURE;
 Q : PROCEDURE;
BEGIN
 P := Q
END M.
I guess this means that P becomes Q, but just syntactically it looks
like we are actually calling Q (never mind is undefined in this
particular program).
This means that the meaning of "Q" depends on what "P" is?

If it is a procedure call then you need the empty parentheses. The following
alternative example should help to illustrate the difference. This compiles
MODULE M;
VAR
  P : PROCEDURE(): INTEGER;
  Q : PROCEDURE(): INTEGER;
  I : INTEGER;
BEGIN
  P := Q;
  I := Q()
END M.
  P := Q();
  I := Q;
would result in an "incompatible assignment" error.
Regards,
Chris Burrows
CFB Software
Astrobe: ARM Oberon-07http://www.astrobe.com

Dear Chris,

Thanks!

Am I correct then in assuming that the parenthesis are
needed every time we want to invoke a function that has an
empty formal parameter list?

Thanks again,
N

[Chris Burrows]

Post by nojb
Am I correct then in assuming that the parenthesis are
needed every time we want to invoke a function that has an
empty formal parameter list?

Invoking functions - yes; proper procedures - no. You can invoke a proper
procedure (i.e. one that doesn't return a result) which has an empty
parameter list, with or without the parentheses.

Chris