Warp wrote:
> Felix Wiemann wrote:
>> Where's the problem with concat?
> 
>   Have you tried just enclosing the string in parentheses?

What do you mean? Enclose the variable name in parentheses? That of course 
won't work. Note that the string itself is normally not available before 
parsing so it's necessary to use a variable.

>> Is much longer. So not better but worse.
> 
>   Perhaps you should learn some basics of (modular) programming.
>   "It's much longer" is a really poor excuse for making bad code.

Hmmm... The SDL is actually not very modularized. It's more a description 
language than a programming language. Macros and functions are possible but 
structures or even classes aren't supported. When I want to write a program 
for POV-Ray, I write a C++ program which generates SDL code.

>   You have to write one #local more - so what? The alternative is to write
> an extra 'concat()' several times, which makes the code quite obfuscated
> and longer.

OK, normally it's better to write well understandable code, but I'm 
currently working on my signature, so in this case it's very important to 
save even a few bytes.
And IMHO it's not a problem to understand what concat with one parameter 
does.
-- 
Felix Wiemann

Post a reply to this message

Felix Wiemann <Fel### [at] gmxnet> wrote:
>>   Have you tried just enclosing the string in parentheses?

> What do you mean? Enclose the variable name in parentheses?

  I said "string", not "variable name".

  When you call your macro, do: MyMacro(("The string"))

>>   Perhaps you should learn some basics of (modular) programming.
>>   "It's much longer" is a really poor excuse for making bad code.

> Hmmm... The SDL is actually not very modularized.

  That doesn't mean you shouldn't make your code as modular as the language
allows.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Wed, 22 May 2002 07:59:33 -0500, Felix Wiemann wrote:

> Where's the problem with concat? It works fine. Aren't POVers (and
> computer users in general) known for using a function for something
> totally different than it was designed for? And I don't see any
> possibility that's as short as concat.

It's common so it must be good?
I already explained the problem with using concat(). It is intended for
concatenating strings, not cloning them. To anyone reading the code, it
looks like you made a mistake: the code does not do what it says it does.
That is a bad thing.


>> If you don't want to declare a temporary variable, a macro is a better
>                                                                   ^^^^^^
> Why?

If you really can't tell...I give up.


>> solution than misusing the concat() function. Something like:
>> 
>> #macro clonestring(String)
>>     #local tmpString = String
>>     tmpString
>> #end
> 
> Is much longer. So not better but worse.

I hope I never have to maintain anything you write...

It is longer by 5 characters, because its name says what it does. That is
a good thing. If the extra 5 characters is that bad, rename it: call it
clnstr() or something. And if you are using it multiple times, it would be
better to skip the macro completely and just use a temporary variable...in
that case, it is shorter than your misuse of the concat() function: the
usual naming convention just adds "tmp" or something similar, which is 5
characters shorter than a call to concat().


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

Warp wrote:
> Felix Wiemann wrote:
>>>   Have you tried just enclosing the string in parentheses?
> 
>> What do you mean? Enclose the variable name in parentheses?
> 
>   I said "string", not "variable name".
> 
>   When you call your macro, do: MyMacro(("The string"))

Sorry, I thought of quotation marks.
In this example it doesn't make sense. MyMacro((S)) doesn't work either, 
error: "Expected 'numeric expression', string identifier found instead"

>> Hmmm... The SDL is actually not very modularized.
> 
>   That doesn't mean you shouldn't make your code as modular as the
>   language
> allows.

You're right. As I said, I need it for a signature, so it's important that 
it's very short.

INGO, could you perhaps update the doc?
| concat(S1,S2,...)
to
| concat(S1,...)
or something similar.
-- 
Felix Wiemann

Post a reply to this message

Christopher James Huff wrote:
> It's common so it must be good?
> I already explained the problem with using concat(). It is intended for
> concatenating strings, not cloning them. To anyone reading the code, it
> looks like you made a mistake: the code does not do what it says it does.
> That is a bad thing.

ACK.

