Update ls.rb without requiring Set, because Set is one of standard libraries

[neko314]

what I did

I replaced some codes to using Array not Set.

background of this PR

I found that require 'set' returns false on irb.
In the case of Ruby, users usually need declare require 'x' to use x when it is a standard library. Set class is a standard library. So expected value of require 'set' is true, but actually not. I think it's a confusing.

supplement

I researched the reason of this problem. The root cause of the problem seems to be rubygems from stack trace below. So only the changes in this pull request can't resolve the problem. But I think irb itself is better not to depend on standard library.

$ irb
/Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/set.rb:65:in `<top (required)>‘: aaa (RuntimeError)
	from <internal:/Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:148:in `require’
	from <internal:/Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:148:in `require’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph/vertex.rb:158:in `new_vertex_set’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph/vertex.rb:141:in `_path_to?'
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph/vertex.rb:133:in `path_to?'
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph.rb:192:in `add_edge’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph.rb:152:in `block in add_child_vertex’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph.rb:150:in `each’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/dependency_graph.rb:150:in `add_child_vertex’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:738:in `block in require_nested_dependencies_for’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:737:in `each’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:737:in `require_nested_dependencies_for’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:727:in `activate_new_spec’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:684:in `attempt_to_activate’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:254:in `process_topmost_state’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolution.rb:182:in `resolve’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver/molinillo/lib/molinillo/resolver.rb:43:in `resolve’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/resolver.rb:190:in `resolve’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/request_set.rb:411:in `resolve’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems/request_set.rb:423:in `resolve_current’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems.rb:240:in `finish_resolve’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems.rb:303:in `block in activate_bin_path’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems.rb:301:in `synchronize’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/lib/ruby/3.0.0/rubygems.rb:301:in `activate_bin_path’
	from /Users/kanekokeiko/.rbenv/versions/3.0.1/bin/irb:23:in `<main>'

[aycabta]

The most fundamental cause is that the Ruby interpreter that is running IRB itself is also running the code you input into the IRB. But I understood what you want to do, and I figured out what you wrote in this Pull Request. I'll merge it.

Separation Ruby interpreter running IRB and running the code you input is really hard work, but I'll spare no effort to cooperate if you try it. Please consult with me easily at any time. When will you do it?

[neko314]

The most fundamental cause is that the Ruby interpreter that is running IRB itself is also running the code you input into the IRB. But I understood what you want to do, and I figured out what you wrote in this Pull Request. I'll merge it.

Separation Ruby interpreter running IRB and running the code you input is really hard work, but I'll spare no effort to cooperate if you try it. Please consult with me easily at any time. When will you do it?

Thanks a lot.

I have no idea what's going on still just now, so I can't think of the problem in smaller pieces, and I haven't come up with any specific questions yet. But I'll give it a try in the near future.