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

Hans-Christoph Steiner hans at at.or.at
Sun Sep 4 20:22:47 CEST 2011

On Sep 4, 2011, at 2:01 PM, Jonathan Wilkes wrote:

> ----- Original Message -----
>> From: Mathieu Bouchard <matju at artengine.ca>
>> To: Jonathan Wilkes <jancsika at yahoo.com>
>> Cc: Chris McCormick <chris at mccormick.cx>; Miller Puckette <msp at ucsd.edu 
>> >; "pd-list at iem.at" <pd-list at iem.at>
>> Sent: Sunday, September 4, 2011 1:48 PM
>> Subject: Re: [PD] (breaking symbols) was Re: find a list of numbers  
>> in a text file
>> On Sat, 3 Sep 2011, Jonathan Wilkes wrote:
>>> It needs to be that simple for the general case because Pd Vanilla  
>>> has no
>> (sensible) mechanism to convert a symbol atom into a float.
>> Then it needs a sensible mechanism to convert a symbol atom into a  
>> float.
> Yes, it does.  But if there were one, it'd still be nice to have the  
> default be float
> atoms come out, and maybe a flag or a different creator name for  
> outputting all
> symbols. (Like [symbol explode]?)

Its more than just methods for converting, there needs to be a type  
system which includes the possibility that "43" can be a symbol.  Pd's  
type system is meant to be "anything that can be intepreted as a  
number is a float, everything else is a symbol".  See this for  

So given that is the type system, how do you represent "43" as a  
symbol?  No matter the techniques for converting anything to a symbol,  
it'll remain confusing to use these symbols unless this is resolved.

One possibility is to do a more duck-typing approach.  For something  
that accepts only symbols, it'll happily accept "43" as a symbol.  For  
something that only accept floats, it'll convert the symbol "43" to 43  
and accept it as a float.  The question here is how to handle it when  
something expects both floats and symbols.  As far as implementing  
this, we could add to the t_symbol struct a flag to say whether it can  
be read as a float, and store the float value there too.

This would open the door to making arbitrary symbol making really  
easy, something like:

[symbol 43(


[symbol 43]


>>> If symbol atoms which look like numbers to the naked eye are going  
>>> to start
>> flying around more freely in Pd then the docs need to explain how  
>> atoms are a
>> kind of weird file cabinet where the label on the cabinet tells you  
>> which
>> file-folder inside actually holds the data.
>> That's called a union or a variant record type or an «any» type or a
>> sum-type or whatever else.
>> If it looks weird and/or difficult, it's because it's not taught in a
>> way that makes it understood as normal.
> I think the problem is it's not explicitly taught at all.
>>> Also, I'm assuming [list implode] would accept and process a list at
>> the left inlet, unlike [s2l] (which passes the 1st element to the  
>> right inlet).
>> I don't understand. Wouldn't [list implode] correspond to [l2s],  
>> whereas
>> [list explode] would correspond to [s2l].
> That's right, I wrote the wrong one.  I have a bad habit of getting  
> opposites
> mixed up-- if I'm not careful I'll create a [max] to output the  
> greater of two numbers.
>> _______________________________________________________________________
>> | Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray,  
>> Montréal, QC
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list


"[W]e have invented the technology to eliminate scarcity, but we are  
deliberately throwing it away to benefit those who profit from  
scarcity."        -John Gilmore

More information about the Pd-list mailing list