Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Daniel Prager]

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
(define (fn args ...) (fn/impl args ...))
(define/contract (fn/impl args ...)
  ctc
  #:freevar fn ctc; Directs blame to "fn/impl" rather than the
enclosing module
  body ...)))

Dan


On Sat, May 6, 2017 at 11:15 AM, Matthias Felleisen 
wrote:

>
> 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 not terminate
>
>
> I suspect you can implement this with a macro now.
>

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Matthias Felleisen]

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 not terminate


I suspect you can implement this with a macro now. 



> On May 5, 2017, at 5:48 PM, Daniel Prager  wrote:
> 
> 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*?
> 
> For instance, the following example does not terminate and cannot help with 
> the necessary debugging because the contract is only checked on the call 
> through the module boundary, with recursive calls incorrectly and implicitly 
> trusted:
> 
> 
> #lang racket
> 
> (module server racket
>   (provide (contract-out
> [unsafe-factorial (-> (and/c integer? (>=/c 0))
>   (and/c integer? (>=/c 0)))]))
>
>   (define (unsafe-factorial n)
> (if (zero? n) ; Naïvely relying on the 
> contract to rule out -ve n's
> 1
> (* n (unsafe-factorial (- n 10))  ; Bug
> 
> 
> (require 'server)
> 
> (unsafe-factorial 5) ; Does not terminate
> 
> 
> My best idea at the moment is to add some extra checking, e.g. (just 
> duplicating the pre-conditions) ...
> 
>   (define (safe-factorial n)
> (unless (integer? n)
>   (raise-argument-error 'safe-factorial "n must be an integer" n))
> (unless (>= n 0)
>   (raise-argument-error 'safe-factorial "n must be >= 0" n))
> (if (zero? n)
> 1
> (* n (safe-factorial (- n 10))
> 
> ... but this is verbose, no good for higher-oder conditions, and redundant: 
> once it has been debugged the contract at the module-boundary suffices.
> 
> What do others do / suggest?
> 
> 
> Dan
> 

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Daniel Prager]

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*?

For instance, the following example does not terminate and cannot help with
the necessary debugging because the contract is only checked on the call
through the module boundary, with recursive calls incorrectly and
implicitly trusted:


#lang racket

(module server racket
  (provide (contract-out
[unsafe-factorial (-> (and/c integer? (>=/c 0))
  (and/c integer? (>=/c 0)))]))

  (define (unsafe-factorial n)
(if (zero? n) ; Naïvely relying on the
contract to rule out -ve n's
1
(* n (unsafe-factorial (- n 10))  ; Bug


(require 'server)

(unsafe-factorial 5) ; Does not terminate


My best idea at the moment is to add some extra checking, e.g. (just
duplicating the pre-conditions) ...

  (define (safe-factorial n)
(unless (integer? n)
  (raise-argument-error 'safe-factorial "n must be an integer" n))
(unless (>= n 0)
  (raise-argument-error 'safe-factorial "n must be >= 0" n))
(if (zero? n)
1
(* n (safe-factorial (- n 10))

... but this is verbose, no good for higher-oder conditions, and redundant:
once it has been debugged the contract at the module-boundary suffices.

What do others do / suggest?


Dan

-- 
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.

[racket-users] (seventh RacketCon) Call for Speakers

[Vincent St-Amour]

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
giving this year's keynote!

RacketCon[1] is a yearly event where members of the Racket community get
together, featuring talks and demos about the things you do with Racket.
Racketeer Office Hours is a free-form day for Racketeers to get together
and collaborate on ongoing projects, start new ones, and get help and
advice from other members of the community.

If you've built something cool with Racket, we want to hear about it!
We're looking for speakers to give 15 minute talks about their Racket-
based applications, libraries, activities, etc. If that sounds like fun,
please send me a talk proposal! Please note, though, that because of
time constraints, we may not be able to accept all proposals.

RacketCon attendees benefit from a group rate[2] a the Hotel Deca[3],
near the venue. Registration is not open yet, but we'll let you know
when it is.

Hope to see you in Seattle!

Vincent, for the RacketCon team


[1] http://con.racket-lang.org/
[2] 
https://gc.synxis.com/rez.aspx?Hotel=76675=10069=10/6/2017=10/8/2017=1=0=4AM98Y
[3] http://www.hoteldeca.com/

-- 
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.

[racket-users] TFPIE 2017

[Marco Morazan]

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 only an abstract is required to 
be accepted for presentation. The full review process occurs post-workshop.

I hope to see you at TFPIE 2017.

Best wishes,

Marco


TFPIE 2017

Trends in Functional Programming in Education, 2017

https://www.cs.kent.ac.uk/people/staff/sjt/TFPIE2017/


The sixth workshop on Trends in Functional Programming in Education, 2017,
which is to be held on the Canterbury campus of the University of Kent on
Thursday, 22 June, following the 2017 TFP meeting on 19–21 June. TFPIE
workshops have previously been held in St Andrews, Scotland (2012), Provo
Utah, USA (2013), Soesterberg, The Netherlands (2014), and Sophia-Antipolis,
France (2015), College Park, USA (2016).

A particular topic of this year's TFPIE will be MOOCs and other online learning
and, as well as a session on this, we're delighed to announce that Heather 
Miller
of EFPL and Northeastern University will be giving a keynote on this topic.
Heather works on and around the Scala programming language and is Executive
Director of the Scala Center. We'll also have MOOC expertise from the OCaml MOOC
team, Jeremy Singer (Haskell), and Simon Thompson (Erlang).


The goal of TFPIE is to gather researchers, teachers and professionals that 
use, or
are interested in the use of, functional programming in education. TFPIE aims 
to be a
venue where novel ideas, classroom-tested ideas and work-in-progress on the use 
of
functional programming in education are discussed. The one-day workshop will 
foster a
spirit of open discussion by having a review process for publication after the
workshop. The program chair of TFPIE 2017 will screen submissions to ensure 
that all
presentations are within scope and are of interest to participants. After the
workshop, presenters will be invited to submit revised versions of their 
articles for
publication in the journal Electronic Proceedings in Theoretical Computer 
Science
(EPTCS).

Third call for papers

TFPIE 2017 welcomes submissions describing techniques used in the classroom, 
tools
used in and/or developed for the classroom and any creative use of functional
programming (FP) to aid education in or outside Computer Science. Topics of 
interest
include, but are not limited to:

 

- FP and beginning CS students
 
- FP and Computational Thinking
 
- FP and Artificial Intelligence
 
- FP in Robotics
 
- FP and Music
 
- Advanced FP for undergraduates
 
- FP in graduate education
 
- Engaging students in research using FP
 
- FP in Programming Languages
 
- FP in the high school curriculum
 
- FP as a stepping stone to other CS topics
 
- FP and Philosophy
 
- The pedagogy of teaching FP
 
- FP and e-learning: MOOCs, automated assessment etc.
 
- Best Lectures – more details below



In addition to papers, we are requesting best lecture presentations. What’s 
your best
lecture topic in an FP related course? Do you have a fun way to present FP 
concepts to
novices or perhaps an especially interesting presentation of a difficult topic? 
In either
case, please consider sharing it. Best lecture topics will be selected for 
presentation
based on a short abstract describing the lecture and its interest to TFPIE 
attendees.



Submission



Potential presenters are invited to submit an extended abstract (4-6 pages) or 
a draft
paper (up to 16 pages) in EPTCS style. The authors of accepted presentations 
will have
their preprints and their slides made available on the workshop's website. 

Papers and
abstracts can be submitted via easychair at the following link:
  https://easychair.org/conferences/?conf=tfpie2017

After the workshop
Presenters will be invited to submit (a revised version of) their article for 
review. The
PC will select the best articles for publication in the journal Electronic 
Proceedings in
Theoretical Computer Science (EPTCS). Articles rejected for presentation and 
extended
abstracts will not be formally reviewed by the PC.

Programme committee

Dr Laura Castro, University of A Coruña

Prof Ralf Lämmel, University of Koblenz-Landau

Dr Elena Machkasova, University of Minnesota, Morris

Prof Michel Mauny, Inria, Paris

Dr Jeremy Singer, University of Glasgow

Prof Simon Thompson, University of Kent (chair)



Important dates

Submissions of draft papers: 10 May, 2017

Notification: 17 May, 2017

Registration: 11 June, 2017
Workshop: 22 June 2017
Submission for formal review: 18 August, 2017
Notification of acceptance: 6 October, 2017
Camera ready paper: 3 November, 2017

-- 
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 

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Matthias Felleisen]

> 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 thinking for now.


Mike Sperber’s language (DieMachtDerAbstraktion) in the DrRacket menu comes 
with a contract system that does this. It checks recursive calls and memoizes 
so that your algorithm has a large constant degradation but is in the correct 
complexity class. The language itself is kind of like the teaching languages 
for HtDP so impoverished. 

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Matthias Felleisen]

> 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 
>> software and we’d be all better off if we did so. 
> 
> I agree that I always feel uneasy about turning off contracts. But sometimes 
> performance is a problem.
> 
> How would you therefore recommend checking the invariant that the recursive 
> function's output is a list of integers, then (as a simple example)?
> 
> 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.) 


> I'd consider this bad programming. It's not about small speed improvements, 
> it's about making an application unusable altogether

Absolutely. Which is why I assumed you had written an alternative to get the 
recursion checked. 


> 
> 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?]


> 
> In my current academic project (a typed variant of Nanopass), I'm using a 
> hybrid approach: types enforce "simple" invariants. More complex structural 
> invariants (acyclicity, well-scopedness, backward "parent" pointers in the 
> AST which indeed point to the correct parent, and so on) are checked at 
> run-time, since they cannot be expressed using Typed Racket's type system 
> alone. Once such an invariant is checked, a phantom type is used on the 
> value's type to indicate that the value was safely checked against a given 
> invariant.
> 
> This allows compile-time verification that a call to a transformation pass 
> gives a value which was properly checked, and also reduces the need for 
> performing the same checks against the AST too often (passing the same AST to 
> two or more analysis passes needs only one check).
> 
> I'm unaware of mechanisms which would allow annotating list elements or 
> syntax objects in Racket, which would allow solution 4 to work. If it was 
> possible to have chaperone contracts on pairs, it would be possible to wrap 
> the checked output values with a no-op "witness" chaperone, and check for the 
> presence of the chaperone. Alternatively, the contract system could maintain 
> a cache of recently-checked values (like equal? does) e.g. using a weak hash 
> table.
> 
> Of course, the best solution is to use types, but until Typed Racket becomes 
> versatile enough to write macro implementations, and until Typed Racket gains 
> dependent types, so that a wide range of expressive properties can be 
> encoded, what would you recommend?


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.) 

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Dupéron Georges]

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 always feel uneasy about turning off contracts. But sometimes 
performance is a problem.

How would you therefore recommend checking the invariant that the recursive 
function's output is a list of integers, then (as a simple example)?

1. (define/contract (foo input) (-> blah (listof integer?)) …)

  This has a O(n²) cost. I'd consider this bad programming. It's not about 
small speed improvements, it's about making an application unusable altogether 
(the SMS app on my phone has a O(n²) somewhere, with n the number of texts 
sent. After a few thousands, it takes 30s to send a text, so it is effectively 
unusable).

2. (provide (contract-out [foo (-> blah (listof integer?))])) + regular define

  This has a O(n) cost, but does not perform any check during recursive calls. 
If the function is a case-lambda with many cases (which happens often in one 
form or another in macro implementations), it's then hard to guess which case 
is the culprit. One then has to resort to printf-debugging and throw-away 
sanity checks inserted during the debugging session and removed afterwards.

3. (define/contract (foo input) (-> blah (or/c (cons/c integer? any/c) null?)) 
…)

  This has a O(n) cost, and checks recursive calls, but it relies on the fact 
that the implementation of foo prepends elements to the result one at a time. 
If the implementation is changed so that at one point is prepends two elements, 
the contract fails to properly check the result.

Ideally, there would be a way to attach to a value a witness that a given 
contract was checked against it:

4. (define/contract (foo input) (-> blah (listof integer?)) …)
  where the contract check stops when it encounters an already-checked value.

In my current academic project (a typed variant of Nanopass), I'm using a 
hybrid approach: types enforce "simple" invariants. More complex structural 
invariants (acyclicity, well-scopedness, backward "parent" pointers in the AST 
which indeed point to the correct parent, and so on) are checked at run-time, 
since they cannot be expressed using Typed Racket's type system alone. Once 
such an invariant is checked, a phantom type is used on the value's type to 
indicate that the value was safely checked against a given invariant.

This allows compile-time verification that a call to a transformation pass 
gives a value which was properly checked, and also reduces the need for 
performing the same checks against the AST too often (passing the same AST to 
two or more analysis passes needs only one check).

I'm unaware of mechanisms which would allow annotating list elements or syntax 
objects in Racket, which would allow solution 4 to work. If it was possible to 
have chaperone contracts on pairs, it would be possible to wrap the checked 
output values with a no-op "witness" chaperone, and check for the presence of 
the chaperone. Alternatively, the contract system could maintain a cache of 
recently-checked values (like equal? does) e.g. using a weak hash table.

Of course, the best solution is to use types, but until Typed Racket becomes 
versatile enough to write macro implementations, and until Typed Racket gains 
dependent types, so that a wide range of expressive properties can be encoded, 
what would you recommend?

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Matthias Felleisen]

> 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 reference. Would you 
> suggest that, in this spirit, types for functions are moved to the top of the 
> file with the provide forms, instead of being specified alongside each 
> function?

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Yes. There is a broken form of type-out that supports some of this already. I 
am hoping Sam will get to fixing this eventually. @samth 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 


> 
>>> On this topic, I have sometimes written recursive functions with expensive 
>>> contracts (when recursing down a list, a contract on the whole list will 
>>> have a total cost of O(n²)).
>> 
>> 2. I consider this a horrible idea and I made sure define/contract does not 
>> do so. If you feel that unsure about recursive functions, I recommend using 
>> types. They help you avoid typos at that level. 
> 
> I'm using types wherever possible. Unfortunately, TR does not (yet) mix well 
> with contracts (but I'm aware that there is a pending PR for this).


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Yes. I am hoping Sam will get to fixing and approving this eventually. @samth 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - 


> More importantly, Typed Racket cannot be used to write macro implementations, 
> for several reasons:


I guess I underestimated what kind of code you’re writing. Your concerns are 
real. 


> I'm genuinely unsure which aspect of this idea you find horrible?
> 
> * Is it because the contract is specified along the function, with 
> define/contract-out, instead of being written alongside the provide forms? If 
> so, separating the contract from the function definition, using a form 
> similar to TR's (: name type), would allow the contract to be specified next 
> to the provide form, but still have it applied to recursive function calls 
> during debugging.
> 
> * Is it because turning off the contract for recursive calls would lower the 
> safety (i.e. the swim vest analogy)? In my case, the contract on the result 
> was strong enough to catch the error anyway, and the goal was only to catch 
> incorrect results as soon as possible, instead of waiting until they cross 
> the module boundary and are returned to the original caller, so that it is 
> easier to locate the exact source of the error.
> 
> * Is it because of something else that I missed?
> 
> In conclusion, I do agree that types are a much better option, and I do use 
> them wherever possible. Unfortunately, there are some cases where types 
> cannot be used (yet), and in those cases I'd like to get as much help as I 
> can from contracts when debugging, without imposing a horrendous cost during 
> normal development (which does not mean tossing all safety aside, but rather 
> allow errors to be caught at module boundaries instead of detecting them 
> nearly immediately). These goals do not seem insane to me, and I'm 100% open 
> to suggestions on how to achieve this :) .


The cost and the false sense of security implied by a contract you ran on 
recursive calls and that you then turned off. 

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. 

— Matthias

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Dupéron Georges]

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 are moved to the top of the file with 
the provide forms, instead of being specified alongside each function?

> > On this topic, I have sometimes written recursive functions with expensive 
> > contracts (when recursing down a list, a contract on the whole list will 
> > have a total cost of O(n²)).
> 
> 2. I consider this a horrible idea and I made sure define/contract does not 
> do so. If you feel that unsure about recursive functions, I recommend using 
> types. They help you avoid typos at that level. 

I'm using types wherever possible. Unfortunately, TR does not (yet) mix well 
with contracts (but I'm aware that there is a pending PR for this). More 
importantly, Typed Racket cannot be used to write macro implementations, for 
several reasons:

* Lack of immutable values at the type level (this means that values with type 
Syntax can in principle contain mutable values, which break occurrence typing)

* syntax/parse (and possibly syntax/case) have not been ported to Typed Racket.

I did in the past a couple of experiments to use Typed Racket to implement 
macros, but the results were unsatisfactory. My best attempt so far, 
tr-immutable/typed-syntax (still unstable and undocumented) requires "unsafe" 
mutable syntax values to be converted to a "safe" representation, and converted 
back after executing the macro.

When writing complex compile-time transformations, I felt the need to check the 
input and output of every recursion step, to catch the exact point at which an 
error occurs.

I'm genuinely unsure which aspect of this idea you find horrible?

* Is it because the contract is specified along the function, with 
define/contract-out, instead of being written alongside the provide forms? If 
so, separating the contract from the function definition, using a form similar 
to TR's (: name type), would allow the contract to be specified next to the 
provide form, but still have it applied to recursive function calls during 
debugging.

* Is it because turning off the contract for recursive calls would lower the 
safety (i.e. the swim vest analogy)? In my case, the contract on the result was 
strong enough to catch the error anyway, and the goal was only to catch 
incorrect results as soon as possible, instead of waiting until they cross the 
module boundary and are returned to the original caller, so that it is easier 
to locate the exact source of the error.

* Is it because of something else that I missed?

In conclusion, I do agree that types are a much better option, and I do use 
them wherever possible. Unfortunately, there are some cases where types cannot 
be used (yet), and in those cases I'd like to get as much help as I can from 
contracts when debugging, without imposing a horrendous cost during normal 
development (which does not mean tossing all safety aside, but rather allow 
errors to be caught at module boundaries instead of detecting them nearly 
immediately). These goals do not seem insane to me, and I'm 100% open to 
suggestions on how to achieve this :) .

-- 
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.

Re: [racket-users] Apropos contracts: simple predicates and switching on and off

[Matthias Felleisen]

> 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 at the top of the 
>> file.
> 
> Since provide transformers are executed in two passes (the second one being 
> after the expansion of the rest of the file, IIRC), I thought about writing 
> define/contract-out so that it saves the contract, but does not implicitly 
> provide the identifier.


See 
https://docs.racket-lang.org/style/Units_of_Code.html#%28part._.Modules_and_their_.Interfaces%29


[[ In a world where the IDE teases out all possible provides and can show a 
beautifully formatted interface for a module, we might not want to follow 
linguistics. ]] 



> On this topic, I have sometimes written recursive functions with expensive 
> contracts (when recursing down a list, a contract on the whole list will have 
> a total cost of O(n²)).


1. It’s “recurring” not “recursing”. The latter means curse and curse and curse 
and curse . . . 

2. I consider this a horrible idea and I made sure define/contract does not do 
so. If you feel that unsure about recursive functions, I recommend using types. 
They help you avoid typos at that level. 

— Matthias



-- 
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.