[racket] Exploratory programming?

Maybe I don't grasp all the implications of your question, and I don't know
what is top-down and bottom-up documentation,
but from DrRacket , if you press F1 on a procedure/form/etc., you get to the
web based pre-filled search box, which gives you a number of hits.
Each hit gives you the module in which the name is declared, and if you
click on that module name, you get the reference about the whole module, so
you can indeed look at similar functions defined in that module.
This search box also has useful tools such as removing a given module from
the current search (when right-clicking on it IIRC).

I, too, would sometimes prefer a "help" function that does not need to
launch a web page and could also be used in a command-line only program, but
I must admit the web help is very convenient and particularly well thought.

As for the psychological effort to temporarily escape from your current
editor, maybe one day DrRacket will embed a sufficiently complete Web
browser (using Webkit?) to display the Help Desk directly inside DrRacket?

Laurent

On Tue, Nov 30, 2010 at 17:55, Richard Lawrence <
richard.lawrence at berkeley.edu> wrote:

> Dear Racketeers:
>
> Apologies in advance for what will probably be a long-winded newbie
> question.  I'm wondering how one goes about "exploring" the Racket
> libraries.  That is, how does one find out things like:
>
> 1. which modules are likely to contain functions useful for a particular
> task
> 2. what names a given module exports
> 3. more information about the objects exported by a module: e.g.,
> brief descriptions, their types, what methods they respond to, ...
>
> Here's some background. Most of the programming I have done is in
> Python. One of my favorite features in Python is that
>
>  >>> help(X)
>
> gives useful information for just about any object X. This is great for
> exploring modules, learning about the methods and member variables of
> classes, and finding out what functions do; it's an important
> "bottom-up" tool for exploring the language and libraries. In Python, I
> can often think, "I need something similar to, but not quite the same
> as, X; X is defined in module M; so let's do help(M) to see if M has the
> function I want." Often, I can tell at a glance over the docstrings that
> the thing I need -- or something related to it -- is there.  (This kind
> of "bottom-up" exploration is complemented by the documentation for the
> Python standard library, which provides a nice "top-down" reference.)
>
> I know that REPL-based interaction is de-emphasized in Racket.  Does
> that mean that the kind of "bottom-up" exploration of the language that
> I'm describing is de-emphasized as well?  Should the documentation be
> the first (only?) place I go to learn about modules and their contents?
> If so, what's the best way to access and search the documentation while
> programming?
>
> Please understand that I'm not ragging on Racket's documentation here;
> the documentation is truly excellent.  I guess one way of asking my
> question might be this.  I tend to think of the documentation as
> something I must sit down and read for a while, partly because the
> examples are often extended and build on each other, and partly because
> of the psychology of jumping out of Emacs into a browser.[1] Is there a
> different way of using and thinking about them?  In particular, is there
> a way of using them that corresponds to the uses of help() in Python?
>
> Thanks for your thoughts!
>
> Best,
> Richard
>
>
> [1] I have so far mostly stayed away from DrRacket, because I know Emacs
> well and haven't felt the desire or need so far to learn another
> environment.  Is that my problem?  Does DrRacket support the kind of
> bottom-up exploration in the documentation that I'm trying to describe?
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20101130/6cd80d89/attachment.html>