[PD] (breaking symbols) was Re: find a list of numbers in a text file

Hans-Christoph Steiner hans at at.or.at
Mon Sep 5 20:34:30 CEST 2011

On Sep 5, 2011, at 2:06 PM, Frank Barknecht wrote:

> On Mon, Sep 05, 2011 at 01:36:34PM -0400, Hans-Christoph Steiner  
> wrote:
>> On Sep 5, 2011, at 1:11 PM, Mathieu Bouchard wrote:
>>> On Sun, 4 Sep 2011, Hans-Christoph Steiner wrote:
>>>> So in the sense of Pd, anything that can be intepreted as a
>>>> number should be.
> This discussion is soooo 2005 ...

And sadly is still unresolved...

> Anyway, a symbol, even if it consists only of digits, will not be
> interpreted as a number in Pd: a symbol is a symbol, a float is a  
> float.
> Note that the sentence that you quote sometimes and which sounds  
> similar
> to the statement above ("Anything that is not a valid number os [sic!]
> considered a symbol." from
> http://crca.ucsd.edu/~msp/Pd_documentation/x2.htm#s3.1) is talking  
> about
> the content of [object boxes] (or more generally: about the Pd  
> editor).
> Here this sentence is true, but you know that not every data entity in
> Pd can be used in object boxes as name or argument, while most things
> that looks like a number will become one here.

I agree that the implementation does not match the descriptions in the  
manual.  That's what is in important here.  Yes, its possible to  
generate any kind of symbols using certain techniques, but it is not  
possible to generate any kind of symbol using any kind of symbol  
generation.  That's one example of where the inconsistency is a pain.   
Try [symbol 43( for example, or this:


Is it really a good idea to have a separate type system in object  
boxes versus the rest of Pd? What we need to come up with first is a  
coherent idea of what Pd's type system should be, or make Pd  
consistent with the idea it was built around.  Otherwise we'll forever  
have a confusing, hack job system where different objects and  
externals have different ideas of how to intrepret symbols (which is  
basically what we have now).  Name another language you want to use  
that doesn't have consistent typing?

>>>> But that's in conflict with having symbols
>>>> that have things that can be intepreted as a number.  So make Pd
>>>> consistent, either it needs to be illegal to have symbols that
>>>> can be interpreted as a number,
>>> This could break some existing patches.
>> Do you have an examples?  That would be very helpful.  Off the top
>> of my head, it seems that it would only break patches that rely on
>> errors, which is not a very common situation.
> What errors would patches rely on that use [makefilename %d] to  
> generate
> a symbol?

That's a clear case of where my proposed solution would help.  Things  
that expect symbols would interpret the message from [makefilename %d]  
as a symbol, and things that expect floats would interpret the message  
from [makefilename %d] as a float.  So the kind of thing I'm talking  
about would be like this:

[makefilename %d]

Then having the patch rely on the "error: float: no method for  
'symbol'" error that is normally generated in that case.  The part I  
don't have a clear idea on is for things that expect both a symbol and  
a float, how should [makefilename %d] be interpreted.  My guess now is  
that it should be interpreted as a symbol in that case.



Computer science is no more related to the computer than astronomy is  
related to the telescope.      -Edsger Dykstra

More information about the Pd-list mailing list