[PD] what distinguishes a numeric symbol as an argument?

[Hans-Christoph Steiner]

I've tried to document odd behavior in Pd.  Here's my collection:

http://pure-data.cvs.sourceforge.net/pure-data/doc/additional/ 
messageoddness/

.hc

On May 31, 2007, at 10:58 AM, Matteo Sisti Sette wrote:

> Hi list
>
> I understand that [symbol 43( is not the same as [43( as it is  
> interpreted
> as a symbol, not a float.
> So I can send the message [symbol 43( to a symbol atom, or to any  
> object
> that works with symbols, and it will be handled just as if it was  
> [symbol
> dog(, right?
>
> However, when this symbol is inserted as an argument into a  
> message, or
> packed into a list, what is it that distinguishes it from the  
> number 43??
>
> Let's make a practical example.
> I want to dynamically set the label of a canvas so that it shows a  
> number.
> Suppose the receive symbol of the canvas is mycanvas_receive.
>
> (1) The following doesn't work:
>
> [label 43(                         (*)
> |
> [s mycanvas_receive]
>
>
> (2) Nor does this:
>
> [43(     (or replace this with a number box)
> |
> [label $1(                         (*)
> |
> [s mycanvas_receive]
>
>
> (3) Nor this:
>
> [symbol 43(
> |
> [label $1(                         (*)
> |
> [s mycanvas_receive]
>
>
> (4) While this DOES work
>
> [43(     (or replace this with a number box)
> |
> [makesymbol %d]
> |
> [label $1(                       (*)
> |
> [s mycanvas_receive]
>
>
> However, I can't see any difference between the output of the  
> message box
> (*) in (4) and in (1-3).
> If I connect that message box to a [print] in any of the four examples
> above, the output is always "label 43".
>
> It seems that the message that is generated in example 4 is  
> intrinsically
> but invisibly different from the previous 3 examples.
>
> I may deduce that each argument of a message has an associated type  
> that
> somewhat depends on its "history" and cannot always be "seen"...  
> which I
> don't like but may be an explanation.
>
>
> However, this does not explain the following:
>
> * Isn't the output of [makefilename] in example (4) just the same  
> as [symbol
> 43( of example 3?? Then why doesn't example 3 work as well???
>
> Also, consider this:
>
> (5)
> [label 43(
> |
> [unpack s f]
>
> and this
>
> (6)
> [symbol 43(
> |
> [label $1(               (**)
> |
> [unpack s f]
>
> In example (5), the second outlet of unpack outputs float 43, which is
> (somewhat) coherent with the fact that example (1) didn't succeed  
> to set the
> canvas label
> However, in example (6) unpack gives the error "unpack: type  
> mismatch"... so
> I guess that the "$1" (i.e. the "43") in (**) is seen as a symbol,  
> not a
> float....... but then, again: why didn't example (3) set the canvas  
> label???
>
>
> Anybody can help me to understand the underlying logic?
>
>
> Oh shit!!!!!!!
>
> Now I see that the following:
> [symbol 43(
> |
> [print]
>
> just outputs "symbol "
>
> while
> [43(
> |
> [makesymbol %d]
> |
> [print]
>
> outputs "symbol 43" as expected....
>
> isn't it weird??????
>
>
> Well... again, if anyone can help me to undertsand this, I'll be  
> grateful
>
>
> Thank you
> m.
>
>
>
>  --
>  Email.it, the professional e-mail, gratis per te: http:// 
> www.email.it/f
>
>  Sponsor:
>  Vacanza in Grecia: 7 giorni con trattamento all inclusive in  
> albergo 4 stelle a soli 479 Euro
>  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6607&d=31-5
>
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/ 
> listinfo/pd-list



------------------------------------------------------------------------ 
----

Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war  
on terrorism.        - retired U.S. Army general, William Odom