[racket] Exploratory programming?

Although I've grown accustomed to it, early on I disliked the
redundancy of define/contract and (my own macro)
define/contract/provide.

(define/contract (foo x #:y y)
  (int? #:y boolean?)
  ( ... body ... ))

Coming from typed languages, I really wanted to state the args and the
"types" together as one list not two.

If that were possible, it would also make possible "show me the blue box".

Of course, I've also learned how expensive contracts could be. So I
sometimes have code where the contract got, not deleted, but commented
out with #| |# because I still wanted the documentation value.  And it
would be helpful if such functions could "get blue boxes", too.

Likewise, there have been times when I've wanted contracts active for
dev/dbg purposes, but don't want them for release/production, and
wished there could be a build or runtime switch (as opposed to
commenting out code).

I wonder if someone smarter than me could pull this all together into
a neat syntax and system?
- Merge function definitions and contracts into one thing, with a new
variation of define/contract and define/contract/provide.
- Let contracts be made inactive for performance, but remain in the
code. Ideally can disable per-function as well as more globally like
per-module?
- Allow contracts' doc value to be not simply their visibility in the
source file, but also their visibility in a help system (which again
can use the contracts whether live or disabled) that shows us the
"blue boxes".


On Wed, Dec 1, 2010 at 11:12 PM, Ryan Culpepper <ryanc at ccs.neu.edu> wrote:
> My $0.02: Most of the time when I hit the docs for a function, all of the
> information I need is in the blue box: usually I'm looking at the contracts,
> but the argument labels help me when I forget the order things go in. I'd be
> happy with a tool that showed just the contents of the blue boxes, formatted
> as text.
>
> At the repl, (blue-box id)---names changed to protect the
> unimplemented---should print out the header and contract information
> associated with id. Perhaps (blue-box "id") should print out the blue-box
> information and require line for everything matching "id" exactly. And other
> search options as needed.
>
> In DrRacket, there should be a way of getting the same information in an
> on-demand panel (like the find/replace panel or error-during-check-syntax
> panel). It must be available without running Check Syntax, however, through
> some combination of search, caching, heuristics, and mind-reading.
>
> It would be great if it were also available in emacs/quack etc.
>
> Ryan
>
>
> Eli Barzilay wrote:
>>
>> Two hours ago, Greg Hendershott wrote:
>>>>
>>>> I wonder whether help could display contracts if the module use
>>>> provide/contract to export f.
>>>
>>> I like this idea.
>>
>> I don't think that combining all of these is right.  To go over the
>> various pieces there are three that are very different:
>>
>> 1. (help id) -- opens a browser window on the documentation for `id'
>>
>> 2. there's the description of which module some identifier is coming
>>   from, where was it defined, and what name was it defined as (some
>>   of it is what check-syntax shows, and also what my interactive
>>   ,describe command does)
>>
>> 3. and there's the description of a value
>>
>> The first is very different from the other two -- I often want to see
>> #2 but don't want a browser window, or if I want to look at the docs
>> then I don't need #2.  So lumping them together doesn't sound right.
>>
>> So it might make a little more sense to bundle all of the light-weight
>> quick output features, like #2 and #3, but they're very different from
>> each other -- #2 is syntactic and #3 uses the value.  So merging them
>> into a single facility can be confusing.
>>
>> [Re python, my guess was that it's more limited in having no
>> syntactic-level tool -- and I do see that things like help(+) or
>> help(if) don't work.  And BTW, after only a few experiments, python's
>> `help' looks like a mess: help(3) is the same as help(int), help("3")
>> does some search, etc etc.  Hardly looks like a good tool to
>> imitate...]
>>
>>
>>> Maybe go a step further and allow per-parameter doc-string-ettes?
>>> Because seeing
>>>
>>>  get-pure-port: (url? (listof string?) . -> . input-port?)
>>>
>>> Might still be too opaque. "What is this (listof string?) you speak
>>> of?", sayeth the aspiring Racketeer on the PLimoTh PLanTation.
>>>
>>> Whereas if contracts could have optional doc-string-ettes:
>>>
>>>  (url? ["URL"] (listof string?) ["headers"] . -> . input-port?)
>>>
>>> Then help could display something very close indeed to the shaded
>>> blue box summary on docs.racket.org.
>>
>> Ideally, the documentation could be rendered in some way that could be
>> displayed in text, but that will take some work.  And that's still
>> different from a simpler doc-string thing.
>>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>