Late to the party, and to make life simple, I removed all quoted material.
Asumu quoted me from the early 1990s. That's what I
understood back then about macros and I got on the
wrong track with this idea for about five to eight
years. I wanted macros to become complete language
definitions ... and that's what they are good for,
but there is way more in all directions. So here are
two thoughts.
First credit to Kent Dybvig who bluntly said to me
in '97 or so, I want to be able to define macros inside
of some lexical scope. These days I define little macros
inside of loops or methods all the time.
Here is an example:
(define/public (run)
(parameterize ([current-input-port in] [current-output-port out])
(send-message SIGN-UP)
(define ok (read-json in))
(define/fsm start
(state: start json->start void --> choose)
(state: choose json->choose (compose send-message values) -->
feed-next)
(state: feed-next json->state next->json --> feed-next || start))))
The above is a remote proxy that will receive three kinds of
messages on port 'in' and will respond via a call to a proper
class. Then it transitions to a different state where it will wait
for a different kind of input. The define/fsm macro makes this
incredible easy to express. I bet everyone can read this 3-line
FSM and guess what each transition does:
-- in state 'feed-next', the method reads the message with json->state
-- calls the method feed-next of the contained object
-- sends the result off to the 'out' port with next->json
-- and then transitions to either feed-next or start,
depending on what kind of message arrives.
The 10-line macro refers to pieces of the class and cannot be
defined globally.
Second credit to Matthew (and Shriram and Robby) who kept me
on the 'macros are good for designing complete languages' track,
too. This one is important for different reasons. Often you want
to create a reasonably complete language but not invent everything
from scratch. In our words, you want 'linguistic inheritance'. For
example, you like Haskell's type system but you hate, loathe, despise
the stupid idea of universally lazy evaluation. Well, if you were
in Racket, you'd define a 10-line language that looks, feels, smells,
tastes like the host but has a by-value evaluation mechanism. Of course,
Racket is by-value, so you may convert it into a lazy language without
giving up the lovely parentheses and the beautiful Lisp syntax. Well,
it's a 10-line language definition, based on Racket's generalization
of old, very old, stone-age old Lisp macro system.
See the last chapter of Realm of Racket on how to teach Kindergarden
kids to define this kind of by-need (actually by-name) Racket.
In short, as Robby says 'macros' (what a stupid word) serve the whole
range of purposes, from little conveniences inside of a class to entire
language rewrites that keep the best of one language and add better
things on top
-- Matthias
--
You received this message because you are subscribed to the Google Groups
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
