[PD] [PD-announce] the end of type restrictions

Mathieu Bouchard matju at artengine.ca
Mon Jul 23 16:05:26 CEST 2007

On Sun, 22 Jul 2007, Frank Barknecht wrote:

> I think, the usefulness, type-checking can have, is obvious, otherwise
> we wouldn't have C. Of course, sometimes it's a pain, otherwise we
> wouldn't have other languages.

I don't think that the choice of C vs other languages is just a matter of 
type checking, nor even just a matter of types. The purpose of types is 
not limited to merely checks. They can also be used for expressing 
conversions and documentation and contracts and polymorphisms.

> But to illustrate where the type-checking of [unpack] is useful, see 
> attached patch: If I have an [unpack 0 0 0] in my patch, and after that 
> some math calculations on numbers, then if a symbol message reaches the 
> [unpack 0 0 0], for years now I *know* that the error in my patch has to 
> be somewhere before that unpack. This makes looking for the bug a bit 
> easier and I admit: I'm used to this behaviour of unpack.

What you wrote in the patch... I made exactly the same argument to a quite 
different group of people some years ago. It was about whether or not 
interfaces should be declared in the program itself and be checked. Ruby 
people tend to be very much into skipping all type checks.

What I didn't think about until yesterday is that if I want to define a 
method in pd using pd itself, how would i typically do that? well, I would 
use a [route] as the method dispatcher; then I might use [list] to revert 
the implicit [list trim] that [route] does; then I have an argument list, 
which is an actual list. from that I can take $1 $2 $3... using 
messageboxes or... using [unpack]. Now if one wanted to add typechecking 
in a location similar to where it usually happens? It probably would be 
next to [unpack] or inside [unpack].

> Your insistence on changing [unpack] itself is what I cannot
> understand.

My first thought was that [unpack]'s job is just to unpack, and that many 
typechecks in pd occur because of technical limitations that need not 
exist, or as optimisation tricks that aren't as optional as they could be 
- e.g. so far, [unpack]'s "p" takes more RAM, because handling "p" 
generally takes more RAM for anything that wants to handle it correctly.

I didn't think much of [unpack] being used expressly for the purpose of 

Interestingly, this sort of circumstance happens even with extremely 
underdeveloped type systems like Pd... 3 atom types (actually 7, but I 
won't count the 4 that only exist within messageboxes). DesireData is down 
to only 2 for now, but I'm still planning to go up to 4 (and not 5 as I 
was saying last year). Yet we're having the same issues with that few atom 
types as in languages in which there are dozens of types and ability for 
user-defined types and plenty of actual ubiquitous practice of using the 
user-defined types.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

More information about the Pd-list mailing list