Generally speaking, Racket is set up to work well with the #lang lines, but not as well without. Lots of things get easier if they are there.
Robby On Wed, Sep 11, 2013 at 11:57 AM, Dmitry Pavlov <dpav...@ipa.nw.ru> wrote: > Hi Joe, > > Thank you. Actually my goal is to run files that do > not contain the #lang declaration--only pure non-Racket > non-sexp code. Is there a way to (dynamic-require) > a module with an externally preset language? I do not know. > > I tried your approach anyway. It works well itself, > but I have failed (as with all the other approaches) > to make a standalone executable from my "interpreter" > program. I wonder if anybody tried that with programs > of this kind. > > Best regards, > > Dmitry > > > > > > On 09/11/2013 05:46 PM, Joe Gibbs Politz wrote: > >> Hi Dmitry, >> >> I've been using `dynamic-require` for Pyret, a non-SEXP based >> language. For example, here's part of our command-line interface: >> >> https://github.com/brownplt/**pyret-lang/blob/master/src/** >> cmdline.rkt#L116<https://github.com/brownplt/pyret-lang/blob/master/src/cmdline.rkt#L116> >> >> You can ignore the parameterization under `check-mode`, which is Pyret >> specific. The point is that `pyret-file` is a filename handed in as a >> command-line argument, and we load the module via `dynamic-require`. >> `dynamic-require` does the work of using the reader/environment >> specified for the #lang declared in the file, and gets things like >> relative module imports right, too (at least I haven't been able to do >> anything too unexpected). >> >> This should work for any language that you want to build a >> file-accepting interface for, not just non-sexp ones. I'm not sure if >> this is the preferred style or not; if it's not, Pyret should probably >> use whatever better method there is as well. >> >> Cheers, >> Joe P >> >> >> >> On Tue, Sep 10, 2013 at 11:14 AM, Dmitry Pavlov <dpav...@ipa.nw.ru> >> wrote: >> >>> Hello, >>> >>> I have developed a non-SEXP DSL called SLON, and it works >>> great in DrRacket via "#lang slon" declaration. >>> >>> I have properly set up a lexer, a parser which returns datum >>> or syntax objects, slon/lang/reader.rkt, >>> slon/lang/lang-into.rkt, slon/lang/confugure-runtime.**rkt >>> and all the other stuff. >>> >>> Now I need it to work as a stand-alone interpreter >>> which runs files specified by user (outside of DrRacket). >>> How do I do that? The only thing I was able to come up >>> with is using make-evaluator for racket/sandbox: >>> >>> (require slon/slon-parser >>> racket/sandbox) >>> >>> (call-with-input-file* >>> "myprogram.slon" >>> (lambda (port) >>> (parameterize ((sandbox-input (current-input-port)) >>> (sandbox-output (current-output-port))) >>> (call-with-trusted-sandbox-**configuration >>> (lambda () >>> ((make-evaluator 'slon/slon-language >>> #:allow-read '("/")) >>> (slon-read port)))))))) >>> >>> Is it the correct way to create a stand-alone interpreter? >>> Because I do not really need a "sandbox" of any kind, >>> and also I was forced to specify #:allow-read '("/") >>> because the SLON programs do read arbitrary files. >>> >>> Also I am having a lot of trouble in making that >>> a stand-alone executable; but I will postpone >>> discussing it because I am not sure whether >>> I chose the right way to do the whole thing. >>> >>> >>> Best regards, >>> >>> Dmitry >>> ____________________ >>> Racket Users list: >>> http://lists.racket-lang.org/**users<http://lists.racket-lang.org/users> >>> >> >> >> > ____________________ > Racket Users list: > http://lists.racket-lang.org/**users <http://lists.racket-lang.org/users> >
____________________ Racket Users list: http://lists.racket-lang.org/users
