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