home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 794 < prev    next >
Encoding:
Text File  |  1992-08-26  |  8.1 KB  |  165 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!gatech!paladin.american.edu!auvm!DKNKURZ1.BITNET!RZOTTO
  3. X-Acknowledge-To: <RZOTTO@DKNKURZ1>
  4. Message-ID: <REXXLIST%92082621432914@DEARN>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Wed, 26 Aug 1992 18:41:09 MEZ
  7. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  8. From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
  9. Subject:      Re: Blanks, REXX, and portability...
  10. In-Reply-To:  Message of Wed, 26 Aug 92 08:31:32 PDT from <GOMBERG@UCSFVM>
  11. Lines: 152
  12.  
  13. On Wed, 26 Aug 92 08:31:32 PDT Dave Gomberg said:
  14. > [...] There is no NEED for lots of different blank characters.
  15.  
  16. May I humbly object:
  17.  
  18. In June, ISO DIS 10646-1 "Universal Character Code" was approved as an
  19. international standard, which will presumably be published in early
  20. 1993. Major vendors have expressed their intention to implement this
  21. standard, which is meant as a possible replacement for ASCII (and the
  22. other national variants of ISO 646-1983 "ISO 7-bit Character Set for
  23. Information Interchange"), the ISO 8859 series ""8-bit single-byte coded
  24. character sets", and a lore of other standard or proprietary character
  25. codes. This standard will comprise (besides, of course, the good old
  26. ASCII tabs) the following space vaiants:
  27.      Space
  28.      Non-breaking Space
  29.      Ideographic Space
  30.      n-Space
  31.      m-Space
  32.      3-per-m-space
  33.      4-per-m-space
  34.      6-per-m-space
  35.      figure space
  36.      punctuation space
  37.      thin space
  38.      hair space
  39.      zero-width space
  40. Obviously, there *are* people seeing a need ... :-)
  41.  
  42. Apparently, the trend goes towards more sophistication in word processing
  43. and finer control over printing devices. Another trend is towards
  44. reconciling electronic data processing and typesetting. Generally
  45. speaking, our programming languages must cease to presuppose the
  46. (obsolete!) typewriter-based notion of "a character is a byte is a
  47. writing position". I guess you are *not* advocating that REXX should
  48. become extinct in the forthcoming EDP world :-)
  49.  
  50. REXX can cope well with any character code, if it is defined and imple-
  51. mented consistently. Regarding white space, this would involve
  52. 1. that the term "white space" (or an equivalent one) be defined in
  53.    the forthcoming standard in a code-independend way,
  54. 2. that all language features recognising words, or depending in other
  55.    ways on the meaning of white space, be identified, and that the
  56.    standard required consistent implementation of these features, e.g.
  57.    - tokenizing of the REXX source program, and of the the INTERPRET
  58.      statement's operand (cf. note 1, below),
  59.    - variables, and dots, in parsing templates,
  60.    - WORD, WORDINDEX, WORDPOS, SUBWORD, and WORDS, functions,
  61.    - STRIP (cf. note 2), and SPACE, functions,
  62.    - weak character comparison (so-called "normal" comparative operators
  63.      applied to non-decimal operands),
  64.    - padding default in COMPARE funktion (cf. note 2),
  65.    - DATATYPE function,
  66.    - white space in operands of numeric operations (including functions)
  67.    (Warning: This list may not be exhaustive);
  68. 3. that the term "blank character" (or an equvalent one) be defined in
  69.    the standard as one definite character belonging to the constituents
  70.    of white space (cf. item 1, supra);
  71. 4. that all language features generating white space (including the
  72.    defaults for pad characters) be identified, and that the standard
  73.    required consistent implementation of these, viz. generation of
  74.    blank characters, e.g. by
  75.    - concatenating terms with one blank in between (expressed by
  76.      white space in lieu of an operator),
  77.    - default padding character in SPACE, CENTER, LEFT, RIGHT, INSERT,
  78.      OVERLAY, SPACE, SUBSTR, and TRANSLATE, functions,
  79.    - padding of the shorter operand in weak character comparisons,
  80.    - the FORMAT function
  81.    (Warning: This list may not be exhaustive);
  82. 5. that standard-conforming implementations be required to implement
  83.    the recognition of white space in a way conforming
  84.    - to all possible sources for REXX source programs,
  85.    - to all possible sources for input to REXX programs
  86.    (cf. note 1);
  87. 6. that standard-conforming implementations be required to implement
  88.    the blank character in a way conforming
  89.    - to all possible environments REXX programs may address,
  90.    - to all possible sinks for output from REXX programs
  91.    (cf. note 1).
  92.  
  93. In a nutshell: REXX language features should be as permissive as
  94.                possible when accepting white space, and as predictable
  95.                as possible when generating it. To achieve this goal, the
  96.                standard should replace the notions of "blank", "blanks"
  97.                or "blank characters" whith "white space" whenever
  98.                characters are inspected, and replace them with "blank
  99.                character" or "blank characters" whenever characters are
  100.                generated.
  101.  
  102. Note 1: Another recent contribution to REXXLIST stated that REXX source
  103.         code, and REXX operands, might be represented in different
  104.         character codes (perhaps including different notions of white
  105.         space). A cursory scan through TRL did not reveal any support
  106.         for this statemnt.
  107.  
  108.         REXX source code and REXX operands are tightly coupled (actually
  109.         tighter than in any other programming language I am aware of) by
  110.         several language features, e.g.
  111.         - literal strings,
  112.         - INTERPRET statement,
  113.         - SYMBOL, and VALUE, functions
  114.         - SOURCELINE function,
  115.         - VALUE sub-keywords of ADDRESS, SIGNAL, and TRACE  statements,
  116.         - ADDRESS, and TRACE, functions.
  117.  
  118.         To me, this tight coupling suggests that source program and
  119.         operands should ideally be expressed in the same character
  120.         code. If the standard does not require this, it must give
  121.         precise, and simple, rules how every single of these language
  122.         features shall handle the discrepancies -- while trying to
  123.         minimize the astonishing factor.
  124.  
  125.         For less consistent systems, the REXX implementation will somehow
  126.         have to level out the irregularities (regarding character codes,
  127.         particularly white space). The standard may choose to provide
  128.         suitable OPTIONS operands to assist in this regard.
  129.  
  130. Note 2. By default, the STRIP function should remove leading and/or
  131.         trailing white space (rather than blank characters). By default,
  132.         the COMPARE function should ignore white space in the excessive
  133.         part of the longer operand (in other words: when no pad character
  134.         is specified, COMPARE should return 0, iff the longer operand
  135.         consists of an exact copy of the shorter operand, followed by any
  136.         amount of white space, and it should return the position of the
  137.         1st non-white character in the excessive part of the longer
  138.         operand, iff the latter consists of an exact copy of the shorter
  139.         operand followed by anything but white space).
  140.  
  141.         Note that these defaults cannot explicetly be specified via the
  142.         currently valid interface. This idiosyncracy could be removed
  143.         by an additional (yet minor, and upwards-compatible) language
  144.         extension:
  145.         - For the STRIP function, the standard could allow an arbitrary
  146.           string rather than a single character as its 3rd argument;
  147.           the meaning would be to remove sequences of any characters
  148.           specified.
  149.         - For the COMPARE function, the standard could allow an arbitrary
  150.           string rather than a single character as its 3rd argument;
  151.           the meaning would be to ignore, in the excessive part of the
  152.           longer operand, sequences of any characters specified.
  153.  
  154. Note that there is no need to define a canonic form for white space in
  155. operands, as there would be REXX functions to accomplish any desired
  156. transformations, if the above items 1 to 6 became standard. Particularly,
  157. stretches of white space could be easily transformed to single blanks
  158. (to allow for a sensible comparison) by applying the SPACE function.
  159. Note also that this function has already the suggestive name of SPACE
  160. rather than BLANK :-)
  161.  
  162. Best wishes,
  163.                     Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  164.                                <RZOTTO@nyx.uni-konstanz.de>
  165.