[racket] Evaluating code written in non-SEXP language

 I think, you may simply add #lang into input-port when reading the file.


Среда, 11 сентября 2013, 12:08 -05:00 от Robby Findler <robby at eecs.northwestern.edu>:
>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  < dpavlov at 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
>>>
>>>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 < dpavlov at 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
>>>
>>>
>>
>>____________________
>> Racket Users list:
>>  http://lists.racket-lang.org/ users
>
>____________________
>  Racket Users list:
>   http://lists.racket-lang.org/users
>


-- 
Roman Klochkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130911/a0640cdd/attachment-0001.html>