From: zjlc12@hou.amoco.com (Jerry Campbell)
Newsgroups: comp.lang.rexx
Subject: Re:      Re: Blanks, REXX, and portability...
Date: 11 Sep 92 19:08:34 GMT
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco

In article 92091111123047@DEARN,         Otto Stolz <RZOTTO@DKNKURZ1.BITNET> () writes:
>Every program exploiting word-oriented operations will intrinsically
>give up controll over the exact number of blanks. What is so horrible
>about the idea of extending these operations, reasonably, to cover *all*
>instances of words the programmer would expect in a given environment?
>Nobody has ever proposed to take control away from the programmer!
>Everybody shall be free to apply the operations best suited to his or her
>problem -- even in REXX :-)
>

Ok, maybe I screamed wolf when it were only the lambs bleating.  Control over
what constitutes a word delimiter would be a nice thing to have.  Certainly
on a Uni* system.  But let me interject another, but!  And its a small but!
But!  Make sure than I can do things like this:

  data = 'one \tabchar two three'
  word2 = Word(data,2)

...and... have word2 equal to the _blank delimited_ tab character 

I assume you're proposing, with some as yet unspecified mechanism, to be
able to have the obvious alternate possibility work as well:

   data = 'one \tabchar two three' 
   word2 = Word(data,2)

....and... word2 will be equal to the characters 'two'

How will you make this possible?  I'm sorry but nobody will ever convince
me to give up the functionality represented by the first code fragment. 
And I certainly won't swallow having a Uni* interpreter behave differently
in this respect than a VM interpreter. 

I can't offer an opinion bolstered with the finer principles of language
design.  But! (there's another one) I will stand up for the average
programmer and tell you what I think! 

>.............................. and may help to confine the discussion
>to the relevant point, viz. how word-oriented operations should be
>defined (not touching character-oriented operations, at all).
>

Ok, thanks for the clarification.  Sorry to be one of the causes 
of a time wasting digression, I wasn't paying close enough attention.

Ok, Ok, what's the problem then?  What shall we allow as word delimiters?
And how shall the programmer have control over the interpretation/use of these
delimiters when computing on data?  Easy, generalize the concept of delimiters.
Encourage interpreter writers to provide a set of default characters
which are specific to the environment.  And then add another parameter to all
the word oriented functions by which an alternate set of delimiting characters
may be specified.  For cases such as,  is ' a' = '\wa'   (\w means whitespace)
let the general form of comparator use the implementation default set of delimiter
characters for leading/trailing character fudging.  In other words,
' a' = '\wa'  is true,  ' a' == \wa' is false.  

To summarize:

    1 - a word delimiter is not just a blank space, it can be anything, given
        the further following qualifications.
    2 - each interpreter implementor may choose to select a set of default 
        delimiter characters (that may be thought of as whitespace).
    3 - each word oriented, builtin function will have an extra parameter that
        can be used to override the implementation default.  
    4 - logical comparisons will use the implementation default delimiters to
        fudge the ends of strings.  Unless the strict comparator operators are 
        used.  

This seems straightforward to me. The only thing missing is a way for the 
programmer to completely override the implementation default delimiter set. 
Perhaps something like,  Options Stream Delimiter 'abc',  for input streams, or, 
Options Builtin Delimiter 'itseasyas', for builtin functions, or, 
Options Default Delimiter '123', for global effect.   

---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036
Newsgroups: comp.lang.rexx