Similar mode here.
My "list of things to improve my programming by programming"
goes into a project folder called Lib/ . When I don't have
time, I write down a design and GTD. When I have breathing
space, I return and invest time in the 'todo' list. It almost
always pays off soon after I invest
Thank you for the "de-clutter" strategies. I realized I could do
something of this sort. One of the things I love the most about Racket
is the ability to do this. On the other hand sometimes that capability
can be distracting for me.
For example lately I've wanted to focus more on programming in R
>
> One way to avoid this problem is instead of module+ use module*:
>
> (module* test racket ;; To test module-boundary contracts, must use
>;; module* and (require (submod "..")).
> (require (submod ".."))
> ... check check check ...
> )
Yup! A similar que
1. Clutter removal is built into Racket:
(define-syntax (interface stx)
(syntax-case stx (subject-to)
[(interface name clauses ...)
;; ==>
.. (provide (contract-out ..) ..) ..]))
The above macro has become a standard in my recent projects where I place it
into my ./Lib/contrac
Not to flog this, but:
Lately I've been trying to be a good little doobie and use `(provide
(contract-out))` instead of `define/contract`. Although it's more
typing/clutter, grumble grumble, I've been getting used to it.
Unfortunately I discovered one gotcha: Using (module+ test ) means that the
I have added a note on this issue to the Style issue; see section 3.6. Strictly
speaking, this prose probably belongs into the Contract guide. -- Matthias
On Nov 30, 2012, at 5:17 PM, Ryan Culpepper wrote:
> You can have mutually recursive functions with define/contract, but you can't
> with
You can have mutually recursive functions with define/contract, but you
can't with submodules.
Ryan
On 11/30/2012 05:04 PM, Ray Racine wrote:
Why not make this explicit by deprecating define/contract and support
this use case with a submodule. They lightweight enough and makes
boundary demarc
Why not make this explicit by deprecating define/contract and support this
use case with a submodule. They lightweight enough and makes boundary
demarcations consistent, explicit and simple. Module -> boundary.
On Nov 30, 2012 12:05 PM, "Matthias Felleisen" wrote:
>
> On Nov 30, 2012, at 10:15
One thing I would find very useful is a blog post giving an overview
of where its more appropriate to use Racket without using contracts,or
Racket using contracts or Typed Racket. Also an overview of the speed
issues would be very useful.. For example I know there is a cost to
contracts, but I'm
On Nov 30, 2012, at 10:15 AM, Greg Hendershott wrote:
>> This is a complete misunderstanding.
>
> Sometimes I feel like a kid in the room while the adults are talking.
> When it comes to contracts, I have to stipulate that most of you are
> smarter than me and have thought about this longer than
I think that we can do better in this case. The -> contract combinator
can be specialized when it sees that there really is a function with
the right type and it actually sees the function itself to insert the
checks into.
But I should point out that benchmarking programs like this one can be
very
> This is a complete misunderstanding.
Sometimes I feel like a kid in the room while the adults are talking.
When it comes to contracts, I have to stipulate that most of you are
smarter than me and have thought about this longer than me.
Having stipulated that, it seems unfortunate and surprising
On Fri, Nov 30, 2012 at 9:33 AM, Matthias Felleisen
wrote:
>
> On Nov 29, 2012, at 11:47 PM, Harry Spier wrote:
>
>> And then to enable/disable contracts you can use the method Mathias
>> pointed out here.
>> http://www.mail-archive.com/users@racket-lang.org/msg12281.html
>
>
> Thanks for remindi
On Nov 29, 2012, at 10:29 PM, Greg Hendershott wrote:
> AFIK these subtleties of contracts and modules arise with
> `provide/contract' -- by saying that the function should only use a
> contract outside the module (or submodule).
>
> But I prefer to use `define/contract'. For one thing, I think
The main value of putting contracts on modules is, in my opinion, that
you can pinpoint blame. So when I fire up DrRacket and click in some
strange way and get a contract violation, it helps me pinpoint which
module. I don't generally need to pinpoint things at the definition
level inside a module
Oh, of course. Sorry for the confusion.
Robby
On Thu, Nov 29, 2012 at 8:56 PM, Matthew Flatt wrote:
> I don't see a bug.
>
> The body of a `module+' module sees all of the bindings of its
> enclosing module, unless those bindings are shadowed.
> For example,
>
> #lang racket
> (define x 5)
>
AFIK these subtleties of contracts and modules arise with
`provide/contract' -- by saying that the function should only use a
contract outside the module (or submodule).
But I prefer to use `define/contract'. For one thing, I think it's
easier and more-maintainable to group the contract near/with
I don't see a bug.
The body of a `module+' module sees all of the bindings of its
enclosing module, unless those bindings are shadowed.
For example,
#lang racket
(define x 5)
(module+ main
x)
would print 5 (even though `x' is not exported), but
#lang racket
(define x 5)
(module+ main
Thanks Robby,
Do I need to submit a bug report.
Harry
On Thu, Nov 29, 2012 at 8:32 PM, Robby Findler
wrote:
> That looks like a bug to me.
>
> Robby
>
> On Thu, Nov 29, 2012 at 6:59 PM, Harry Spier
> wrote:
>> Dear list members,
>>
>> Case 1 below doesn't give a contract violation but case 2 d
That looks like a bug to me.
Robby
On Thu, Nov 29, 2012 at 6:59 PM, Harry Spier wrote:
> Dear list members,
>
> Case 1 below doesn't give a contract violation but case 2 does. Is
> this desired behavour or is it a bug?
>
> In DrRacket
> Case 1
> -
> #lang racket
> (provide (contract-out
20 matches
Mail list logo
