[PD] [PD-announce] the end of type restrictions
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
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
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
More information about the Pd-list