On 06/02/2011 04:41 PM, rogerdpack wrote:
This should work, in git trunk, but doesn't:
> Hello all. Well mostly caleb, if you're still around.
> After seeing mirah macros, I wonder if something like
> macro "
:( (^receiver).go2(^*args) )
* arg to a macro looks like it's broken. guess I gotta make a test case
for that.... in addition, ^* definitely won't work in the current release :(
I hope I can get this to work soon, in git trunk anyway.
> macro " there's an andand.rb in my example/ dir, but it's not really quite the
> if(_v =<something>)
same as what you have above. (I first saw this in reg braithwaite's
macro library.... I tried to imitate his, but maybe missed the point. In
fact, these mirah macros look a lot like reg's macros-by-example.)
It's not really possible to do andand currently. macros have access to
their args, block, and receiver, but not to subsequent expressions on
the same line, from which they are separated by a dot operator (or any
other operator, for that matter). Such expressions are not (directly or
indirectly) subnodes of the macro callsite node in the unexpanded parse
tree, so it's difficult to see how this could really be accomplished in
my rubymacros given the current design.... Maybe with up-pointers in the
syntax trees, but that's still giving me conceptual headaches, so I
don't know how to implement it.
Really, tho, something like andand should be an operator (and named
differently too). Macro operators have been on my list of features to
add for a long time.
So for example, you'd want:
something andand go(arg1, arg2)
should expand to
with syntax maybe like:
macro operator andand(left,right)
#somehow gotta specify precedence and associativity too of the new
fail unless RedParse::CallNode===right and right.receiver.nil?
That's klunky by comparison, I realize. Whenever you start referring to
parse nodes, it gets a lot more confusing/involved. For complicated
cases, that may be necessary, but 'simple' things should be simple. This
particular case should be 'simple', and talking directly to node classes
should be avoidable here.....
Maybe I can come up with a better way. Something like forms with reg
expressions in them for the <holes> was what I wanted to do when I last
thought about this....
> Also I am guessing the "holy grail" of macros is that you can somehow hmm, define "nest", please.
> nest them...I wonder how that could ever look/operate well on.
It should be possible currently to call macros from within macros
(including in the forms returned from macros), to pass macro invocations
as args to macros, and for macros to recursively call themselves (with
the danger of infinite regress, of course).
> This feels almost like erb but for ruby code :) Not a bad analogy at all. The resemblance is closer in the mirah
> I know so little about them.
examples you give above and reg's macros-by-example thing. (Wish I could
remember the name....)
I will queue this up for careful perusal.
PS: I am going to respond to your previous email too. I just haven't had
any time to look into it at all. (Just warning you, I might not be able
to do anything about it.......)