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

[Jonathan Wilkes]

----- Original Message -----

> From: Hans-Christoph Steiner <hans at at.or.at>
> To: Frank Barknecht <fbar at footils.org>
> Cc: pd-list at iem.at
> Sent: Monday, September 5, 2011 2:34 PM
> Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers in a text file
> 
> 
> 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:
> 
> [43(
> |
> [symbol]
> 
> 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]
> |
> [float]

Hm, how about making it so that a Pd selector cannot be anything that could be interpreted 
as a valid number in Pd?  In other words, convert any "numeric" selector to a float atom:

[12(
|
[makefilename %d]
|
[list trim]  <-- selector '12' becomes a float atom '12'
|
[float]  <-- float atom has implicit 'float' selector, so it is accepted at the inlet

I don't think this would break existing patches, except in really obscure cases.

-Jonathan

> 
> 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.
> 
> .hc
> 
> ----------------------------------------------------------------------------
> 
> Computer science is no more related to the computer than astronomy is related to 
> the telescope.      -Edsger Dykstra
> 
> 
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>