Just a curiosity question related to the "Function" command...

[mathewsdw]

As I indicated in the subject line, I've found a work-around that is not particularly inconvenient. However, I do wonder why the situation is happening in the first place. So I will illustrate with an annotated "dump" of a complete TCC session:

   Fri  Dec 2, 2011  12:59:12p

ISO8601 plugin v1.1.1 loaded.
SafeChars plugin v1.5.7 loaded.

TCC  12.11.76   Windows 7 [Version 6.1.7601]
Copyright 2011  Rex Conn & JP Software Inc.  All Rights Reserved
Registered to Daniel Mathews

[Z:\]Function ReplaceChar=`%@Left[%@Dec[%2],%@UnQuote[%1]]%@UnQuote[%3]%@Right[-%2,
%@UnQuote[%1]]`

This is a much cut-down version of the "real" function which has some error handling and "special case" functionality which I've "stripped out" for demonstration purposes. As can be seen I am defining a rather simple function "ReplaceChar" that replaces the character in the string supplied as parameter one to the function by the string supplied as parameter three to the function at the position specified by parameter two to the function. (I will note here that the "position" is 1-based as opposed to 0-based as is true of many of Rex's built-in functions.)

The first example, which is a little bit "odd" but not at all a problem because it can easily be "worked around" (by putting the third parameter in double quotes):

[Z:\]Echo %@ReplaceChar[ABCDEF,4,This Will Replace the Fourth Character]
ABCThisEF

The second example showing that the previously-mentioned "work around" does, in fact work:

[Z:\]Echo %@ReplaceChar[ABCDEF,4,"This Will Replace the Fourth Character"]
ABCThis Will Replace the Fourth CharacterEF

The third example, where the previously-mentioned "work around" absolutely did not work (at all):

[Z:\]Echo %@ReplaceChar[ABCDEF,4,"        "]
ABCEF

As you can easily see in the above, the "D" was eliminated but absolutely no spaces were inserted in the character string at its former position.

And finally, the one that "worked" (by surrounding parameter three with back-quotes):

[Z:\]Echo %@ReplaceChar[ABCDEF,4,`        `]
ABC        EF

The question is "Why is that needed?" or maybe "Why dosn't the third example work?".

 

[samintz]

Dan,

The issues you are seeing relate to parameter parsing. Spaces, tabs,
commas, and forward slashes delimit parameters to a function.

So if I define a function like this:
function foo=`"%1" : "%2" : "%3$"`

And I invoke that function with comma delimited parameters vs space
delimited, I get the same results:
[R:\] echo %@foo[1,2,3]
"1" : "2" : "3"

[R:\] echo %@foo[1 2 3]
"1" : "2" : "3"

However, you'll notice that I used %3$ as my third argument in the
function definition. That means 3rd parameter plus all the rest.
So if I invoke that same function like this:

[R:\] echo %@foo[1 2 3 4 5 6 7 8 9]
"1" : "2" : "3 4 5 6 7 8 9"

Now, your second question about the spaces is caused for the same reason.
The parser removes trailing spaces.

Using your function as an example:
[R:\] echo %@ReplaceChar[test 3 " "]
tet

[R:\] echo %@ReplaceChar[test 3 " 123 "]
te 123t

Backquotes prevent the parser from removing the trailing spaces.

Look at the Parameter Quoting section of the help for a very detailed
description.

-Scott




As I indicated in the subject line, I've found a work-around that is not
particularly inconvenient. However, I do wonder why the situation is
happening in the first place. So I will illustrate with an annotated
"dump" of a complete TCC session:

Code:
Fri Dec 2, 2011 12:59:12p

ISO8601 plugin v1.1.1 loaded.
SafeChars plugin v1.5.7 loaded.

TCC 12.11.76 Windows 7 [Version 6.1.7601]
Copyright 2011 Rex Conn & JP Software Inc. All Rights Reserved
Registered to Daniel Mathews

[Z:\]Function
ReplaceChar=`%@Left[%@Dec[%2],%@UnQuote[%1]]%@UnQuote[%3]%@Right[-%2,
%@UnQuote[%1]]`
This is a much cut-down version of the "real" function which has some
error handling and "special case" functionality which I've "stripped out"
for demonstration purposes. As can be seen I am defining a rather simple
function "ReplaceChar" that replaces the character in the string supplied
as parameter one to the function by the string supplied as parameter three
to the function at the position specified by parameter two to the
function. (I will note here that the "position" is 1-based as opposed to
0-based as is true of many of Rex's built-in functions.)

The first example, which is a little bit "odd" but not at all a problem
because it can easily be "worked around" (by putting the third parameter
in double quotes):

Code:
[Z:\]Echo %@ReplaceChar[ABCDEF,4,This Will Replace the Fourth Character]
ABCThisEF
The second example showing that the previously-mentioned "work around"
does, in fact work:

Code:
[Z:\]Echo %@ReplaceChar[ABCDEF,4,"This Will Replace the Fourth Character"]
ABCThis Will Replace the Fourth CharacterEF
The third example, where the previously-mentioned "work around" absolutely
did not work (at all):

Code:
[Z:\]Echo %@ReplaceChar[ABCDEF,4," "]
ABCEF
As you can easily see in the above, the "D" was eliminated but absolutely
no spaces were inserted in the character string at its former position.

And finally, the one that "worked" (by surrounding parameter three with
back-quotes):

Code:
[Z:\]Echo %@ReplaceChar[ABCDEF,4,` `]
ABC EF
The question is "Why is that needed?" or maybe "Why dosn't the third
example work?".

 

[mathewsdw]

Dan,

The issues you are seeing relate to parameter parsing. Spaces, tabs,
commas, and forward slashes delimit parameters to a function.

...

-Scott

Scott, of course you are correct. The major problem I have is that from my 30+ years of writing programs in about a dozen other programming languages I deeply expect (without really thinking about it) that double quotes will have more "meaning" than they often do in TCC, although, I am also aware, when I think about/remember it, that that is often not the case in TCC (something "inherited" from cmd.exe??? I haven't used that command processor on a "consistent" basis since about Windows 3.1, so I really wouldn't know.). A basic issue related to deeply-ingrained programming "habits"...