----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Frank Barknecht fbar@footils.org Cc: pd-list@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@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list