From: RZOTTO@DKNKURZ1.BITNET (Otto Stolz)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 27 Aug 92 19:36:39 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <RZOTTO@DKNKURZ1>
              27 Aug 92 00:40:39 LCL from <anders@LISE3.LISE.UNIT.NO>

In article <REXXLIST%92082621432914@DEARN> I said:
>  A cursory scan through TRL did not reveal any support
>  for this statemnt.

On Thu, 27 Aug 92 00:40:39 LCL Anders Christensen said:
>   "Programming in the REXX language can be considered to involve the
>    use of two character sets. [...]"
>                            TRL, 2nd ed.
>                            Part 2, section 1, page 18.
>                            First paragraph of "Character Sets",

Sorry, my "cursory scan" started in the right place (Part 2, Section 1)
of the wrong book (1st edition, 1985).

> [...]
> Consequently, Rexx may allow a lesser set of whitespace characters for
> use in the Rexx script source code (except from comments and strings),
> while it may recognize a much broader set of whitespace characters in
> the data.

This is a reasonable demand, but it places an extra burden on the
standard committee. The REXX standard will have to give explicit (though
not system specific) rules about the mapping from the source character
set to the data character set underlying the following language
features:
- literal strings,
- SOURCELINE function,
- ADDRESS, and TRACE, functions,
and about the mapping from the data character set to the source character
set underlying the following features:
- INTERPRET statement,
- SYMBOL, and VALUE, functions,
- VALUE sub-keywords of ADDRESS, SIGNAL, and TRACE, statements.
I hope I haven't missed any relevant features.

These rules should be designed to preserve the meaning of the character
strings as much as possible. Some of the points to be considered are:
- when the source character set is a proper subset of the data character
  set, the rules should state that source code is transferred unalterd
  into the data domain;
- when a graphic character is available in one domain S but lacking in
  the other domain T, the rules could state
  - either that this character may not be contained in character strings
    bound to be mapped from S to T (e.g. the statement
            INTERPRET "say '" || blabla || "'"
    would result in a runtime error, if the blabla variable comprised
    a character not allowed in the source program (not even in literal
    strings), whilst the statement
            INTERPRET "say blabla"
    would work under the same circumstances),
  - or that the offending character would be mapped to a suitable
    substitute such as the SUB character of domain T (e.g. '1A'x in
    ISO 646 and ISO 6429, '001A'x in the  BMP of ISO 10646), or '3F'x
    in EBCDIC);
- when white space is represented differently in the two domains, the
  rules could state that one representation be mapped to an equivalent
  one;
- if at all possible, the statement
            INTERPRET sourceline(i)
  should have the same effect as the REXX statement(s) contained in
  line i of the respective source program (aka "round-trip integrity"),
  or otherwise the standard should define all possible discrepancies.

I am not sure which rule would be most practical. Opinions? Note that I
do *not* suggest the REXX standard should state explicit character names
(let alone particular bit combinations): these were only fyi -- rather I
suggest the standard should state its rules independent of the underlying
character code (as in "a suitable substitute", above).

Best wishes,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>
Newsgroups: comp.lang.rexx