var foo = (function () {
      var n = {};
      return function ( s ) {
          return Function( "n",
              "\"use strict\";\n" +
              "return (\n" +
              s + "\n" +
              ");\n" +
              "//@ sourceURL=foo"
          )( n );
      };
  })();
  
  foo( "n.foo = 5" );
  foo( "n.foo + 10" );

  (function () {
    "use strict";
    console.log(eval("var x = 5; x"));
    console.log(eval("x"));
  })()

If the above code wasn't in strict mode, it would have printed 5 both times, and the variable "x" would have been local to the function block:

  (function () {
    console.log(eval("var x = 5; x"));
    console.log(eval("x"));
    return x;
  })()

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."

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

---

"It's not idiomatic to assign to variables [in Nulan]."

Well, I wonder what Ruby idioms were like before Rails came along! EDSLs often use every readability-enhancing language feature they can get their paws on, regardless of the intended stability of those features.

I'm a culprit of this. Consider my Arc module system, where namespaces work by assigning macros to the global scope, calling 'eval on a module body, and removing the macros again. When my module system didn't work in Jarc and Rainbow, I considered Jarc and Rainbow to be nonconformant, even after jazzdev and conanite fixed most of the obvious bugs and probably conformed to pg's intended design about as well as pg-Arc did. :)

---

Blog post: "It forces every Ruby programmer to second-guess every block of code they pass into someone else's library or someone else's method call."

You: "I'm fairly sure Nulan avoids [this issue]"

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.

---

"[...]but I think this kind of "magical action at a distance" is consistent with Ruby's hyper-liberal viewpoint."

  # library1
  (types %inject)

  (def (add-all [ %inject f ])
    (f "" -> str acc (+ acc str)))

  # application
  (import library1)

  (def (my-+ x y) "@x plus @y")

  (def (my-array)
    [ %inject -> str f
                (do (each {"foo" "bar" "qux"} -> x
                      (set! str (let! + my-+ (f x str))))
                    str) ])

1) It's not idiomatic to assign to variables. Instead, it's idiomatic to use unique types to create extensible functionality. Mutability is discouraged in general (though allowed).

2) It's also possible to protect against such things, if you really want to. For instance, you could do this:

  # library1
  (types %inject)

  (def (add-all [ %inject f ])
    (f "" -> str acc (+ acc str)))

  (var + +)

  # library1
  (protect-all
    (types %inject)

    (def (add-all [ %inject f ])
      (f "" -> str acc (+ acc str))))

Of course, I guess the same argument could be used for Ruby... if refinements aren't idiomatic, then it's not a big deal, right? Well, except that mutable monkey-patching actually is idiomatic in Ruby, refinements are just a way to scope them.

Thankfully, I believe Nulan avoids most of that issue by A) using global names, so you could simply define a new "camelize" function, no need to attach it to the String class, and B) a combination between mutable variables/hyper static scope/unique types/Arc-style "extend" to control extensibility.

I'd be interested in seeing some examples where Ruby's refinements are better than Nulan's system.

---

Some interesting points:

"Because there's no "using" anywhere in the code, and we're not extending some other class, most folks will assume we're simply concatenating strings here. After all, why would I expect my "+" call to do something else? Why should my "+" call ever do something else here?"

"The "module_eval" behavior of refinements simply goes too far. It forces every Ruby programmer to second-guess every block of code they pass into someone else's library or someone else's method call. The guarantees of standard method dispatch no longer apply; you need to know if the method you're calling will change what calls your code makes. You need to understand the internal details of the target method. That's a terrible, terrible thing to do to Rubyists."

Actually, this is going a bit off topic, since it doesn't especially matter to me whether exact integers are a subset of inexact numbers. I thought I even deleted this part of my reply, but oh well. XD

Looks like the racket docs say[1] Racket's inexact numbers are IEEE floating-point numbers of single or double precision, with double being the default. So they don't preserve integers beyond 53 bits:

  > (define foo 12345678901234567890)
  > foo
  12345678901234567890
  > (inexact->exact (exact->inexact foo))
  12345678901234569216
  > (number->string foo 2)
  "1010101101010100101010011000110011101011000111110000101011010010"
  > (number->string (inexact->exact (exact->inexact foo)) 2)
  "1010101101010100101010011000110011101011000111110001000000000000"

Not if I change printing to always use floating point, or print exact floating points as integers. :P I actually did something like that with Arc/Nu: I was tired of typing in (/ 1 5) and getting back 1/5, so I changed Arc/Nu to print exact numbers as if they were inexact, so it would print 0.2. This only affects the printing, not the actual math stuff.

