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
typechecking.
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
_______________________________________________
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
