Le vendredi 5 mai 2017 19:10:12 UTC+2, Matthias Felleisen a écrit :
> > 1. (define/contract (foo input) (-> blah (listof integer?)) …)
> > 
> >  This has a O(n²) cost.
> I assume input is also a list. Then Racket’s define/contract is NOT O(n²) 
> because the recursion of foo is considered INSIDE the boundary. You have to 
> jump through hoops to get define/contract to check recursive calls. (If it 
> does so now, it’s a bug.)

Well I feel silly, now :) . I didn't know that define/contract had this 
behaviour. I understand much better the "sense of false security" you mentioned 
earlier! Thanks for making this clear.

> > 4. (define/contract (foo input) (-> blah (listof integer?)) …)
> >  where the contract check stops when it encounters an already-checked value.
> [What’s the diff to 1?]

The difference would be that a partial check would be performed at each 
recursion step, stopping when data which has already been validated by the same 
contract is encountered. But that's wishful thinking for now.

> > [… stuff about nanopass …]
> Have you considered using nano-pass specific types? Leif and I did for a 
> brief time, but we moved on to other things. (We had a private exchange on 
> that one.)

Yes, I am using customised variants and structure types, which offer the 
features I need. Typed Racket is still used to perform the actual 
type-checking, as these variants & structures translate down to regular unions 
and structs, with a few adjustments. The run-time checks are only performed for 
things which cannot be easily expressed by the type system, and cannot be 
guaranteed by macro-enforced discipline/design patterns.

You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to