On Thu, Jun 2, 2011 at 9:26 PM, Caleb Clausen <ca
...@inforadical.net> wrote:
> On 06/02/2011 04:41 PM, rogerdpack wrote:
>> Hello all. Well mostly caleb, if you're still around.
>> After seeing mirah macros, I wonder if something like
>> macro "
>> <something>.go(<args>)
>> =>
>> <something>.go2(<args>)
>> "
> This should work, in git trunk, but doesn't:
> macro go(*args)
> :( (^receiver).go2(^*args) )
> end
> * 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 "
>> <something>.andand.go(<args>)
>> =>
>> if(_v =<something>)
>> _v.go(<args>)
>> end
>> "
> there's an andand.rb in my example/ dir, but it's not really quite the 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
> if (_v=something)
> _v.go(arg1,arg2)
> end
> with syntax maybe like:
> macro operator andand(left,right)
> #somehow gotta specify precedence and associativity too of the new
> operator, tho
> fail unless RedParse::CallNode===right and right.receiver.nil?
> action=right.deep_copy
> action.receiver=:(_v)
> :(
> if (_v=^left)
> ^action
> end
> )
> end
> 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
>> nest them...I wonder how that could ever look/operate well on.
> hmm, define "nest", please.
> 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 :)
>> I know so little about them.
> Not a bad analogy at all. The resemblance is closer in the mirah examples
> you give above and reg's macros-by-example thing. (Wish I could remember the
> name....)
>> http://www.mirah.org/wiki/Macros
> 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.......)
