I'm not sure that extension registration is different than collection
installation. For example, the meaning of '#lang foo' depends on the
'foo' that you have installed.
But ensuring that it's the same would require picking some extesions
to mean "PLT module". We couldn't keep the current behavior of
allowing any extension.
On Feb 1, 2010, at 3:26 PM, Eli Barzilay <e...@barzilay.org> wrote:
On Feb 1, Carl Eastlund wrote:
On Mon, Feb 1, 2010 at 5:02 PM, Eli Barzilay <e...@barzilay.org>
wrote:
DrScheme can be made to pretend (relatively easily, I think) that
some "#lang"-less buffer really has the right "#lang indirect
STDIN r6rs" contents, or something like that. In any case, I
don't consider it important to think about drscheme-specific
problems -- I believe that finding a good solution at the mzscheme
level is bound to lead to a drscheme solution.
If mzscheme recognized something like DrScheme tools -- more
lightweight and GUI-free, but still a form of library registry --
registering file extensions should be easy.
One of the main things that I dislike with extension registration is
that it means that running mzscheme on a file makes it do much more
work, in this case -- digging through all info files (reading
"collects/info-domain/compiled/cache.ss") for the registration. This
is in addition to the (bad) result of making the semantics of files
depend on my specific environment. (For example, this is one of the
bad aspects of having teachpacks specified outside of the file.)
--
((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
