That’s beautiful.

You know, it’s a bit embarassing, but before this I had never learnt what method names went with the unary operators. I shall have to file this away…

I get this, except for:

def -@; @action = :reject end

What does the @ do? As opposed to have just “def -;”

The unary ops are -@, +@, ~@, !@

Jon: I believe -@ +@ Are the unary operator method names

Ah, I see. Thanks.

why: awesome, thanks~

It appears that !@ is not definable?

wait wait..i thought i had it but i lost it. The unary + and – methods are in the Rule class, right? So how is it possible that you can call them from Filter? (Like in your example at the top.)

teebag: The unary operators are called on the results of from(), to(), etc. which are Rule objects.

Ezra: ah, good catch. Yes, everything to do with truth in Ruby is hard-coded.

(bit-twiddling is lies. all of it.)

Bonus Challenge

Get the RubyTalk one to work like this:

 class RubyTalk < Filter
   + to | cc("ruby-talk@ruby-lang.org")
 end

oooooooooooooooooo. gotit.

!@ is not a unary operator. Unfortunately it is pure syntax.

excellent, without eval!

problem is: it produces warnings (useless use of +@ in void context.)

ko1 made a lang with this +@ trick: http://flgr.0×42.net/deobfu/1-negaposi.html

I’m sorry. I got that from parse.y, which lists the unary operators in op_tbl. Which means:

 >> "!(unary)".intern
 => :!
 >> "!@".intern
 => :!

But which doesn’t actually work:

 >> true.send("!(unary)")
 NoMethodError: undefined method `!' for true
        from (irb):2:in `send'
        from (irb):2

Ooh, nice ;-)

Did I mention that that x-thing in Textile was a real bad idea?

http://flgr.0×42.net/deobfu/1-negaposi.html

I guess unary ! is parsed and converted to some rb_negate method. Same to != and !~.

NegaPosi

sorry for the spam :( I should really use the Preview. And the Textile Docu.

NegaPosi?

Wait a minute… >_>

why, are you telling us that x.intern.to_s == x isn’t an invariant for non-empty strings?

That sucks—I think almost everybody was under the erroneous impression that it was. Speaking for myself, I know I am going to have to rewrite some code not to use symbols now…

It’s true. In a few cases.

 >> "+(binary)".intern
 => :+
 >> "-(binary)".intern
 => :-
 >> "+(unary)".intern
 => :+@
 >> "-(unary)".intern
 => :-@
 >> "!(unary)".intern
 => :"!" 
 >> "~(unary)".intern
 => :~
 >> "!@".intern
 => :"!" 
 >> "~@".intern
 => :~

I guess that’s okay for many things. My little lisp interpreter’s going to suffer though.

(I wouldn’t use it personally, but according to the R5RS grammar ! and !@ are both valid identifiers.)

huh. I knew there were a couple things like that, but I didn’t realize how bad it was. I think they should be invariant as described above, and the parser/eval should be responsible for dispatching correctly, not the other way around.

As I said in my unposted wink, I smell something fishy. Like a Ruby spam filter. Or something of the sort. This is too EigenSpiffy to only be something to throw arround.

Always wondered about the unary operator def syntax. Too bad about that !@ not being definable, though. Was this a yacc limitation or something? Could it be changed in 1.9?

Huh. I didn’t know you could use instance variables in a class directly via a meta-class. That’s actually kinda frightening.

Wait, is the | operator supposed to make it so that the latter rule’s terms are copied into the former rule or what?

Yah know, I mean, the syntax is cool and all, but, maybe it’s TOO cool, for school, you know?

As a DSL , yeah, sure, but it’s… hrmm.

Well, in any case, I expect _why’s next feat to be shoe-horning the Klingon language into a DSL for putting lids on bacon grease tubs.

Oh, come on, Danno. Just do the exercise. You’ll learn something neat. The pipe is an “or”.

pHiL: It’s got nothing to do with yacc at all.

Ruby’s boolean operations are all hard-coded for efficiency, not implemented via methods.

unariffic!

caveat emptor!

That is one of the simplest, and most beautiful meta-programming hacks I’ve seen in quite a while.

Matz has just verified that the !@ operator isn’t callable and will likely be removed.

So here’s a start. If you want to be able to chain a bunch of |’s together, then Rule might need to keep a list of siblings with which it would like to share it’s terms.

class Filter
  class Rule
    def -@; @action = :reject; self end
    def +@; @action = :accept; self end
    def |(other_rule)
      both_terms = @terms
      both_terms += other_rule.terms
      other_rule.terms = both_terms
      @terms = both_terms
      self
    end
  end
end

why: Can you also ping him about whether we can eventually avoid having different strings intern to the same symbol?

So, can anyone a bit more familiar with Ruby internals tell me the reason strings like ”” are converted to : ?

Okay, I just can’t get this right. I find any way to make plus signs display at all, unless it’s only broken in the ajax-y preview… What I meant to ask is why are strings like "+(unary)" converted to :+@ (COLON PLUS AT -SIGN)

We want

- to | cc("ruby-talk@ruby-lang.org")

to be a shortcut for

- to("ruby-talk@ruby-lang.org")
- cc("ruby-talk@ruby-lang.org")

(I’m rejecting ruby-talk mail because Textile makes it hard to use plus.)

1. the | method is applied last
2. the left operand has the action to apply (actually, IS the action unless we change Rule#-@ to return self)
3. the right operand has the terms

 class Filter::Rule
   def -@; @action = :reject; self end
   def +@; @action = :accept; self end
   def |(other)
     @terms |= other.terms
     other.action = action
     [self, other]
   end
 end

Though I wouldn’t use it since it’s ugly, here’s my solution to the challenge :

 class Filter
   class Rule
     attr_accessor :field, :terms, :action
     def initialize(f, *a)
       @field = f
       @terms = a
     end
     def -@; @action = :reject; self end
     def +@; @action = :accept; self end
   end

   class RulePlaceholder
     attr_accessor :fields
     def initialize(f, filter)
       @filter = filter
       @fields = [f]
     end
     def |(other)
       if other.kind_of? RulePlaceholder
         @fields.concat other.fields
       elsif other.kind_of? Rule
         other.action = @action
         @filter.rules.concat @fields.map { |field| rule = Rule.new(field, *other.terms); rule.action = @action; rule }
       else
         :explode_penguin
       end
     end
     def -@; @action = :reject; self end
     def +@; @action = :accept; self end
   end

   class << self
     attr_accessor :rules
     [:from, :to, :cc, :subject].each do |m|
       define_method(m) do |*a|
         if a.empty?
           RulePlaceholder.new(m, self)
         else
           r = Rule.new(m, *a)
           (@rules ||= []) << r
           r
         end
       end
     end
   end
  end
 

I have seen the error of my ways and slapped it around a bit :

 class Filter
   class Rule
     attr_accessor :field, :terms, :action
     def initialize(f, *a)
       @field = f
       @terms = a unless a.empty?
     end
     def |(other)
       other.action ||= @action
       @terms ||= other.terms
     end
     def -@; @action = :reject; self end
     def +@; @action = :accept; self end
   end

   class << self
     attr_accessor :rules
     [:from, :to, :cc, :subject].each do |m|
       define_method(m) do |*a|
         r = Rule.new(m, *a)
         (@rules ||= []) << r
         r
       end
     end
   end
 end

I have seen the post right before mine and slapped me around a bit.

No, good work, C Erler. The thing is: you get it now. I’m sure Dave and Danno feel better now too. Accolades for all of you.