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

On Oct  4, YC wrote:
> So is the requirement to read a list of symbols from a config file
> and use them as the mapping to the underlying modules?

No, there are no requirements -- any scheme code that you want to use.


> Correct me if I am wrong, but doesn't planet already solve this
> problem?

Not at all.

[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.]


> 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.


> The changes to files are localized within the package, and if you
> have a main.ss that require and provide the underlying modules, it
> acts as the config.ss for other modules requiring the package.
> [...]

The "main.ss" file is (by convention) an entry point for code
*outside* of a collection -- that is, it would normally require most
of the code in the collection -- whereas a configuration file is
something that most code in the collection would require.


> And cce/system/planet appears to solve the self referencing problem
> within a single package -
> http://blog.plt-scheme.org/2009/03/maintaining-self-references-in-planet.html

I asked Carl about this last week, trying to see if there's any
intersection -- my guess was that it would make his package easier to
write, but it looks even that won't happen.  His package is more about
deriving a `planet' *symbolic* form for the root of the package (which
can be used as above in some cases) -- which is needed in some cases.
For example, look for the problematic cases in his blog post: they
refer to situations where the require spec is moving outside of
`require' to some other part of the system, as the case with
specifying a language level for drscheme where you need to pass a
require-spec that will refer to your code.  Perhaps a clearer example
is `defmodule' -- it won't work to do something like

  (defmodule "../foo.ss")

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.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!