[plt-scheme] Contracts and (multiple-return-)values

This is a bit orthogonal to your complaints, which I assume will be  
answered with "but you violated a contract between the application  
operation and the procedure, which is handled by mzscheme and  
therefore doesn't provide the same level/kind/appropriate word spliced  
in here of error messages." See recent plt-dev thread on same topic.

So after this preliminary remark, my orthogonal comment:

You are clearly using the contract system to perform type checking --  
at run-time. I recommend you program in Typed Scheme instead. If you  
did, the type system would signal this mistake before you ever run  
your code, including on unit tests. I know that Untyped does use Typed  
Scheme on occasion. Well here is another one.

-- Matthias





On Nov 26, 2009, at 10:47 AM, David Brooks wrote:

> Hi PLTers,
>
> I've just had a bit of grief with the intersection between  
> procedures returning multiple values, their contracts, and my  
> careless programming. (I'm sure this is a question with a Noddy  
> answer, but I've not drummed up anything in my googling.)
>
> I wrote a procedure returning multiple values: (values a b), where  
> "a" is a struct and "b" is a list of structs of type "c". I gave  
> this procedure a contract accordingly:
>
> [my-proc (-> (values a? (listof c?)))]
>
> After getting bored of all the different "let" and "let-values"  
> blocks, I decided to change the procedure to return (cons a b).  
> However, I forgot to change the contract (d'oh!), so when I ran my  
> code I got an error of the form:
>
> context (lexical binding) expected 2 values, received 1 value:  
> (#(struct:a ...) #(struct:c ...) #(struct:c ...) ...
>
> I spent a little while examining all my lexical assignments  
> procedure return-types, before I realised this was a contract  
> violation, but one that wasn't being flagged as such.
>
> So my questions are
> [1] does the contract system offer any protection against misuse of  
> "values"? If so, how do I use it? If not, is there an interesting  
> technical reason why not?
> or [2] is there any way I can get more meaningful error messages if  
> I am stupid enough to repeat my mistake?
>
> Cheers,
> D
> --
> David Brooks
> http://www.untyped.com
>
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme