Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!apple!agate!shelby!msi.umn.edu!cs.umn.edu!!jdege
From: jdege@ (Jeff Dege)
Newsgroups: comp.lang.rexx
Subject: Re: exposing a stem passed as a arguement
Message-ID: <1990Nov1.025608.15601@cs.umn.edu>
Date: 1 Nov 90 02:56:08 GMT
References: <1990Oct31.173237.895@wrkgrp.uucp>
Sender: news@cs.umn.edu (News administrator)
Reply-To: jdege@donald.cs.umn.edu (Jeff Dege)
Organization: University of Minnesota, Minneapolis
Lines: 41
Nntp-Posting-Host: donald.cs.umn.edu

In article <1990Oct31.173237.895@wrkgrp.uucp> ets@wrkgrp.uucp (Edward T Spire) writes:
>The VM/CMS implementation seems to support a syntax which doesn't
>look legal with respect to Cowlishaw's definition of the language:
>
>name: arg stem .
>      interpret 'procedure expose' stem'.'
>
>Cowlishaw specifies that "(the procedure instruction) must be the
>first instruction executed after the call or function invocation",
>so how can that arg instruction sit between the procedure name and
>the interpreted procedure instruction?
>
>I tried this under Unix and it doesn't work.  What I had to do was
>
>name: interpret 'procedure expose' arg(1)'.'
>
>It's still shakey that this works at all, since one could argue that
>the interpret instruction is "between" the label and the procedure
>instruction, but I suppose one could also argue that the interpret
>instruction isn't actually executed at all, and that it's operand
>instruction(s) are.
>
>Can anyone explain why the former works?
>Is this kind of thing in common use?
>Anybody know how the other implementations stack up on this?
>Anybody know of other things that work when the language spec says
>they should not?
>
>Any comments would be greatly appreciated.
>
  I tried this using Arexx version 1.10 (the Amiga version of REXX, and
got similar behavior.  "name: arg stem; ..." successfully exposed the
stem variable passed, but lost the 'stem' variable inside the routine,
so you couldn't access it.  I.e., with "foo. = 0; call name foo", 
foo. is exposed, but stem is hidden after the procedure command, so
I can't access it.  Using arg(1), it all works fine.
 
  I'd been looking for a way to pass a stem variable to a function,
this may be it.  Seems a bit twisted, though...
 
-------------------------------------