[PD] (breaking symbols) was Re: find a list of numbers in a text file
Jonathan Wilkes
jancsika at yahoo.com
Mon Sep 5 21:32:59 CEST 2011
----- 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
>
More information about the Pd-list
mailing list