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]
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
