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