[plt-dev] New forms for requiring files -- poll for opinions and names

Thanks Eli - I think I have have better understanding of the issue now...
see below.

On Sun, Oct 4, 2009 at 10:40 AM, Eli Barzilay <eli at barzilay.org> wrote:

>
> [The only thing that is vaguely close to the same area is that planet
> adds the concept of a `package' (which is, IIUC, what Carl's tool uses
> to come up with a symbolic name) -- so you could think of an
> alternative form to require code from the current package's root, but
> this would hard-wire a "package == project" concept, and it still
> won't apply to code that is outside of planet packages.]
>

Agreed - project might or might not equal packages.


>  > It helps define packages which are referred via symbols.
>
> The symbolic way to reference them is not related here -- what would
> be is some form like I mentioned above, which can work relatively to
> the current package's root.
>

When the packages are small, the relative paths are isolated within the
package, so potential changes are small and less disruptive.  That's why I
mentioned it (and main.ss).  I found that having a big project, like having
a big module or a big procedure, is simply harder to manage without
intermediate abstractions.

because that relative string is not a universal reference to that
> specific file.  Carl's package solves that by coming up with a
> symbolic name that would always refer to that file, and it does so
> using a `planet' symbolic name (which is exactly why it's limited to
> planet packges).  You could imagine a similar tool (or an extension of
> Carl's tool) that works for installed collections too, but you'd still
> be left with random code in your filesystem that is in neither --
> since in that case there is no symbolic way to refer to the file
> without specifying its full path.
>

When I first start writing large programs in PLT I was directed to make use
the planet system for organization.  It definitely take me a while to figure
out how to make it work, but so far things mostly work well.

That being said, having the ability to handle projects similar to other IDEs
such as Visual Studio or XCode makes sense for PLT.  I would love to be able
to open all files for a project at once.

The trouble with config file is of course you would have to keep it in
sync.  That's easier with DrScheme than with emacs/mzscheme since you can
make DrScheme to maintain it automatically (like Visual Studio, XCode, etc),
but I agree maintaining it in one spot is easier than having to modify
relative paths all over the modules unless the developer has already taken
the care to organize the modules. Anyhow, I digress.

Going back to your question - how does the following look to you?

;; load the config file, which provides a list of symbols to the file path
mappings that you can explicitly require (and implicitly requires all if you
provide no symbols)
(require (*config-in "config.ss"* my-module-foo my-module-bar ...))

And it seems that having the ability to reset the
current-load-relative-directory would be useful too if you do not want to
maintain a config file but would like to have uniform relative paths against
a base directory.

;; reset the base-directory to the parent directory, and then load the rest
of the files relative to the new base directory.
(require (*base-in ".."* "my/module/foo.ss" "my/module/bar.ss" ...))

My 2 cents.  Cheers.
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091004/499257a9/attachment.html>