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

[Mathieu Bouchard]

On Sat, 21 Jul 2007, Frank Barknecht wrote:

> It's not in my responsibility to decide, if and where people may rely
> on the ouput of [unpack] and how they use it, but as I see it, [unpack
> 0 0] is of contract between the patch author and Pd, which states,
> that this construct will always give nothing but two floats.

What is the thing that states it? The help file says that types have to be 
specified, but doesn't say that type checking can be relied upon. The 
source code only says what is being done right now, not what are the 
intents and the expectations.

We could make abstractions that embody contracts and unit-tests, but 
unless they come from Miller or are Miller-approved, this can only be a 
tentative at formalising the distinction between a feature, a limitation, 
an implementation detail, a bug, etc. If it's not Miller, then it has to 
be some authority or some sufficiently explicit consensus. If we don't 
have that, implementing a new feature is a matter of: first do it, then 
try to gather complaints about it, then try to cook up some ex-post-facto 
specification from it. The problem with this is that we're never safe, 
there's always one more opinion that can be contrary to the reconstructed 
contract and which hasn't been stated yet.

> What Matju does is breaking this contract, which I can only explain by
> assuming, that he doesn't view it as a contract, but views the "0 0"
> part more as a kind of default value for something like [unpack
> anything anything].

[unpack] does not have default values. If you unpack a list of length 2 
using [unpack 0 0 0], the last outlet won't be used. The zero is never 
used as a float. So, if one believes that the type declarations only have 
to do with former limitations that have been overcome, the actual 
arguments of [unpack] may be ignored, and instead the actual values of 
them may be used.

[pack] is a rather different beast, so its case has to be considered 
separately: it always outputs the same length of list, and it does use its 
own arguments as defaults, but only if they are floats.

> While I'm a strong subscriber to the "[t a b] and nothing else" idea
> and don't use [t f] anymore, I don't think, that [t f] should ever
> output a symbol,

When something is posted to the console, and it begins with "Error: ", 
how do you distinguish between:

   A) a mistake that the user has to fix,

   B) a limitation whose existence can't be relied upon,

   C) just bad luck (connection refused, out of disk space, file not found)

And/or another similar question - how do you distinguish between:

   1) an error that represents a breach of contract by the user

   2) an error that represents a breach of contract by the implementor

   3) an error whose reporting is required by the contract

   4) an error whose reporting is not specified by a contract, but which
      exists by necessity

   5) an error that is none of the above

   6) a warning

   7) a notice

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