NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/rexx/955

Text File | 1992-09-08 | 6.1 KB | 140 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!paladin.american.edu!auvm!DKNKURZ1.BITNET!RZOTTO
X-Acknowledge-To: <RZOTTO@DKNKURZ1>
Message-ID: <REXXLIST%92090821571399@DEARN>
Newsgroups: comp.lang.rexx
Date:         Tue, 8 Sep 1992 19:35:55 MEZ
Sender:       REXX Programming discussion list <[e-mail]>
From:         Otto Stolz <[e-mail]>
Subject:      Re: Blanks, REXX, and portability...
In-Reply-To:  Message of Tue, 8 Sep 92 10:21:06 PDT from <GOMBERG@UCSFVM>
Lines: 127

Hello REXXperts,

apparently, some of us have been at cross-purposes, as illustrated by
the exchange quoted below. The present note attempts to make sure we are
all talking about the same proposals; I hope this will pour some oil on
troubled waters (rather than on the flames :-)

Dave Gomberg <[e-mail]> writes:
> I would really like [...] to say if they can stand it that:
>    c=a||b;  say pos(a,c)
> would say 0?  It is not what I mean by REXX.

On Tue, 8 Sep 1992 12:32:48 -0400 cultural elite said:
> [...] explain how you get c=a||b; pos(a,c)=0 out of any sensible
> proposal.

On Tue, 8 Sep 92 10:21:06 PDT Dave Gomberg said:
> If the synonymy of tabs to a particular number of blanks were accepted,
> and if assignment did normalization (as it often does, both in
> standards and in practice) then c might well have a tab when a ended
> and b began with strings of blanks.

I think nobody has proposed a *general* synonymy of tabs to any number of
blanks, and nobody has proposed normalization of strings in *arbitrary*
situations (e.g. during assignment).

Rather, some of us were concerned about the following facts:

- Some REXX language features are meant to do "Parsing strings into
  words" or to deal in other ways with "blank-delimited words" (these are
  quotes from TRL, e.g. a headline on p. 109 of my copy).

- TRL does not define the terms "word", or "blank-delimited word";
  apparently, TRL pre-supposes that one particular character (the
  "blank") is used to delimit words, and this character is represented
  by one single bit-pattern (one per implementation, of course) --
  the only redundancy being in the number of blank characters delimiting
  any two words.

- The latter assumption does not hold with all character codes. Rather,
  several different characters may serve to delimit words -- in major
  character codes, both currently used (e.g. some ASCII implementations)
  and forthcoming ones (ISO 10646).

The forthcoming REXX standard will definitely have to do something about
this discrepancy. At least, it has to define its terms, unambiguously.
I see the following alternatives:

- The standard could perpetuate (and rigidly define) the notion of
  one single blank character -- in contrast to existing (ASCII) and
  foreseeable (ISO 10646) practice.

- The standard could abandon TRL's implicit (and wrong) assumption,
  while preserving a consistent (and useful) language definition.

Clearly, I am in favour of the second alternative. Note that both of its
parts are equally essential! We need a truly "REXXish" language: both
complying to established practice and consistent in itself.

Basically, there have been two proposals to solve this problem:

1 Identify all language features concerned with blank-delimited words,
  and define their semantics consistently and in accordance with current
  and foreseeable practice.

  About a fortnight ago, I presented a temptative list of the pertinent
  language features. I'll append it for those who want to re-read it.
  I am proposing that these features take "white space" of any length
  as word-delimiters, where "white space" may consist of any characters
  that are normally used to delimit words, and whose visual represent-
  ation consists of the absence of a graphic symbol. I am also proposing
  that every standard-conforming implementation shall list the characters
  considered as constituents of "white space" in the accompanying
  documentation.

2 Pre-suppose the existence of a "canonic" form of word-separators
  (consisting of stretches of a particular bit pattern), and set up a
  new language feature to allow the programmer to explicitely normalize
  any string into that canonic form.

  Along these lines, there was an EXPAND() function, and a PARSE EXPAND
  statement, proposed.

I think, we can unanimously agree that the following language features
do *not* deal with words, hence should preserve their present meaning
viz. leave the data *unaltered*:
- literals,
- assignment, and parameter passing,
- parsing with literal, positional, and variable patterns,
- strict comparative operators,
- built-in functions that take character positions or field lengths
  as arguments, such as SUBSTR,
- concatenation without an intervening blank (||-operator, or abuttal).

Note that consistency requisites pertaining to words should involve the
blank-operator rather than the ||-operator, e.g. the expression
      space(a b) = space(a) space(b)
should always yield 1.

Now the positions are clear (as I hope), we should proceed to evaluate
the proposals considering, their relative values, e.g.
- their assigned "astonishing factors",
- their usability,
- their impact on existing programs,
- their technical feasability.

Best wishes,
                    Otto Stolz <[e-mail]>
                               <[e-mail]>

------

On Wed, 26 Aug 92 18:41:09 MEZ I said:
> that all language features recognising words, or depending in other
> ways on the meaning of white space, be identified, and that the
> standard required consistent implementation of these features, e.g.
> - tokenizing of the REXX source program, and of the the INTERPRET
>   statement's operand [..],
> - variables, and dots, in parsing templates,
> - WORD, WORDINDEX, WORDPOS, SUBWORD, and WORDS, functions,
> - STRIP [...], and SPACE, functions,
> - weak character comparison (so-called "normal" comparative operators
>   applied to non-decimal operands),
> - padding default in COMPARE funktion [...],
> - DATATYPE function,
> - white space in operands of numeric operations (including functions)
> (Warning: This list may not be exhaustive);