>>> solution than misusing the concat() function. Something like:
>>> 
>>> #macro clonestring(String)
>>>     #local tmpString = String
>>>     tmpString
>>> #end
>> 
>> Is much longer. So not better but worse.
> 
> I hope I never have to maintain anything you write...

If one knows that concat(S) creates a copy, it won't be a problem.
OK, *if*.

> It is longer by 5 characters, because its name says what it does. That is
> a good thing. If the extra 5 characters is that bad, rename it: call it
> clnstr() or something. And if you are using it multiple times, it would be
> better to skip the macro completely and just use a temporary variable...in
> that case, it is shorter than your misuse of the concat() function: the
> usual naming convention just adds "tmp" or something similar, which is 5
> characters shorter than a call to concat().

Sorry, I wrote that from my current point of view. I'm writing a signature, 
so the chars needed to declare the macro (or the temporary variable) are 
important, too.
-- 
Felix Wiemann

Post a reply to this message

Felix Wiemann <Fel### [at] gmxnet> wrote:
>>   When you call your macro, do: MyMacro(("The string"))

> Sorry, I thought of quotation marks.
> In this example it doesn't make sense. MyMacro((S)) doesn't work either, 
> error: "Expected 'numeric expression', string identifier found instead"

  Well, it was just a guess from my part.
  With floating point numbers it works, but apparently not with strings.

> You're right. As I said, I need it for a signature, so it's important that 
> it's very short.

  There's probably another way of doing it without concats and locals. ;)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

I think this whole discussion is pointless. The use of concat() with one
parameter of course shouldn't be arbitrarily restricted, since some might
find it useful. But I think the docs shouldn't be changed either, since it
would only encourage people to make their scripts more confusing.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

Felix Wiemann wrote:

> #debug concat("POV")
>
> works fine, but the doc says:
>
> concat(S1,S2,...)
>
> IMO the doc and not the function should be changed because this is a useful
> feature ...

I agree this is a useful feature, although for different reasons.
Consider the following macro:

#macro reverse_string (s)

concat(
  ""
  #local j=strlen(s);
  #while (j>0)
    ,substr(s,j,1)
    #local j=j-1;
  #end
)

#end

It is essential for use with the empty string that concat still works with
only one parameter. This macro is a quick hack and probably not the
best way to reverse a string, so consider it just an example.

  Mark Weyer

Post a reply to this message

On Mon, 27 May 2002 09:00:37 +0200, Mark Weyer
<wey### [at] fregemathematikuni-freiburgde> wrote:
> I agree this is a useful feature, although for different reasons.
> Consider the following macro:
> #macro reverse_string (s)

#macro reverse_string (s)
  #if(strlen(s)>1)
    concat(
      #local j=strlen(s);
      #while (j)
        substr(s,j,1)
        #local j=j-1;
      #end
    )
  #else
    s
  #end
#end

ABX

Post a reply to this message

I suppose, I did not make myself clear enough.
Of course there would be workarounds if concat(s) was
prohibited. The point is, that these are not as clearly readable
or writable any more. To provide a better example:

#macro foo_string(s)
  concat(
    ""
    #local i=0;
    #while (i<strlen(s))
      #local i=i+1;
      ,... //(do something longish with the i-th caharacter of s)
    #end
  )
#end

With your case distinction one would have to write the longish stuff
"..."
twice or declare a macro/function that does it.
The former is errorprone (consider changes later apllied to "...")
and not as readable (the human has to parse "..." twice).
The latter would introduce a macro/function to the namespace that will
probably never again be used and also inhibits fluent parsing by the
human.

But still, the point is not to argue over specific examples.
Concatenation is a binary operation that fulfills the axioms of monoids.

Hence it is canonically extendable to an operation taking lists of
strings as input.
As the povary team has decided to provide this generalization, it is
natural
to allow ALL lists of strings, especially one-element lists and the
empty list.
OK, I know the empty list, ie. concat(), is not permitted,
but that is a different story...

  Mark Weyer

Post a reply to this message