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
For more options, visit https://groups.google.com/d/optout.