To a point, but it doesn’t fix the problem because when you’re applying an operator to something, you should know the context as well. I don’t think context is the big issue here. It’s interpretation of how said operator should function given that context. Depending on how you design a DSL, it could be subject to many questions of this nature (which is why a lot of people are saying you shouldn’t make a DSL very natural language-like).

The syntactic sugar that Java did — basically proving some low-level operator overloading for integer and floating point arithmetic — seemed to be a nice compromise between general-case operator overloading (evil[1]) and universal operational purity (off-putting). Surprisingly, I’ve heard very few people lamenting the inability to define + for matrices in Java. The one downside is that there comes a point in every journeyman Java developer’s life where they get confused about why 1 / 7.0 * 7 > 1 — the reality is that floating point and integer arithmetic are fundamentally different, so mixing the two is a Devil’s bargain: you don’t put off beginners used to blurring those boundaries, but you put off intermediate developers who suddenly discovered that there’s a lot of dangerous plays. Of course, by the time they’re intermediate developers, you’ve already suckered them into knowing your language pretty well, so they’re vested.

[1] The biggest evil of general-case operator overloading is that changing foo + bar to bar + foo suddenly drastically changes the definition of “+“. It gets even worse when you consider foo * (bar + baz) vs. foo * bar + foo * baz. Or, y’know, 1 / 7.0 * 7 vs. 7 * 1 / 7.0.

Excellent point on SS. Here’s a very verbose +1:

The interchangeable map access/property access aspect of Groovy (indeed, the entire mostly-orthogonal properties/methods approach) has drastically extended the capabilities for mocking and dynamic typing in that language, even compared to other dynamic languages like Ruby. If you’re testing a method that looks like:

   void foo(bar) {
     bar.baz()
     bar.val++
   }

You can test “bar” with:

def bar = [val:0]
def bazCalled = false
bar.baz = { bazCalled = true }
obj.foo(bar)
assertEquals(bar,1)
assertEquals(bazCalled, true)

That’s simply not a possible approach in languages without that shortcut.

Similarly, I first started getting into functional programming (without really knowing what it was) in Perl, because subroutine references and “method templating” were so easy to do.

my $x = sub { ... }

Because of that, entirely knew ways of meta-programming structures seemed natural, including having objects that were basically just thinly-veiled subroutine references (see my Regexp::Tr library), and then data structures of thinly-veiled subroutine references (see my Text::Shift library).