[racket] Best Way to Really Understand the Compilation and Execution Model?

From: Nick Sivo (nicksivo at gmail.com)
Date: Mon Aug 5 13:29:29 EDT 2013

This is the approach I took at first.  But as things built on each
other I needed definitions at deeper and deeper syntax phases.

It might be possible to track definitions and introduce them
dynamically at deeper syntax levels automatically as required, but I'd
like to reserve that for my last attempt at the problem.  In fact, I
think the submodule approach explored by Jens would do this
automatically because each submodule requires its dependencies, so you
automatically get the whole chain.

I'll definitely report back if I get things working with the solution
I chose and why.

Thanks,
Nick

On Mon, Aug 5, 2013 at 10:12 AM, Vincent St-Amour <stamourv at ccs.neu.edu> wrote:
> For that, you could have Arc's `define' expand into both a Racket
> `define' and a `define-for-syntax', which I believe is what Jens was
> suggesting. You may want to do something similar for `require', too.
>
> Vincent
>
>
>
> At Mon, 5 Aug 2013 10:06:36 -0700,
> Nick Sivo wrote:
>>
>> I'm aware of defmacro and even understand its implementation (cute
>> trick!), but I need to eventually get something like this to work:
>>
>> (require compatibility/defmacro)
>>
>> (define (my-cdr lst)
>>   (cdr lst))
>>
>> (defmacro drop-first-form args
>>   `(begin ,@(my-cdr args)))
>>
>> (drop-first-form
>>  (displayln 1)
>>  (displayln 2))
>>
>> Where the above just works and displays 2.
>>
>> I'll check out the latest research papers too.
>>
>> Thanks,
>> Nick
>>
>> On Mon, Aug 5, 2013 at 1:40 AM, Noel Welsh <noelwelsh at gmail.com> wrote:
>> > Does defmacro do what you want?
>> >
>> > http://docs.racket-lang.org/compatibility/defmacro.html?q=defmacro#%28form._%28%28lib._compatibility%2Fdefmacro..rkt%29._defmacro%29%29
>> >
>> > In terms of grokking the macro system you probably want to read some of the
>> > research papers, which you can find from links here:
>> >
>> > http://racket-lang.org/people.html
>> >
>> > Racket's macro system is really cutting edge, so it doesn't have a large
>> > body of text explaining it.
>> >
>> > HTH,
>> > N.
>> >
>> >
>> >
>> > On Sun, Aug 4, 2013 at 9:50 PM, Nick Sivo <nicksivo at gmail.com> wrote:
>> >>
>> >> Hello everyone,
>> >>
>> >> I work on Hacker News[1], which is written in Arc[2], and am tasked
>> >> with making it faster.  The Arc compiler targets Racket[3], but
>> >> doesn't do so in such a way that function names or source locations
>> >> are preserved.  This makes output from the sampling profiler and error
>> >> messages mostly useless.
>> >>
>> >> I'd like to make Arc work as a Racket language (and in the process
>> >> preserve srclocs and names), and have made some progress[4].  However,
>> >> I'm hitting a wall trying to implement Arc's macros.  Specifically, I
>> >> need to find a way for the macros themselves to use previously defined
>> >> Arc functions as part of their processing. I understand that there are
>> >> good reasons for Racket's hygiene and syntax phases, but I'm
>> >> implementing an existing language that has its own strong opinions.
>> >> I'm almost certain that accomplishing my goal is possible with the
>> >> right understanding, but despite reading much of the Racket Reference,
>> >> I don't truly get it yet.
>> >>
>> >> With that motivation in mind, what's the best way for me to become
>> >> intimately familiar with Racket's runtime, execution and compilation
>> >> model? Should I read through and make sure I understand the debugger?
>> >> The macro stepper?  Is there any kind of guide to Racket Internals?
>> >>
>> >> Thanks for any advice.
>> >>
>> >> Best,
>> >> Nick
>> >>
>> >> [1] https://news.ycombinator.com
>> >> [2] http://arclanguage.org
>> >> [3] Well, really mzscheme
>> >> [4] https://github.com/kogir/rark
>> >> ____________________
>> >>   Racket Users list:
>> >>   http://lists.racket-lang.org/users
>> >
>> >
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users

Posted on the users mailing list.