[racket] variables within macros

My experience learning Racket (starting from not really knowing any
lisp/schemes at all), is that you can do a lot with a simple core. The
rest can unfold gradually and simply on an as-needed basis:

1. You need to do X real-world thing, and you find/learn/use Racket's
"battery included" to do that. (Where X is net, web, image, GUI or
whatever.)

2. What you're writing works, but you're curious if there's another
way to express it.

I _think_ that's pretty typical for any language?

In my experience the only two big "speed bumps" are macros and
continuations. I think the issues here are:

1. The mental model is a bigger step up.

2. Terminology soup.

I think that's what causes "syntax expand transformer datum splicing
#' #, stx blah blah blah Ginger".

But actually, this is like my original point. You can write a _lot_ of
stuff using syntax-rules etc., which has none of that cognitive load.
So this is a box you don't need to open until/unless you're ready.

Maybe there's potentially a "marketing problem" if people look at
Racket too quickly and the surface area seems too big and complicated,
and mistakenly conclude that's a bad thing?  But I don't think that's
the reality. IMHO.

On Sat, Jan 19, 2013 at 4:00 AM, Laurent <laurent.orseau at gmail.com> wrote:
> Rüdiger,
>
> I used to think as you do (for the same reasons and with the same history
> you describe), but then I understood that the macro system is still an area
> under research. I think PLT and all other Scheme researchers are all willing
> to have the simplest and most beautiful definition of a hygienic macro
> system (or whatever comes next), but currently Racket's is the best we have
> (although I know little about other macro systems, so certainly some people
> would disagree).
>
> Regarding the whole rest of Racket features, bells and whistles, you can
> still do without them if you want, but you'll end up redefining them all at
> some point. The programmers behind Racket are doing their best to produce
> practical yet powerful tools, but hey, they're only human. If you find a
> better way to do something they did, just make it a PLaneT package, or fork
> the git repository, and discuss the benefits on the mailing list. I'm pretty
> sure they're all willing to make Racket better and simpler.
>
> However, I also agree that Racket is quite complex if you want to know it
> all. And collapsing some parts of it into simpler structures might be
> difficult because of the required backward compatibility. I wish sometimes
> programmers could be able to care less about that.
>
> Just my own point of view,
> Laurent
>
>
> On Fri, Jan 18, 2013 at 9:22 PM, Rüdiger Asche <rac at ruediger-asche.de>
> wrote:
>>
>> 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
>>
>>
>> ____________________
>>  Racket Users list:
>>  http://lists.racket-lang.org/users
>
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>