home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.modula2
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ira.uka.de!math.fu-berlin.de!news.belwue.de!theorie!titania.mathematik.uni-ulm.de!borchert
- From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
- Subject: Re: Oberon vs Modula-2
- Message-ID: <1992Nov20.131039.1764@informatik.uni-ulm.de>
- Sender: usenet@informatik.uni-ulm.de (Name for nntp-posting)
- Nntp-Posting-Host: titania.mathematik.uni-ulm.de
- Organization: University of Ulm, SAI
- References: <1992Nov13.130852.22775@jyu.fi> <1992Nov16.080647.26783@informatik.uni-ulm.de> <1992Nov17.155855.4413@let.rug.nl> <1992Nov19.104407.338@jyu.fi>
- Date: Fri, 20 Nov 92 13:10:39 GMT
- Lines: 28
-
- In article <1992Nov19.104407.338@jyu.fi>, sakkinen@jyu.fi (Markku Sakkinen) writes:
- > Fortran, I think, has a rule stating that if a formal parameter is
- > modified within a subprogram, the corresponding actual parameter must
- > not be the same as any other actual parameter in the call.
- > Does Modula-2 or Oberon have a similar rule? (Value parameters need
- > not be considered, but constant parameters would if passed by reference.)
-
- I'm not familiar with Fortran but neither Modula-2 nor Oberon have
- a rule which forbid to pass the same actual parameter to two or more
- parameters, i.e.
-
- PROCEDURE p(VAR x, y: INTEGER); BEGIN ... END p;
- (* ... *)
- p(i, i);
-
- is legal.
-
- > Of course, those breaches of the rule that cannot be detected at compile
- > time could be too expensive to catch at run time.
-
- That's the problem and I still don't see a better solution by
- use of constant attributes for parameters.
-
- --
- _______________________________________________________________________________
-
- Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
- Internet: borchert@mathematik.uni-ulm.de
-