[plt-dev] #lang: the stake in Dracula's heart?

From: Carl Eastlund (cce at ccs.neu.edu)
Date: Mon Feb 1 16:29:04 EST 2010

On Mon, Feb 1, 2010 at 4:18 PM, Eli Barzilay <eli at barzilay.org> wrote:
> On Feb  1, Carl Eastlund wrote:
>> On Mon, Feb 1, 2010 at 1:02 PM, Matthew Flatt <mflatt at 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


Posted on the dev mailing list.