Thank-you Matthias
That's neat!
And yes, I can write a basic macro. By introducing #:freevar I was able to
improve the blame situation, but the abstraction is a bit leaky ...
(define-syntax-rule (define/tight (fn args ...)
ctc
body ...)
(begin
(d
Sure:
#lang racket
(define/contract [unsafe-factorial n]
(-> (and/c integer? (>=/c 0)) (and/c integer? (>=/c 0)))
(if (zero? n)
1
(* n (factorial (- n 10)
(define (factorial n) (unsafe-factorial n)) ;; cross the boundary and go right
back in
(unsafe-factorial 5) ; Does n
Hi Matthias
Thanks for the pointer to Robby's 2014 keynote.
Here's the link for those interested — it's really good:
https://www.youtube.com/watch?v=gXTbMPVFP1M
* * *
In regard to Racket's use of boundaries, am I right in thinking that it's
difficult to pull the boundaries in really *tight*?
Racketeers,
(seventh RacketCon) will be held on October 7th, followed by Racketeer
Office Hours on October 8th. This year, RacketCon will be in Seattle, WA,
with support from the Racket group at the University of Washington.
We are pleased to announce that Dan Friedman and Will Byrd will be
givin
Dear Colleagues,
My apologies if you receive this more than once on different lists.
Please consider submitting your novel ideas and classroom techniques to TFPIE
2017. The call for papers is below with detailed information. Keep in mind that
the deadline for submission is approaching, but onl
> On May 5, 2017, at 1:21 PM, Dupéron Georges
> wrote:
>
>>
>> [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
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
> On May 5, 2017, at 11:30 AM, Dupéron Georges
> wrote:
>
> Le vendredi 5 mai 2017 16:36:49 UTC+2, Matthias Felleisen a écrit :
>> I think that developers should write contracts and use them during testing
>> and deployment in the same way. I did this decades ago for embedded realtime
>> soft
Le vendredi 5 mai 2017 16:36:49 UTC+2, Matthias Felleisen a écrit :
> I think that developers should write contracts and use them during testing
> and deployment in the same way. I did this decades ago for embedded realtime
> software and we’d be all better off if we did so.
I agree that I alwa
> On May 5, 2017, at 10:05 AM, Dupéron Georges
> wrote:
>
> Le vendredi 5 mai 2017 15:24:40 UTC+2, Matthias Felleisen a écrit :
>> See
>> https://docs.racket-lang.org/style/Units_of_Code.html#%28part._.Modules_and_their_.Interfaces%29
>
> That's a very interesting document, thanks for the ref
Le vendredi 5 mai 2017 15:24:40 UTC+2, Matthias Felleisen a écrit :
> See
> https://docs.racket-lang.org/style/Units_of_Code.html#%28part._.Modules_and_their_.Interfaces%29
That's a very interesting document, thanks for the reference. Would you suggest
that, in this spirit, types for functions a
> On May 4, 2017, at 8:40 PM, Dupéron Georges
> wrote:
>
> Le vendredi 5 mai 2017 02:30:50 UTC+2, Ben Greenman a écrit :
>> With a `define/contract-out` macro?
>>
>> But I'd rather not have a macro like this in the contract library.
>> I prefer reading code with all the "provide" statements
12 matches
Mail list logo
