I wonder if Ruby could use something like ECMAScript 6's private names instead.[1] The method name itself would be looked up from the lexical scope, neatly letting the lexical context play a part in resolving a dynamically dispatched method call.
I could be missing something big here. I don't really know all the required use cases, having hardly used Ruby myself.
"It perplexed me that you didn't take that point of view in the first place. :) From that blog post, Ruby's refinements strike me as a snowball of complexity arising from the existing use of monkey patching in the wild. Nulan has no entrenched user base and no monkey patching mechanism (that I can see offhand), let alone a culture of monkey patching, so you have little to worry about. :-p"
Because I was still mulling over the particular problems that that blog post mentioned, and trying to figure out if they applied to Nulan or not. And yes, it does strike me as overly complex, but then again, Ruby already has classes + mixins + 2 or more forms of eval + instance-specific anonymous classes + like 5 different kinds of blocks...
---
"Actually, since Nulan's an fexpr language, its programmers potentially have to second-guess how every single expression will be evaluated. XD Yes you may have idioms to manage this paranoia, but that doesn't make Nulan exempt to the blog post's point, since Ruby could develop idioms for this too."
I'm actually changing Nulan to use macros, for the sake of speed and to make it easy to compile to JS. But yes, fexprs do cause that same sort of second-guessing. And as both you and I pointed out, Nulan is vulnerable, but the idioms are different. In particular, hyper-static scope helps a lot I think.
---
"I wonder if Ruby could use something like ECMAScript 6's private names instead.[1] The method name itself would be looked up from the lexical scope, neatly letting the lexical context play a part in resolving a dynamically dispatched method call."
Well, that's pretty much exactly Nulan's "unique types" system. Not that I'm saying it'd be a bad thing for Ruby to implement that. And I'm actually quite pleased that that system is on the table for JS. I really do feel it's the most flexible type system while still remaining hygienic.
