JS Symbols round trip as Strings if sent to Ruby and back

Start by reading the Ruby to JavaScript value conversion path used by MiniRacer::Context#attach and the related symbol marshaling code. Reproduce the reported round trip with the provided example, then review the comment thread for project guidance on symbol behavior. Done means the project has a decided behavior for generic, registered, and well-known symbols, with the round-trip results matching that decision.

I've noticed there are a few issues with how Symbols are marshaled between JS and Ruby. The most obvious issue being: if you take a JS Symbol, send it to Ruby, and then back into JS, you get it back as a string, not a symbol. There's a few other related issues (including at least one hard crash), but I'm hesitant to try to fix these without double-checking what the project wants to do with symbols in general. They are clearly being handled wrong (from JS's point of view, at least) right now, but I don't know if that behavior is being relied upon somewhere, or is deliberate rather than accidental, so I'd like to sanity check this before I spend time implementing a fix.

Looking at this from a purely JS-centric perspective, I believe the problem is that JS symbols are being marshaled into Ruby symbols, and JS symbols and Ruby symbols are completely at cross purposes: JS symbols are meant to be primitives that use instance-equality: Symbol("foo")==Symbol("foo") is false in JS because they are not the same instance. Trying to serialize most JS symbols is sort of perverse, they are pretty much deliberately made to not serialize. Ruby Symbols on the other hand seem to be glorified interned strings, except that if you ask for the symbol :foo you always get the same instance. Which is completely the opposite of JS symbols, but somewhat similar to JS's Symbol.for() function. So there's a pretty big mismatch there. And then since Ruby symbols are just special strings, when you try to send them back into JS, they wind up converting to JS strings rather than back into Symbols as they should.

From a JS perspective, the ideal situation would be:

1. Symbols round-trip as symbols, not as strings

2. Symbols created with Symbol.for or that are well-known symbols (such as Symbol.iterator) round trip as themselves: i.e. the before-value and the after value == each other. (v8 keeps track of it's Symbol.for'd symbols, so it shouldn't be a problem to differentiate those from generic symbols)

3. Other symbols (i.e. Symbol('foo') ) could maintain equality before and after the round trip or not (I honestly don't know what "correct" here is because JS symbols aren't really meant to be serialized). Alternatively, other symbols could just fail to marshal since trying to serialize an entity that by definition is unserializable is just weird.

I'd be happy to take a stab at implementing the above to get Symbols handled properly (and then I can start to address other symbol related problems), but as I said, I want to double check that this isn't working against the project's goals before I spend too much time on this. And if anyone has a strong preference for what to do with 'generic' symbols like Symbol("foo"), I'd love to hear it; as I said, it is not at all clear to me what "correct" behavior is there; everything will seem wrong to someone. My inclination is "do whatever is easiest" which is almost certainly going to be "they round trip as symbols, but do not maintain equality" (which makes sense: if you round trip {} to Ruby and back, it stays an object, but does not == it's pre-round-trip self)

Here is a very simple example showing some of these issues:

require 'mini_racer'

context = MiniRacer::Context.new

context.attach('round_trip',proc{|a| a});

context.eval <<~JS
    var sym_gen=Symbol('foo');
    var sym_for=Symbol.for('foo');
    var sym_wk= Symbol.iterator;

    var sym_gen_rt=round_trip(sym_gen);
    var sym_for_rt=round_trip(sym_for);
    var sym_wk_rt= round_trip(sym_wk)

    var object={};
    var object_rt=round_trip(object);
JS


puts context.eval 'typeof sym_gen_rt' # expect "symbol", get "string"; alternatively, expect invalid conversion error
puts context.eval 'typeof sym_for_rt' # expect "symbol", get "string"
puts context.eval 'typeof sym_wk_rt'  # expect "symbol", get "string"

# The following are all currently false because of round-tripping as strings.
# The expectation values are what I'd expect if that were fixed and they round-tripped as symbols.
puts context.eval 'sym_gen_rt===sym_gen'  # expect (I have no idea), get false
puts context.eval 'sym_for_rt===sym_for'  # expect true, get false
puts context.eval 'sym_wk_rt===sym_wk'    # expect true, get false

puts context.eval 'object_rt === object'  # expect false, get false, included to show symbols breaking equality isn't unprecedented