[racket] variables within macros

Tim, I wholeheartedly agree. Scheme used to be plainly beautiful. Understand 
lambda expressions, recursion and continuations, and everything else more or 
less falls into place.

The Scheme part of Racket still is as cool, but the rest is a moloch. Just 
syntactically understanding a Racket application requires deep digging into 
the guts; when I first picked up Racket after a long absence of Scheme, I 
just couldn't make heads or tails of all the #s, :s, ,s and and %s spread 
all over the place (and I still need to look those up frequently when I 
don't deal with something for a week or more). The macro system is even 
worse for the reasons you describe. Nothing simple, beautiful or orthogonal 
anymore. What a shame. Then take modules, phases and all the other bells and 
whistles (some of which are actually useful, but most appear to be of 
interest more to theoreticians than people involved in solving real 
problems) and you end up with something that takes much more time to get the 
tools to work right before you even get something relatively straightforward 
accomplished with them.

It used to be the case that you could reduce a Scheme system to a very few 
primitives and build the rest around it using syntactic extensions. That may 
still be true in Racket, but dealing with the syntactic extensions 
themselves requires learning a complete new and several times more complexe 
language. Bummer. I just don't see how one would attract newcomers to Racket 
when all the beauty is so obfuscated.

----- Original Message ----- 
From: "Tim Brown" <tim.brown at cityc.co.uk>
To: "Matthias Felleisen" <matthias at ccs.neu.edu>
Cc: "Racket Users" <users at racket-lang.org>
Sent: Friday, January 18, 2013 6:36 PM
Subject: Re: [racket] variables within macros


> On 18/01/13 15:54, Matthias Felleisen wrote:
>> Is there a single stumbling block or do you feel overwhelmed by
>> the broad API to the syntax system? -- Matthias
>
> It's a combination of the two...
>
> My single stumbling block is "binding" identifiers -- I'm never sure if
> I'm going to end up with an identifier referencing the same value/entity/
> thing. This is because I'm not so used to passing the lexical context
> around as the macro API (probably) demands.
>
> So, in order to get my bindings right, I want to be sure I'm using
> the right syntax-... calls. And this is where the breadth of the API
> starts to overwhelm me.
>
> There is also the fact that I'm "feeling around" the rest of the racket 
> API
> to understand the runtime-work that I want my macros to help me with.
> Trouble is, the more I look into it "runtime" seems to be less like
> "execute a function" and more like "run another macro"!
>
>
>
> A concrete example is that I am trying to write a #lang language. Which, I
> believe (from syntax_module-reader.html) requires me to:
> (provide (except-out (all-from-out racket) #%module-begin)
>          (rename-out [module-begin #%module-begin]))
>
> I also want to (provide define/tested) which defines functions (with
> racket's define), but also adds a unit test to the function... ala
> (check-= (add2 2) 4 0 "something descriptive") Racket/raco provides the
> facility to put that into a "test" module for unit testing.
>
> But I find that because I'm tinkering with #%module-begin, simply adding
> a (module+ test (check-= ...)) clause causes problems.
>
> I *think* I'm doing something relatively simple; but there are enough
> gotchas here to keep me going round in circles.
>
> What I have just described is in:
>   https://github.com/tim-brown/plt-games-racket-tested
>
> the "minimal-..." code(*), when run leaves me with the error:
> "check-=: unbound identifier in module in: check-="
>
> To my mind there is nothing wrong! There is either something stupid that
> I'm missing, or there is something that requires "knowledge of how all of
> racket works together" (as described above).
>
> This is a bit of a big bite to have taken out of the macro system, but I
> have to start non-triviality somewhere. Equally, though extending the
> language is something that Racket encourages; and as far as I can tell,
> this is (or should be) a trivial extension.
>
> Thank you for listening :-)
>
> Tim
>
> * the rest of the code shows evidence of me banging my head against 
> various
>   walls, may be instructive as to what extremes I have gone two, and may
>   also provide amusement; but the minimal-... code is fundamentally where
>   I'm coming stuck.
>
>
>
>> On Jan 18, 2013, at 6:38 AM, Tim Brown wrote:
>>
>>> On 17/01/13 21:33, Greg Hendershott wrote:
>>>>>> Greg Hendershott's pages may be of interest to you:
>>>>>> http://www.greghendershott.com/fear-of-macros/
>>>
>>> Which is as close as I have come to "How to Design Macros" so far.
>>>
>>>>> I read that earlier, and it gave me the confidence to get stuck in...
>>>>> maybe I read it again to give me the insight to know what I'm doing.
>>>>
>>>> Well it might help prepare you to understand something like Danny's
>>>> solution. But unfortunately it doesn't specifically explain local
>>>> expansion. That was only at the fuzzy edge of my own understanding.
>>>> Still is: When I read something like Jens' code, my brain still hears
>>>> "blah blah blah Ginger".
>>>> <https://www.google.com/search?q=blah+blah+blah+ginger&tbm=isch>
>>>
>>> Do you _know_ how good it makes me feel that someone else "blah blah 
>>> blah
>>> Ginger"s with macros?
>>>
>>> Went through fear-of-macros AGAIN last night. I think I can cope with 
>>> that!
>>> It all sounds *so reasonable*... but everything anyone writes about 
>>> macros
>>> sounds *so reasonable*. Until I put the page down!
>>>
>>> I feel like one of those Zen disciples who just doesn't get it.
>>> But quite often they do. After a while. So I'm keeping up hope.
>>>
>>> Tim
>>>
>>> --
>>> Tim Brown <tim.brown at cityc.co.uk>  | City Computing Limited            |
>>> T: +44 20 8770 2110                | City House, Sutton Park Road      |
>>> F: +44 20 8770 2130                | Sutton, Surrey, SM1 2AE, GB       |
>>> -----------------------------------------------------------------------|
>>> BEAUTY:  What's in your eye when you have a bee in your hand           |
>>> -----------------------------------------------------------------------'
>>> City Computing Limited registered in London No. 1767817.
>>> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
>>> VAT number 372 8290 34.
>>> ____________________
>>> Racket Users list:
>>> http://lists.racket-lang.org/users
>>
>
>
> -- 
> Tim Brown <tim.brown at cityc.co.uk>  | City Computing Limited            |
> T: +44 20 8770 2110                | City House, Sutton Park Road      |
> F: +44 20 8770 2130                | Sutton, Surrey, SM1 2AE, GB       |
> -----------------------------------------------------------------------|
> BEAUTY:  What's in your eye when you have a bee in your hand           |
> -----------------------------------------------------------------------'
> City Computing Limited registered in London No. 1767817.
> Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE
> VAT number 372 8290 34.
> ____________________
>  Racket Users list:
>  http://lists.racket-lang.org/users