Reginald extensions

Jeff Glatt: I don't know if you entertain suggestions for
Reginald
extensions.   This is an idea for your consideration.

The DO OVER loop is useful, and it suggests a language
extension in
which the DO OVER is implied.

It would be neat if it were permitted to code such things as ...

T. = T. + 1
which would increment all stems which exist and have a
numeric value.

T. = left(T.,80)
would make all stems into 80-character records.

T. = A. + B.
would take all stems in A for which there is a corresponding
stem in
B, sum the respective values and store them in T with the
same stem.

Daniel B. Martin

Daniel B. Martin wrote:

> Jeff Glatt: I don't know if you entertain suggestions for Reginald
> extensions.   This is an idea for your consideration.
>
> The DO OVER loop is useful, and it suggests a language extension in
> which the DO OVER is implied.
>
> It would be neat if it were permitted to code such things as ...
>
> T. = T. + 1
> which would increment all stems which exist and have a numeric value.
>
> T. = left(T.,80)
> would make all stems into 80-character records.
>
> T. = A. + B.
> would take all stems in A for which there is a corresponding stem in
> B, sum the respective values and store them in T with the same stem.
>
> Daniel B. Martin
hmm, I'd rather not use the imprecise "T."  "T." could be short for
"T.0".  I'd rather something like "T.*" or "T.()" or something else that
makes it more clear that you're referring to multiple elements.  Rexx
isn't C or Perl and should strive for a lesser amount of cryptic-ness.

--

Gary Scott
mailto:garylscott@sbcglobal dot net

Fortran Library:  http://www.fortranlib.com

Support the Original G95 Project:  http://www.g95.org
-OR-
Support the GNU GFortran Project:  http://gcc.gnu.org/fortran/index.html

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Gary Scott wrote:
> I'd rather something like "T.*" or "T.()" or something else that
> makes it more clear that you're referring to multiple elements.

Yes, I like your suggestion.   I won't quibble over
notation, it is the
function that I yearn for.

Daniel B. Martin

"Daniel B. Martin" <daniel88b88martin@earthlink88.net> wrote:

> T. = A. + B.
> would take all stems in A for which there is a corresponding
> stem in
> B, sum the respective values and store them in T with the
> same stem.

This is like the way (in Python for example) one can apply an operator or
function to all the items in a list (or array or whatever the Python term
is, I forget).


It might be better to be more generic (ie allow an arbitrary operator or
function) to be mapped onto a series of stems.  (Like lambda in Python.)


You have the problem of what to do if the operator can't legally act on the
items concerned.

If for example  A.3 = 5    and B.3 = "cat"

would   T. = A. + B.   work at all?

Worse, would the result of T. = B. + A.   be different?  If so that's a
hazard for programmers who tend to assume that (a+b) == (b+a)   Perhaps in
this case because "B.3" isn't numeric it would mean that index 3 wassn't
eligible for the operation.


--
Jeremy C B Nicoll - my opinions are my own.

>Daniel B. Martin
>I don't know if you entertain suggestions for Reginald
>extensions.

Absolutely. In fact, most all of the extensions are there because various
Reginald endusers asked me for them. If I come up with some idea on my own,
what I do is first run it past the users via the Reginald forum. Everyone ta
kes
a look at the proposal and weighs in on it. Some things may be changed, or
added/deleted. Then, if the majority gives a thumbs up, I start coding. In
fact, that's the case with all proposals from anyone. The usual procedure is
 to
publically propose something on the forum, in the same vein.

I'm not one of those programmers that says "No, I won't do that because some
document written 10 years ago didn't say I could do that, and therefore I do
n't
care what you need/want today". I'm very much a pragmatic programmer. Never 
be
afraid to ask me about something Reginald-related simply because you may hav
e
dealt with vociferously dogmatic open source developers in the past. I'm not
one of those. And neither is anyone else using Reginald. Those sorts of peop
le
are quickly redirected to some other project where they can all flame each
other with their "I don't want/need that, so you shouldn't want/need that
either" diatribes.

>T. = T. + 1
>which would increment all stems which exist and have a numeric value.

Someone already requested a more intuitive way to perform a math operation
between a variable and a constant. That's already on my to do list. Your
suggestion would fit right into that.

But that proposal favored a C syntax for it as so:

T. += 1

The reason I favor it is because it would make it easier to parse for
optimization, and can also be an intuitive way to involve operands other tha
n
constants, for example:

/* Calculate the total length of "Hello world", in pieces */
TotalLen = LENGTH("Hello ")
TotalLen += LENGTH("World")  /* Instead of TotalLen = TotalLen +
LENGTH("World") */

But as someone else pointed out, a stem variable can have a value too. For
example, assume you have the following statements:

T. = 1
T. += 5

Doesn't this naturally look like you're incrementing the value of T. by 5 (a
nd
now its new value is 6)?

So if you wanted to implement some sort of "pattern matching", it would be b
est
to notate it differently, and more explicitly. I see Gary suggested:

