On Mon, Feb 1, 2010 at 5:02 PM, Eli Barzilay <e...@barzilay.org> wrote: > On Feb 1, Carl Eastlund wrote: >> >> Tool registration is stored with each collection or planet package, >> not in a preference file. > > (Same point applies.)
There is no way around the fact that without Dracula installed, ACL2 files have no meaning to DrScheme. >> 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. > > I think that it's generally healthier to think about it in terms of > running some file through mzscheme. There's no drscheme around to ask > you what you mean. So in place of "manually switch", think "supply a command-line argument". >> > 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. > > 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. >> > 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" > > I think that you're missing the point. What I was suggesting in all > of the above is that (translating back to acl2): > > mzscheme --program-language acl2 file.lisp > > becomes shorthand for > > mzscheme --program '#lang indirect "file.lisp" acl2' file.lisp > > which makes mzscheme run AS IF it was requiring a file with this > contents: > > #lang indirect "file.lisp" acl2 > > (only as if -- no actual file), and finally that will read from > "file.lisp" using the acl2 language reader. > > So -- no "#lang" needed in the file; the language specification is > completely done with a flag. Aha, I see. That works. --Carl _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
