On Mon, Feb 1, 2010 at 4:18 PM, Eli Barzilay <e...@barzilay.org> wrote: > On Feb 1, Carl Eastlund wrote: >> On Mon, Feb 1, 2010 at 1:02 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote: >> >> > Finally, I'm not sure how a file extension would get mapped to >> > "planet cce/acl2". But maybe all of that could be worked out. >> >> Presumably the same way `#reader(planet "reader.ss" ("cce" >> "dracula.plt" 8 0) "modular" "lang")' gets translated to the >> "Modular ACL2" language level currently. The language level tool >> must register itself and its identifying metadata. > > That's something that exists only in DrScheme now. Moving it to a > higher level seems dangerous to me, since it means that the meaning of > files depends on stuff in my own preference file. Using "lisp" as the > ACL2 extension is good example for that -- since it'll get in the way > of a different lisp language implementation. If there is such a > language, how would I be able to use both?
Tool registration is stored with each collection or planet package, not in a preference file. As for using two ".lisp" language levels, well, automatic detection just wouldn't work. You'd have to manually switch each time you opened a file in whichever one wasn't the current default. There's no real way around this. > Another bad option that I mentioned in the past is to do what emacs is > doing -- define some magic that can appear anywhere on the line. With > Emacs, you can write > > <anything> -*- scheme -*- <anything> > > But this seems fine only with the heuristic-based stuff that Emacs is > doing (which in most cases doesn't affect the semantics since it's > "just" an editor...). This also only works when you have control over your source code. Importing existing files from a different compiler doesn't allow this. > One concrete suggestion that would be easy to work with now is > something like (using r6rs as an example): > > #lang indirect "foo.scm" r6rs > > which would make the reader parse "foo.scm" using the r6rs syntax. > To make it a little more convenient to use, DrScheme could have some > special treatment of such a language -- like presenting you with a > buffer that has > > #lang r6rs > ...the contents of "foo.scm"... > > with a different color for the #lang line or something like that. > This is still inconvnient in the sense that it requires an actual file > to work, but there's probably some way to go around this, like > > #lang indirect STDIN r6rs > > or something. It sounds like the above solves the problem of "what do you run when you open a non-#lang file" by declaring that you can't, you must always open a #lang file. Meaning a user trying to run a set of ACL2 libraries could only run them in DrScheme by creating a "#lang indirect" file for each one they wanted to try. > Using something like that I can imagine extending mzscheme with a > command line flag for the module to run. Something like: > > mzscheme --program '#lang scheme (+ 1 2)' > > might work nicely -- and assuming that, you can finally do > > mzscheme --program '#lang indirect "file.scm" r6rs' file.scm > > which could then be sugared into some > > mzscheme --program-language r6rs file.scm Or, if we have non-#lang language levels, how about: mzscheme --language-level acl2 "file.lisp" --Carl, attempting to eval his cake and compile it too _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev