Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
parse multiple values
92 views
Skip to first unread message
Glenn Knickerbocker
Mar 13, 2012, 2:27:00 PM3/13/12
to
Not a how-to but a why-the-heck-not? inspired by current discussion on
the TSOREXX list. A time-honored way of swapping variables around is to
put them into an expression for PARSE:
Parse Value x y z With z x y
When the values aren't single words, we can play games with delimiters:
Parse Value x':'y':'z with z ':' x ':' y
But of course this depends on knowing a delimiter that will never occur
within your values. A simple and obvious extension to the PARSE syntax
that would eliminate the guessing games is for PARSE VALUE to take a
comma-separated list to be parsed with multiple templates like ARG:
Parse Value x, y, z With z, x, y
(I thought about extending PARSE VAR similarly but the syntax got less
obvious and it doesn't really provide any different function anyway.)
A less trivial extension would be to provide the result of allItems for
a single variable or expression starting in the second value:
Parse Var x. xdefault, x1, x2, x3, etc.
Parse Value f(x) With fclass, f1, f2, etc.
My "etc." above is just intended to represent any further combination of
templates, but it suggests another extension that's been wanted for a
long time even in the non-object world: Parse all the remaining values
into a stem. In Object Rexx, it could be any other collection object,
so the syntax could include the class:
Parse Value f(x) With fclass, .stem(f.)
For stems, this could include putting the count of items in stem.0, the
way some external programs (like EXECIO and PIPE on CMS) do. Missing
values should remain unassigned (and the count for the stem would be the
highest-numbered argument present rather than the number of items).
ŹR >@< >@< >@< >@< >@< http://users.bestweb.net/~notr/chewy.html
I think you're telling me that, if you know the secret spells, you can
actually force Windows into behaving rationally. -- Rob Bannister
the TSOREXX list. A time-honored way of swapping variables around is to
put them into an expression for PARSE:
Parse Value x y z With z x y
When the values aren't single words, we can play games with delimiters:
Parse Value x':'y':'z with z ':' x ':' y
But of course this depends on knowing a delimiter that will never occur
within your values. A simple and obvious extension to the PARSE syntax
that would eliminate the guessing games is for PARSE VALUE to take a
comma-separated list to be parsed with multiple templates like ARG:
Parse Value x, y, z With z, x, y
(I thought about extending PARSE VAR similarly but the syntax got less
obvious and it doesn't really provide any different function anyway.)
A less trivial extension would be to provide the result of allItems for
a single variable or expression starting in the second value:
Parse Var x. xdefault, x1, x2, x3, etc.
Parse Value f(x) With fclass, f1, f2, etc.
My "etc." above is just intended to represent any further combination of
templates, but it suggests another extension that's been wanted for a
long time even in the non-object world: Parse all the remaining values
into a stem. In Object Rexx, it could be any other collection object,
so the syntax could include the class:
Parse Value f(x) With fclass, .stem(f.)
For stems, this could include putting the count of items in stem.0, the
way some external programs (like EXECIO and PIPE on CMS) do. Missing
values should remain unassigned (and the count for the stem would be the
highest-numbered argument present rather than the number of items).
ŹR >@< >@< >@< >@< >@< http://users.bestweb.net/~notr/chewy.html
I think you're telling me that, if you know the secret spells, you can
actually force Windows into behaving rationally. -- Rob Bannister
Jeremy Nicoll - news posts
Mar 13, 2012, 2:43:39 PM3/13/12
to
Glenn Knickerbocker <No...@bestweb.net> wrote:
> Not a how-to but a why-the-heck-not? inspired by current discussion on the
> TSOREXX list. A time-honored way of swapping variables around is to put
> them into an expression for PARSE:
>
> Parse Value x y z With z x y
>
> When the values aren't single words, we can play games with delimiters:
>
> Parse Value x':'y':'z with z ':' x ':' y
>
> But of course this depends on knowing a delimiter that will never occur
> within your values.
Not immediately applicable here as it might be too inefficient if lots and
> Not a how-to but a why-the-heck-not? inspired by current discussion on the
> TSOREXX list. A time-honored way of swapping variables around is to put
> them into an expression for PARSE:
>
> Parse Value x y z With z x y
>
> When the values aren't single words, we can play games with delimiters:
>
> Parse Value x':'y':'z with z ':' x ':' y
>
> But of course this depends on knowing a delimiter that will never occur
> within your values.
lots of data (as in the original post) has to be parsed, but one could do
parse value c2x(x) c2x(y) c2x(z) with z x y
x = x2c(x)
y = x2c(y)
z = x2c(z)
One could even keep the data in hex form in the first place.
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "aaa" by "284".
Glenn Knickerbocker
Mar 13, 2012, 3:29:50 PM3/13/12
to
On 3/13/2012 2:43 PM, Jeremy Nicoll - news posts wrote:
> parse value c2x(x) c2x(y) c2x(z) with z x y
> x = x2c(x)
> y = x2c(y)
> z = x2c(z)
If you're going to use four statements, the simple way is just to put
> parse value c2x(x) c2x(y) c2x(z) with z x y
> x = x2c(x)
> y = x2c(y)
> z = x2c(z)
the last value in a dummy variable:
temp = z
z = x
x = y
y = temp
In Object Rexx, if you don't want to reserve a dummy name, you can use
the last variable to hold a collection of its own old and new values:
y = .array~of(y, z)
z = x
x = y[1]
y = y[2]
ŹR
Jeremy Nicoll - news posts
Mar 13, 2012, 4:06:12 PM3/13/12
to
Glenn Knickerbocker <No...@bestweb.net> wrote:
> If you're going to use four statements, the simple way is just to put the
> last value in a dummy variable:
>
> temp = z
> z = x
> x = y
> y = temp
Yes, of course, I wasn't thinking straight.
> If you're going to use four statements, the simple way is just to put the
> last value in a dummy variable:
>
> temp = z
> z = x
> x = y
> y = temp
I've used the "take whatever values something has and convert it to a one
'word' hex string" technique quite a lot in the past (Classic REXX under
TSO), eg to return multiple arbitrary values from a function call, eg:
return c2x(x) c2x(y) c2x(z)
with the caller having:
multipleresults = myfunction()
parse var multipleresults hexx hexy hexz
And if some of them could be null I've had to delimit the return values:
return "!"c2x(x)"!"c2x(y)"!"c2x(z)"!"
so caller has:
multipleresults = myfunction()
parse var multipleresults "!"hexx"!"hexy"!"hexz"!"
And of course either way one then has to do a set of x2c() calls.
Glenn Knickerbocker
Mar 13, 2012, 5:17:06 PM3/13/12
to
On 3/13/2012 4:06 PM, Jeremy Nicoll - news posts wrote:
> And if some of them could be null I've had to delimit the return values:
>
> return "!"c2x(x)"!"c2x(y)"!"c2x(z)"!"
The other approach would be to parse out single blanks explicitly:
> And if some of them could be null I've had to delimit the return values:
>
> return "!"c2x(x)"!"c2x(y)"!"c2x(z)"!"
Parse Var multipleresults hexx ' ' hexy ' ' hexz
ŹR
Shmuel Metz
Mar 13, 2012, 8:00:42 PM3/13/12
to
In <TK6dnUPEbK_vDMLS...@bestweb.net>, on 03/13/2012
at 02:27 PM, Glenn Knickerbocker <No...@bestweb.net> said:
>Subject: parse multiple values
My take depends on whether you're concerned with classic Rexx or with
OREXX. For either, you can use the hack
call Permute x, y, z
...
Permute: PROC
EXPOSE x y z
parse arg z, x, y
return
For OREXX I'd suggest arrays rather than stems in your proposed
extension.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
at 02:27 PM, Glenn Knickerbocker <No...@bestweb.net> said:
>Subject: parse multiple values
My take depends on whether you're concerned with classic Rexx or with
OREXX. For either, you can use the hack
call Permute x, y, z
...
Permute: PROC
EXPOSE x y z
parse arg z, x, y
return
For OREXX I'd suggest arrays rather than stems in your proposed
extension.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org
Glenn Knickerbocker
Mar 14, 2012, 10:20:16 PM3/14/12
to
On Tue, 13 Mar 2012 20:00:42 -0400, Shmuel wrote:
>For OREXX I'd suggest arrays rather than stems in your proposed
>extension.
Right, as I said, it could be any collection class:
>For OREXX I'd suggest arrays rather than stems in your proposed
>extension.
Parse Value f(x) With fclass, .stem(f)
Parse Value f(x) With fclass, .array(f)
Parse Value f(x) With fclass, .bag(f)
I'm just proposing the count part specifically for stems, because that
would have special usefulness in Classic Rexx.
"It's not the size of the boat, it's Matt McIrvin" -- Joe
ŹR / http://users.bestweb.net/~notr/ny2001.html / Manfre
danfan46
Mar 15, 2012, 10:57:19 AM3/15/12
to
In ooRexx the string class has the makeArray method.
-- -------------------------------
signal on novalue
string = "hello boys this is not an array yet"
array = string~makeArray(' ')
say "Array contains" array~items
say "the sixth item is:" array[6]
say "the seventh item is:" array[7]
say "the eigth item is:" array[8]
say "the ninth item is:" array[9]
-- --------------------------------
The method can use an arbitrary delimiter, but can't handle varying delimiters like doubled or tripled spaces.
It is not what you discussed of course but anyway ...
/dg
Shmuel Metz
Mar 15, 2012, 9:01:28 AM3/15/12
to
In <muj2m7llbuud3igdv...@4ax.com>, on 03/14/2012
consider .array or .stem more suitable than, e.g., .bag, .set.
at 10:20 PM, Glenn Knickerbocker <No...@bestweb.net> said:
>Right, as I said, it could be any collection class:
Order is frequently important in parsing. For that reason, I'd
>Right, as I said, it could be any collection class:
consider .array or .stem more suitable than, e.g., .bag, .set.
Glenn Knickerbocker
Mar 16, 2012, 2:23:48 PM3/16/12
to
On 3/15/2012 9:01 AM, Shmuel (Seymour J.) Metz wrote:
> Order is frequently important in parsing. For that reason, I'd
> consider .array or .stem more suitable than, e.g., .bag, .set.
Order is also frequently unimportant--in parsing a set of options, for
> Order is frequently important in parsing. For that reason, I'd
> consider .array or .stem more suitable than, e.g., .bag, .set.
instance. I'm proposing that it could be ANY subclass of .collection,
not some particular one. That's why the class name is in the syntax.
ŹR
Gerard_Schildberger
Mar 20, 2012, 3:05:29 PM3/20/12
to
On Mar 13, 7:00 pm, Shmuel (Seymour J.) Metz
<spamt...@library.lspace.org.invalid> wrote:
> In <TK6dnUPEbK_vDMLSnZ2dnUVZ_sidn...@bestweb.net>, on 03/13/2012
Permute: procedure expose x y z
parse arg z,x,y
return
__________________________ Gerard Schildberger
> For OREXX I'd suggest arrays rather than stems in your proposed
> extension.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
>
> Unsolicited bulk E-mail subject to legal action. I reserve the
> right to publicly post or ridicule any abusive E-mail. Reply to
> domain Patriot dot net user shmuel+news to contact me. Do not
> reply to spamt...@library.lspace.org
<spamt...@library.lspace.org.invalid> wrote:
> In <TK6dnUPEbK_vDMLSnZ2dnUVZ_sidn...@bestweb.net>, on 03/13/2012
> at 02:27 PM, Glenn Knickerbocker <N...@bestweb.net> said:
>
> >Subject: parse multiple values
>
> My take depends on whether you're concerned with classic Rexx or with
> OREXX. For either, you can use the hack
>
> call Permute x, y, z
> ...
>
> Permute: PROC
> EXPOSE x y z
> parse arg z, x, y
> return
---- I assume you meant to code:
>
> >Subject: parse multiple values
>
> My take depends on whether you're concerned with classic Rexx or with
> OREXX. For either, you can use the hack
>
> call Permute x, y, z
> ...
>
> Permute: PROC
> EXPOSE x y z
> parse arg z, x, y
> return
Permute: procedure expose x y z
parse arg z,x,y
return
__________________________ Gerard Schildberger
> For OREXX I'd suggest arrays rather than stems in your proposed
> extension.
>
> --
> Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
>
> Unsolicited bulk E-mail subject to legal action. I reserve the
> right to publicly post or ridicule any abusive E-mail. Reply to
> domain Patriot dot net user shmuel+news to contact me. Do not
Gerard_Schildberger
Mar 22, 2012, 4:51:08 PM3/22/12
to
On Mar 13, 1:27 pm, Glenn Knickerbocker <N...@bestweb.net> wrote:
> Not a how-to but a why-the-heck-not? inspired by current discussion on
> the TSOREXX list. A time-honored way of swapping variables around is to
> put them into an expression for PARSE:
>
> Parse Value x y z With z x y
>
> When the values aren't single words, we can ...
> Not a how-to but a why-the-heck-not? inspired by current discussion on
> the TSOREXX list. A time-honored way of swapping variables around is to
> put them into an expression for PARSE:
>
> Parse Value x y z With z x y
>
[rest of text deleted]
Of course, if any of X, Y, or Z has either leading or trailing
blanks, then the above method fails (as you pointed out, it'll
also fail if there are imbeded blanks in any of the variables).
I haven't tried all characters, but horizontal tabs and vertical
tabs (white space characters) also goof the works up.
___________________________________________ Gerard Schildberger
Gerard_Schildberger
Mar 22, 2012, 5:03:30 PM3/22/12
to
On Mar 13, 1:43 pm, Jeremy Nicoll - news posts
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
'4f6F 7073'
is a valid string --- but it has imbedded blanks, and two
versions of "effs". That's not a concern if you KNOW the
datum has been converted from a character string.
_____________________________________ Gerard Schildberger
> --
> Jeremy C B Nicoll - my opinions are my own.
>
> Email sent to my from-address will be deleted. Instead, please reply
> to newsreply...@wingsandbeaks.org.uk replacing "aaa" by "284".
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> Glenn Knickerbocker <N...@bestweb.net> wrote:
> > Not a how-to but a why-the-heck-not? inspired by current discussion on the
> > TSOREXX list. A time-honored way of swapping variables around is to put
> > them into an expression for PARSE:
>
> > Parse Value x y z With z x y
>
> > When the values aren't single words, we can play games with delimiters:
>
> > Parse Value x':'y':'z with z ':' x ':' y
>
> > But of course this depends on knowing a delimiter that will never occur
> > within your values.
>
> Not immediately applicable here as it might be too inefficient if lots and
> lots of data (as in the original post) has to be parsed, but one could do
>
> parse value c2x(x) c2x(y) c2x(z) with z x y
> x = x2c(x)
> y = x2c(y)
> z = x2c(z)
>
> One could even keep the data in hex form in the first place.
Keep in mind the hexstring
> > Not a how-to but a why-the-heck-not? inspired by current discussion on the
> > TSOREXX list. A time-honored way of swapping variables around is to put
> > them into an expression for PARSE:
>
> > Parse Value x y z With z x y
>
> > When the values aren't single words, we can play games with delimiters:
>
> > Parse Value x':'y':'z with z ':' x ':' y
>
> > But of course this depends on knowing a delimiter that will never occur
> > within your values.
>
> Not immediately applicable here as it might be too inefficient if lots and
> lots of data (as in the original post) has to be parsed, but one could do
>
> parse value c2x(x) c2x(y) c2x(z) with z x y
> x = x2c(x)
> y = x2c(y)
> z = x2c(z)
>
> One could even keep the data in hex form in the first place.
'4f6F 7073'
is a valid string --- but it has imbedded blanks, and two
versions of "effs". That's not a concern if you KNOW the
datum has been converted from a character string.
_____________________________________ Gerard Schildberger
> --
> Jeremy C B Nicoll - my opinions are my own.
>
> Email sent to my from-address will be deleted. Instead, please reply
Jeremy Nicoll - news posts
Mar 23, 2012, 12:02:53 AM3/23/12
to
Gerard_Schildberger <gera...@rrt.net> wrote:
>On Mar 13, 1:43 pm, Jeremy Nicoll - news posts
><jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> > Not immediately applicable here as it might be too inefficient if lots
> > and lots of data (as in the original post) has to be parsed, but one
> > could do
>>
>> parse value c2x(x) c2x(y) c2x(z) with z x y
>> x = x2c(x)
>> y = x2c(y)
>> z = x2c(z)
>>
>> One could even keep the data in hex form in the first place.
>
>Keep in mind the hexstring
>
> '4f6F 7073'
>
>is a valid string --- but it has imbedded blanks, and two
>versions of "effs".
What?
>On Mar 13, 1:43 pm, Jeremy Nicoll - news posts
><jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> > Not immediately applicable here as it might be too inefficient if lots
> > and lots of data (as in the original post) has to be parsed, but one
> > could do
>>
>> parse value c2x(x) c2x(y) c2x(z) with z x y
>> x = x2c(x)
>> y = x2c(y)
>> z = x2c(z)
>>
>> One could even keep the data in hex form in the first place.
>
>Keep in mind the hexstring
>
> '4f6F 7073'
>
>is a valid string --- but it has imbedded blanks, and two
>versions of "effs".
> That's not a concern if you KNOW the datum has been converted from a
> character string.
Are you saying the result from that function could contain a blank? I've
never seen that.
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
Glenn Knickerbocker
Mar 23, 2012, 12:12:23 PM3/23/12
to
On 3/22/2012 4:51 PM, Gerard_Schildberger wrote:
> On Mar 13, 1:27 pm, Glenn Knickerbocker <N...@bestweb.net> wrote:
>>> When the values aren't single words, we can ...
> [rest of text deleted] Of course, if any of X, Y, or Z has either
> leading or trailing blanks,
then if stripping them makes a difference they're not "words" in the
> On Mar 13, 1:27 pm, Glenn Knickerbocker <N...@bestweb.net> wrote:
>>> When the values aren't single words, we can ...
> [rest of text deleted] Of course, if any of X, Y, or Z has either
> leading or trailing blanks,
sense I meant. That's a semantic matter, not a programming problem.
ŹR
Gerard_Schildberger
Mar 24, 2012, 11:23:49 AM3/24/12
to
On Mar 22, 11:02 pm, Jeremy Nicoll - news posts
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
you
KNOW the datum has been created from a character string." But as you
mentioned, it could be null however, and that becomes problematic.
Perhaps I'm just getting confused with all the PARSE statements being
being seperated from the data creation. It's hard to tell with all
the program snippetes being quoted and then, re-quoted. It would be
far simplier and faster to just use a temporary variable instead of
invoking multiple BIFs. ________________________ Gerard Schildberger
> --
> Jeremy C B Nicoll - my opinions are my own.
>
> Email sent to my from-address will be deleted. Instead, please reply
> to newsreply...@wingsandbeaks.org.uk replacing "aaa" by "284". - Hide quoted text -
>
> - Show quoted text -
<jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> Gerard_Schildberger <gerar...@rrt.net> wrote:
> >On Mar 13, 1:43 pm, Jeremy Nicoll - news posts
> ><jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> > > Not immediately applicable here as it might be too inefficient if lots
> > > and lots of data (as in the original post) has to be parsed, but one
> > > could do
>
> >> parse value c2x(x) c2x(y) c2x(z) with z x y
> >> x = x2c(x)
> >> y = x2c(y)
> >> z = x2c(z)
>
> >> One could even keep the data in hex form in the first place.
>
> >Keep in mind the hexstring
>
> > '4f6F 7073'
>
> >is a valid string --- but it has imbedded blanks, and two
> >versions of "effs".
>
> What?
>
> > That's not a concern if you KNOW the datum has been converted from a
> > character string.
>
> I know the example I gave above showed the strings being created by c2x().
> Are you saying the result from that function could contain a blank? I've
> never seen that.
No, I never said or implied that. I did say, "that's not a concern if
> >On Mar 13, 1:43 pm, Jeremy Nicoll - news posts
> ><jn.nntp.scrap...@wingsandbeaks.org.uk> wrote:
> > > Not immediately applicable here as it might be too inefficient if lots
> > > and lots of data (as in the original post) has to be parsed, but one
> > > could do
>
> >> parse value c2x(x) c2x(y) c2x(z) with z x y
> >> x = x2c(x)
> >> y = x2c(y)
> >> z = x2c(z)
>
> >> One could even keep the data in hex form in the first place.
>
> >Keep in mind the hexstring
>
> > '4f6F 7073'
>
> >is a valid string --- but it has imbedded blanks, and two
> >versions of "effs".
>
> What?
>
> > That's not a concern if you KNOW the datum has been converted from a
> > character string.
>
> I know the example I gave above showed the strings being created by c2x().
> Are you saying the result from that function could contain a blank? I've
> never seen that.
you
KNOW the datum has been created from a character string." But as you
mentioned, it could be null however, and that becomes problematic.
Perhaps I'm just getting confused with all the PARSE statements being
being seperated from the data creation. It's hard to tell with all
the program snippetes being quoted and then, re-quoted. It would be
far simplier and faster to just use a temporary variable instead of
invoking multiple BIFs. ________________________ Gerard Schildberger
> --
> Jeremy C B Nicoll - my opinions are my own.
>
> Email sent to my from-address will be deleted. Instead, please reply
>
> - Show quoted text -
Glenn Knickerbocker
May 7, 2012, 10:10:33 AM5/7/12
to
I just stumbled back on this thread and spotted an idea to revisit, and
I wonder if I've stumbled on a bug in PARSE ARG or just a quirk.
On 3/13/2012 8:00 PM, Shmuel (Seymour J.) Metz wrote:
> Permute: PROC
> EXPOSE x y z
> parse arg z, x, y
> return
My thought was, can we do this without having to expose a predefined set
of variable names? Could we play tricks with USE ARG?
Permute: Procedure
Use Arg x, y, z
Parse Arg z, x, y
Return
But this is no good, since string objects are never changed, and PARSE
just reassigns the variables. So then, what if I tried it with stems
but used only their default values?
Permute: Procedure
Use Arg x, y, z
Parse Arg z[], x[], y[]
Return
The result surprised me:
14 *-* Use Arg x, y, z
>>> "1"
>>> "2"
>>> "3"
15 *-* Parse Arg z[], x[], y[]
>>> "1"
>>> "1"
>>> "2"
>>> "2"
>>> "1"
>>> "1"
I guess this goes along with regular left-to-right processing, but I
expected the arguments all to be evaluated as strings before any
assignments were made. Is this as expected, that a template in parsing
one argument string can update an object before it's evaluated for
parsing as a subsequent argument string? I don't see an indication
either way under ARG, PARSE ARG, or Parsing Several Strings.
ŹR
I wonder if I've stumbled on a bug in PARSE ARG or just a quirk.
On 3/13/2012 8:00 PM, Shmuel (Seymour J.) Metz wrote:
> Permute: PROC
> EXPOSE x y z
> parse arg z, x, y
> return
of variable names? Could we play tricks with USE ARG?
Permute: Procedure
Use Arg x, y, z
Parse Arg z, x, y
Return
But this is no good, since string objects are never changed, and PARSE
just reassigns the variables. So then, what if I tried it with stems
but used only their default values?
Permute: Procedure
Use Arg x, y, z
Parse Arg z[], x[], y[]
Return
The result surprised me:
14 *-* Use Arg x, y, z
>>> "1"
>>> "2"
>>> "3"
15 *-* Parse Arg z[], x[], y[]
>>> "1"
>>> "1"
>>> "2"
>>> "2"
>>> "1"
>>> "1"
I guess this goes along with regular left-to-right processing, but I
expected the arguments all to be evaluated as strings before any
assignments were made. Is this as expected, that a template in parsing
one argument string can update an object before it's evaluated for
parsing as a subsequent argument string? I don't see an indication
either way under ARG, PARSE ARG, or Parsing Several Strings.
ŹR
Shmuel Metz
May 8, 2012, 12:25:06 AM5/8/12
to
In <rIqdnWK_ZfZJSjrS...@bestweb.net>, on 05/07/2012
patterns".
at 10:10 AM, Glenn Knickerbocker <No...@bestweb.net> said:
>I guess this goes along with regular left-to-right processing, but
>I expected the arguments all to be evaluated as strings before
>any assignments were made.
That would break some of the examples under "parsing with variable
>I guess this goes along with regular left-to-right processing, but
>I expected the arguments all to be evaluated as strings before
>any assignments were made.
patterns".
Glenn Knickerbocker
May 8, 2012, 4:33:41 PM5/8/12
to
On 5/8/2012 12:25 AM, Shmuel (Seymour J.) Metz wrote:
> That would break some of the examples under "parsing with variable
> patterns".
No, none of those involve parsing multiple arguments. This is something
> That would break some of the examples under "parsing with variable
> patterns".
different.
In those examples, a template is parsed and the results of that parsing
are used to fill in another template. But the string being parsed has
already been evaluated, and doesn't change if you assign something new
to the variable it came from:
z = 'these 15 words this is the stuff'
Parse Var z . z . 0 =(z) z
Say z /* says 'this is the stuff' */
Here, Z is set to 15, and then used as a position to start parsing at,
and the rest of the string is then assigned to Z. That string had
already been evaluated, and it didn't change when we reassigned Z in
parsing it.
That's just a more complicated version of the same thing that this
thread started out with:
Parse Value x y z with z x y
parsed.
In my example:
Use Arg x, y, z
Parse Arg z[], x[], y[]
y, z) as strings, before parsing any of the templates. What happens
instead is that the first argument (x) is evaluated and parsed into z[]
before the other arguments are evaluated, so when it gets to evaluating
the third argument (z) it has already changed.
ŹR
Shmuel Metz
May 9, 2012, 12:48:15 AM5/9/12
to
In <nuSdnReBz7-9HjTS...@bestweb.net>, on 05/08/2012
Example:
/* Using a variable as a string pattern */
/* The variable (delim) is set in the same template */
SAY "Enter a date (mm/dd/yy format). =====> " /* assume 11/15/90 */
pull date
parse var date month 3 delim +1 day +2 (delim) year
/* Sets: month='11'; delim='/'; day='15'; year='90' */
>But the string being parsed has already been evaluated, and
>doesn't change if you assign something new to the variable it
>came from
Correct; the handling of variables within a template does seem to be
different from the handling of multiple[1] templates. Is it a bug or a
feature, and has it been reported?
>In my example:
> Use Arg x, y, z
> Parse Arg z[], x[], y[]
>I expected the same thing to happen:
Note that in your example there are three templates, not just three
varibles in a single template. I'm also wondering whether OOREXX
should have flagged your parse arg as a syntax error, since x[] is a
method call rather than a variable.
>What happens instead
I understand what happens; I'm just unclear about what should have
happened. The three obvious answers are:
1. Evaluate all three templates before parsing
2. Process the templates sequentially, as is currently done
3. Reject stem[] as not being a variable name
Were it I running into this, I'd report it and let them figure out the
correct behavior, and document it.
[1] In your case, there are three templates.
at 04:33 PM, Glenn Knickerbocker <No...@bestweb.net> said:
>In those examples, a template is parsed and the results of that
>parsing are used to fill in another template.
No, the results are used in the same template
>In those examples, a template is parsed and the results of that
>parsing are used to fill in another template.
Example:
/* Using a variable as a string pattern */
/* The variable (delim) is set in the same template */
SAY "Enter a date (mm/dd/yy format). =====> " /* assume 11/15/90 */
pull date
parse var date month 3 delim +1 day +2 (delim) year
/* Sets: month='11'; delim='/'; day='15'; year='90' */
>But the string being parsed has already been evaluated, and
>doesn't change if you assign something new to the variable it
>came from
different from the handling of multiple[1] templates. Is it a bug or a
feature, and has it been reported?
>In my example:
> Use Arg x, y, z
> Parse Arg z[], x[], y[]
>I expected the same thing to happen:
varibles in a single template. I'm also wondering whether OOREXX
should have flagged your parse arg as a syntax error, since x[] is a
method call rather than a variable.
>What happens instead
I understand what happens; I'm just unclear about what should have
happened. The three obvious answers are:
1. Evaluate all three templates before parsing
2. Process the templates sequentially, as is currently done
3. Reject stem[] as not being a variable name
Were it I running into this, I'd report it and let them figure out the
correct behavior, and document it.
[1] In your case, there are three templates.
Glenn Knickerbocker
May 9, 2012, 12:08:05 PM5/9/12
to
On 5/9/2012 12:48 AM, Shmuel (Seymour J.) Metz wrote:
> Glenn Knickerbocker <No...@bestweb.net> said:
>> In those examples, a template is parsed and the results of that
>> parsing are used to fill in another template.
> No, the results are used in the same template
Sorry, mixed up terms--I meant a pattern.
> Glenn Knickerbocker <No...@bestweb.net> said:
>> In those examples, a template is parsed and the results of that
>> parsing are used to fill in another template.
> No, the results are used in the same template
> Correct; the handling of variables within a template does seem to be
> different from the handling of multiple[1] templates. Is it a bug or a
> feature, and has it been reported?
¬R
LesK
May 21, 2012, 12:25:38 AM5/21/12
to
I suggest you report it as a bug. You should, of course, look for similar bugs
to avoid dups.
--
Les (Change Arabic to Roman to email me)
Glenn Knickerbocker
May 21, 2012, 2:21:08 PM5/21/12
to
On 5/21/2012 12:25 AM, LesK wrote:
> I suggest you report it as a bug. You should, of course, look for
> similar bugs to avoid dups.
I was hoping discussion here might first reveal whether it was a bug, an
> I suggest you report it as a bug. You should, of course, look for
> similar bugs to avoid dups.
intentional feature, or an unspecified behavior whose specification
should be nailed down.
ŹR
0 new messages