Looks like you Rubinius people have some work to do.

The right thing to do would be to have Fixnum#/ return a rational number; this is what Smalltalk does.

I’m also going to be at the European Ruby conference (EuRuKo) that’s a week or two after in Prague.. that should be even more fun.

class Fixnum
alias divide :/
def / x
if caller.first =~ /kernel/
divide x
else
…
end
end
end

(j/k)

It seems like the problem is one of unexpected changes of semantics.

I suppose the closest thing I can think of is importing an extra header file that redefines stuff with macros and e.g. makes all your printouts disappear.

Actually, in the case of the macros, I can imagine situations where you DO exactly want to include a macro that made all your debug print messages disappear – as well as that situation where you didn’t want it to happen.

A related problem crops up in debugging where you also want only e.g. a specific subset of debug information to appear – i.e. you want to change semantics for some modules, not all. The solutions I most often see to this aren’t pretty. A different macro for printing for every module. (extra work/complexity, recompiling the affected files) ‘Debug levels’ to run the program at. (bad granularity)

I suppose a way out for this particular problem is distinguishing in kernel code with rigid semantic requirements by using a different name for the fixnum division that HAS to return fixnum from the fixnum division that can be user-redefined to return what the user wants to work in (fractions, decimals, etc).

Then the user is free to redefine the semantics of the operator (which becomes an alias for one or other division func) without changing semantics the ‘fixdiv’ routine, or whatever.

But every other function that can be redefined gives you the same sort of potential dangers…

You could call this ‘The danger of side effects in a language’… and contrast it to ‘the danger of side effects in programs’.