T.* += 5

Offhand, that looks appealing. But not so much so if you do a multiply
operation:

T.* *= 5

Or worse, raising to a power:

T.* **= 5

He also suggested:

T.() *= 5

That looks better to me, but I think (since T. is sort of like an array in
REXX) this looks best:

T.[] *= 5

If you're  with that, then I'll put it to the Reginald folks and see wha
t
they think. We already gave the thumbs up to the math shortcut (although not
yet implemented. That's the thing. Lately, I've been very busy with other
things so a lot of Reginald work has gotten backlogged).

>T. = left(T.,80)
>would make all stems into 80-character records.

I'm not sure about this one. LEFT() returns a value, and it naturally looks
like you're assigning it to the stem. The above is already a legal REXX
instruction. I think this idea needs more work to find a useful way of notat
ing
it.

>T. = A. + B.
>would take all stems in A for which there is a corresponding
>stem in
>B, sum the respective values and store them in T with the
>same stem.

Again, that's already a legal REXX instruction.

I think what you may be looking for in the above 2 requests are some sort of
new REXX instructions that operate upon a variable, like SORT does. For
example:

RECORD T. 80

...where the RECORD instruction is followed by the stem name to operate upo
n,
and then the length of the desired "record", and it performs that operation 
you
want.

Sometimes it takes awhile to decide the best way to implement something.

>Jeremy Nicoll
>You have the problem of what to do if the operator can't legally act on the
>items concerned.
>
>If for example  A.3 = 5    and B.3 = "cat"
>
>would   T. = A. + B.   work at all?

Well, we can't really use that syntax as is, because it's already a legal RE
XX
instruction meaning something entirely different. But assuming there was
another way to note it, such as a new STEMMATH instruction:

STEMMATH T. A. + B.

If some element of A. or B. wasn't numeric, that would have to raise a SYNTA
X
condition with an error that it's an illegal math operation. So in Reginald,
you'd handle it as so:

DO
STEMMATH T. A. + B.

CATCH SYNTAX
/* Most likely, I'd have CONDITION('D') return the name of the variable
in error. Not sure yet what errror number CONDITION('E') would return */
END

And then of course, the STEMMATH instruction could perhaps be made really
spiffy so that it could do other math operations such as multiplication:

STEMMATH T. A. * 5

Or more than one of a variety of math operations:

STEMMATH T. A. * (5 + B.) / POS(",", MyVariable)

which adds 5 to the value of each element in B., multiplies that by the
respective A. element, divides by the position of the first comma in
MyVariable, and assigns the final result to the respective T. element.

Anyway, that's what appeals to me offhand.

Jeff Glatt wrote:
> If you're  with that, then I'll put it to the Reginald folks and see w
hat
> they think.

Sure, I'm  with that.   As previously said,  I won't
quibble over notation,
it is the function that I yearn for.    Thank you for having
an open mind and
open ear.

Daniel B. Martin

Jeremy Nicoll - news posts wrote:
> You have the problem of what to do if the operator can't legally act on th
e
> items concerned.
> If for example  A.3 = 5    and B.3 = "cat"
> would   T. = A. + B.   work at all?

My line of thinking is permissive.
If the operator can legally act, it does so.
If it can't legally act, it ignores the situation.

If A.3 = 5 and B.3 = "cat" then T.3 remains unchanged.
Similarly,
if A.3 = 5 and B.3 has no assigned value, T.3 remains unchanged.

Daniel B. Martin

On Sun, 30 Mar 2008 22:19:54 UTC, Jeff Glatt
<jglatt@spamgone-borg.com> wrote:
 
>
>I'm not sure about this one. LEFT() returns a value, and it naturally
looks
>like you're assigning it to the stem. The above is already a legal
REXX
>instruction. I think this idea needs more work to find a useful way
of notating
>it.

T.[] = left(T.[],80)
 
>
>I think what you may be looking for in the above 2 requests are some
sort of
>new REXX instructions that operate upon a variable, like SORT does.
For
>example:

> RECORD T. 80

T.[] = A.[] + B.[]
--
Andre

Jeff Glatt <jglatt@spamgone-borg.com> wrote:
 
the 
>
> Well, we can't really use that syntax as is, because it's already a legal
> REXX instruction meaning something entirely different.

What?

> But assuming there was another way to note it, such as a new STEMMATH
> instruction:
>
> STEMMATH T. A. + B.

If you're not going to have an "=" in there to imply assignation, could I
suggest a literal placeholder (like "WITH" in parse for example) eg:

STEMMATH T. UPDATEDBY A. + B.

or something?

But why limit this to mathematical operators, or indeed /operators/ ?

Why not just indicate that there's a process that updates a stem, eg:

STEMPROCESS T. UPDATEDBY arbitraryfunction(A.,B.,C.,23,"false") + F. - G.

say?

--
Jeremy C B Nicoll - my opinions are my own.