clipka <ano### [at] anonymousorg> wrote:
> Yup - quote from the change log on <http://www.povray.org/beta/>:

>  >> -------------------------------------------
>  >> Changes between 3.7.beta.22 and 3.7.beta.23
>  >> -------------------------------------------
>  >>
>  >> ...
>  >> Added comparison ('=', '!=', '<', '<=', '>', '>=') support for strings.

  Btw, back then I also tried to add support for string concatenation using
operator + so that you could write

    "value=" + str(value,0,-1) + "\n"

instead of having to write

    concat("value=", str(value,0,-1), "\n"))

but I hit a wall because of how the parsing works. A straightforward
implementation might sound trivial for anybody who has programmed for the
parser code, but there are surprising pitfalls. If you try to support string
concatenation by using the + operator, you end up having SDL like this:

    #debug "Hello\n"
    #debug "there!\n"

print out:

    there!
    Hello

  The reason for this might not be immediately obvious, but should be so
for people who know how the parser works, when pointed out like this. It
has to do with how the parser interprets #-commands while it's scanning
for the next token (iow. in this case checking if a '+' token follows the
string after the first #debug). And no, turning off the #-command
interpretation during the check doesn't work because then you end up in
a situation where you pull out a #-token, after which you have broken the
'#debug' into two tokens, after which you end up with a parsing error about
a lone '#' having been found.

  The problem is not trivial to solve with the current parser. On the other
hand, by far the most common place where people need string concatenation is
with #debug, so I thought of an alternative solution to make printing messages
easier, something like:

    #print "value=", value, "\n";

  The #print-command would take comma-separated elements and smartly interpret
them according to their type (ie. if it's a string, it just prints it, if
it's a numerical identifier it prints it with default accuracy, if it's a
vector, it prints with default accuracy and delimiters, etc.)

  Never got past the planning stages, though (although the team's opinion on
that suggestion was positive). However, there's still time to add it if
someone is willing to make some minor development.

-- 
                                                          - Warp

Post a reply to this message