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! _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
