Just now, Robby Findler wrote:
> In DrR, it isn't looking at the log that tells you this, you get a
> special bar appearing in the window. You don't have to do any extra
> clicks or anything like that.
(Yeah, take that as a generalized version of my "see the log"...)
> That said, I don't mind if, when someone runs some planet2 code in
> racket, outside drracket, that it raises an error saying "you need
> to pass the --slow-me-down-but-automatically-download-missing-
> packages flag, or just run this program in drracket".
WRT the automatic download + install -- while it's obviously possible
to do that, I think that because of such things it's generally bad to
actually make "real code" depend on it.
Here's what I mean: if you assume that there should always be some
visible indication of a package being installed, there is not going to
be some magical require that would always work silently, and that can
interfere with actually running the code. For example, you do some
(require (download-and-install-from-somewhere))
and it might produce some output or it might not -- and the code that
uses this might break if there's unexpected output.
But such a functionality is obviously useful -- so how about including
it only for interactive purposes, which means that you can use it in
your blogged code since you know that the extra output is not
interfering with your code. If OTOH you post some script for people
to run, then you don't use that and instead tell people that they
should install the other needed package, and later just pack your own
code as a package.
----
This might lead to an interesting direction. Since it's not boring,
it might not be a good idea, but still I think that it looks
promising...
Imagine that there was some meta syntax for required packages (I'll
use emacs-like hackish-isms):
#lang racket
;; *** Requires: some-package ***
... code ...
This idea can be taken further to add more package-like features,
eventually like
#lang racket
;; *** Package: name-for-this-code-as-a-package ***
;; *** Requires: some-package ***
... code ...
which can eventually make it possible to treat a single file as a
package.
The nice thing that should be obvious now is that there's no need for
such hacks, since that require line is serving the same purpose.
Except that to really make it possible to do this effectively, you
need to be able to know the package information separately for the
code -- and submodules look like a perfect way to do that. Just
replace the hacks with something like:
#lang racket
(module pkg planet/pinfo ; for "package info" or whatever
(define package name-for-this-code-as-a-package)
(requires some-package)
(requires some-other-package and-another))
... code ...
Or drop the define for the shorter case. And since this is still
pretty verbose, it might be abstracted away in some macro. (But I
don't remember the dependency issues with such things, so it might not
be doable as is.)
I think that with something like that you can get everything that you
want. A plain run in drr can do the same thing when it sees that
there's a package inforation. Toplevel requires in the racket input
can do the same, but just requiring this file from another will not do
it which means that you can also use it this way without worrying
about interfering with real runs. And you can also have some new
command like "raco pkg install-whatever-is-needed-for some-file.rkt"
which would be like doing the toplevel require thing.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________
Racket Developers list:
http://lists.racket-lang.org/dev