---

"I don't know about that. What happens with very large, but exact, integers?"

I dunno, what happens in Racket?

---

"Similarly, in JavaScript I tend to use Arrays of strings, storing them as their ECMAScript 5 JSON representation."

"I prefer to view integers as being a subset of floating point[...]"

I don't know about that. What happens with very large, but exact, integers?

---

"[...]so I prefer to see 1 and 1.0 as identical. Is there a reason not to?"

Actually I think there is a reason. We're talking about exact and inexact numbers here. If you want to know that a number is exactly 1, then 1.0 doesn't give you enough information. :-p

Personally, I think floating point numbers mostly get in the way. I'd rather treat them as a separate concept, even if it means using a special +. operator like OCaml.

More specifically...

In Arc I can't really rely on using lists as keys, since (IIRC) Jarc converts table keys to strings using the same behavior as 'write. However, in practice I have used lists of alphanumeric symbols, since those have a predictable 'write representation on Jarc, a predictable Racket 'equal? behavior on pg-Arc, etc.

Similarly, in JavaScript I tend to use Arrays of strings, storing them as their ECMAScript 5 JSON representation.

  myTable[ JSON.stringify( k ) ] = v;

To answer your question, the first example that pops to mind is file uploads in arc. Let's consider a parallel universe where arc came with multi-part file upload support, and it worked for you out of the box, and you never came here with questions, and I never delved into how it worked. In that scenario the file-upload features in arc would be a service to me, not an abstraction. But in this universe all those things happened[1], and now file-upload is an abstraction for me. I know I can get into its guts if I find something wrong. I've become a lion when it comes to file upload (http://paulgraham.com/boss.html).

Notice that this would be true even if the code I wrote for it were identical to the code the authors of arc would have written (ha!). This isn't a technical argument but a social one: Programmers should learn about their dependencies. Or put another way: Ask not if something is an abstraction. Ask if it is an abstraction to you.

(Did that make sense?)

Oh, well then welcome to the club. XD

I looked around for where I talked about this before, and I guess I was mainly thinking about this time: http://arclanguage.org/item?id=13701

I touched upon it in at least one other conversation after that: http://arclanguage.org/item?id=14596

However, I can't find any more than that. Maybe I just took it for granted at that point.

Quite the rare thing indeed.

---

"I seem to remember us advocating egal a few other times (though I don't think I've ever called it "egal")."

I personally haven't. I only recently started to actually care about egal because of Nulan using immutable objects.

Oh, I can understand that point of view. Just because there were multiple examples doesn't mean each one introduced new requirements.

---

"It's obvious that you want to think in terms of package managers, and that's fine, but I really do not get the impression that's what they're talking about."

I just wanted to help you elaborate on the claims you're making about Nulan's namespace system. You originally quoted Casey McCann's examples, but I perceived them differently than you did, and I had trouble understanding your perception from your terse example code.

Now this seems to be resolved. We may not agree in our interpretations, but now I understand your claims relative to both of them. Thanks for your patience with me. ^_^

---

"Ultimately, it seems the only way to resolve this is to actually ask them what they meant."

Then make the objects immutable. Then equal makes sense. Then the compiler/interpreter knows what your intent is. Then you avoid all these issues. Then you don't even need a distinction between eq/equal: you can just use egal.

Just as a point of interest, Racket handles this with its built-in types:

  > (define foo (mlist 1))
  > (set-mcdr! foo foo)
  > foo
  #0=(mcons 1 #0#)
  > (define bar (mlist 1 1))
  > (set-mcdr! (mcdr bar) bar)
  > bar
  #0=(mcons 1 (mcons 1 #0#))
  > (map (lambda (f) (f foo bar)) (list equal? eqv? eq?))
  '(#t #f #f)

That said, I don't care if this functionality is provided as a two-argument function or as (addr ...).

---

"Yeah, using lists and hashes as hash keys is kinda crazy. And mutating such hash keys is utterly crazy."

I built Cairntaker on the idealistic notion that every single first-class value is a mutable or immutable weak table. That includes the table keys. Cairntaker does make compromises for performance and FFI, but none that betray this ideal.

I think the crux is this: "..it is possible to distinguish two mutable objects by mutating one of them and checking to see if the same change occurs in the other object."

This still feels like a crazy abstraction. If two mutable objects look the same I want equality to say they are the same by default, not go into contortions to cover its ass because I might choose to mutate them and I might then care about reference equality.