[racket] Evaluating code written in non-SEXP language

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<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<http://lists.racket-lang.org/users>
>>>
>>
>>
>>
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/**users <http://lists.racket-lang.org/users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130911/791b41e0/attachment.html>