token_type or lexical_type would make more sense to me. On top of defined? not returning a boolean, it has other confusing semantics. In particular, it's the only keyword I can think of that appears to exhibit call-by-name semantics. I don't know if this is just a special parser case, but it doesn't evaluate your arguments despite looking like a method call. So the return value can be doubly confusing.

It's a special parser case. The reason is that defined? may be followed by an uninitialized constant:

  jruby-1.6.8 :089 > defined? Foo::Bar
   => nil 
  jruby-1.6.8 :090 > Foo::Bar
  NameError: uninitialized constant Foo::Bar

You don't want the argument to be evaluated because that could raise a NameError. It's actually an operator.

Thanks for the clarification. I was recently surprised by the return value when:

z = x.y

z == x.y # => true

defined?(z) == defined?(x.y) # => false

what about defined_as

(i agree that within ruby's conventions (weak typing) defined? is not that bad)

> ruby's conventions (weak typing)

No. "Weak Typing" doesn't mean jack shit, and there are very few under its thousands of different and incompatible identities which Ruby would match, save for the very least useful of them.

no. weak typing is exactly what i mean.

> if a.defined?

works, because the returned string type is implicitly converted to a boolean. that's weak typing. at least one (i guess the most common) interpretation of weak typing.