why no function(parm)^ in the Modula-2 language 
Author Message
 why no function(parm)^ in the Modula-2 language

Does anybody know why Wirth designed Modula-2 deliberately so that you can't
indirect through a function call?  If you have a procedure that returns a
pointer to something you cannot use an expression like  a := func(b)^;
You can indirect through variables, but not function calls.  I have often
wanted to do this, as it can make cascaded functions awkward to write, and
creates unnecessary variables.  I think C can do this, so I have always been
curious about this probably deliberate language omission.

edj



Thu, 20 May 2004 07:17:16 GMT  
 why no function(parm)^ in the Modula-2 language

Quote:

> Does anybody know why Wirth designed Modula-2 deliberately so that you can't
> indirect through a function call?  If you have a procedure that returns a
> pointer to something you cannot use an expression like  a := func(b)^;

It comes solely from the syntax of Modula-2, i.e. the syntax for
designators does not include function calls or other expressions.
This restriction/simplification was included for better readability
and to reduce ambiguities. Pascal and Oberon have the same restriction.

See how simple a designator is in the syntax of Modula-2:

   Designator = QualIdent
              | Designator "." Identifier
              | Designator "[" ExpressionList "]"
              | Designator "^" .

You are always starting with a qualified identifier designating a
variable and optionally specify subcomponents of it or takes it as a
starting point for a path (in case of "^").

If you want to permit a construct like func(b)^ you could try to
change the syntax to

   Designator = QualIdent
              | Designator "." Identifier
              | Designator "[" ExpressionList "]"
              | Expression "^" .

Now you could even write constructs like

   func(b)^ := a;

or even

   FunctionReturningAFunction(a)(b)^ := c;

Unfortunately, it isn't that easy. Take a look at following IF statement:

   IF a = b^ THEN (* ... *) END;

Is this (a = b)^ or a = (b^)? In Modula-2 "^" isnt't in conflict with
the other operators but now it is. The only practical solution is to
include "^" (and similarly "[]" and ".") to the operators
in the syntax for expressions. Designator can be dissolved then, just
replace Designator by QualIdent in Factor.

Now you can even write nice statements like

   1 := 2;

and wait for semantic error messages for things which would have
been caught before by the syntax.

Quote:
> I think C can do this, so I have always been
> curious about this probably deliberate language omission.

The unary ``*'' in C accepts arbitrary pointer expressions including
function results. But we know all that readability wasn't the top
priority in the design of C. Neither a syntax which supports good
error handling.

Andreas.

--
Andreas Borchert, Universitaet Ulm, SAI, Helmholtzstr. 18, 89069 Ulm,  Germany

WWW:    http://www.mathematik.uni-ulm.de/sai/borchert/
PGP:    http://www.mathematik.uni-ulm.de/sai/borchert/pgp.html



Thu, 20 May 2004 11:44:08 GMT  
 why no function(parm)^ in the Modula-2 language

Quote:


>> Does anybody know why Wirth designed Modula-2 deliberately so that you can't
>> indirect through a function call?  If you have a procedure that returns a
>> pointer to something you cannot use an expression like  a := func(b)^;

> It comes solely from the syntax of Modula-2, i.e. the syntax for
> designators does not include function calls or other expressions.
> This restriction/simplification was included for better readability
> and to reduce ambiguities. Pascal and Oberon have the same restriction.

Modern Pascal's (like FPC, Delphi) support it though. A lot of proper (e.g.
extended) ones support it as extension.


Fri, 21 May 2004 17:59:18 GMT  
 why no function(parm)^ in the Modula-2 language



Quote:


> >> Does anybody know why Wirth designed Modula-2 deliberately so that you
can't
> >> indirect through a function call?  If you have a procedure that returns
a
> >> pointer to something you cannot use an expression like  a := func(b)^;

> > It comes solely from the syntax of Modula-2, i.e. the syntax for
> > designators does not include function calls or other expressions.
> > This restriction/simplification was included for better readability
> > and to reduce ambiguities. Pascal and Oberon have the same restriction.

> Modern Pascal's (like FPC, Delphi) support it though. A lot of proper
(e.g.
> extended) ones support it as extension.

It's the case in Component Pascal too, without problems. Function calls are
allowed in designators, but not general expressions.


Sat, 22 May 2004 06:03:47 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Passing parm hex parm to STCKCONV

2. C functions with variable parm lists

3. why why why oh why why baby

4. Language question : function'Access / function'unchecked_Access

5. Compilers (was: Why no ** operator in Modula 2)

6. Why Modula-2?

7. Why do we need to learn Modula-2?

8. Why Modula-2

9. Why should I use Modula-2

10. App to App parm passing in 2.003

11. InputBox 3rd parm

12. How to Pass parm to PRO*CoBOL program in UNIX environment

 

 
Powered by phpBB® Forum Software