repl can't provide a value back to Rib.anchor caller.

[ghost]

scroll to "rib":
https://github.com/robgleeson/binding.repl/blob/master/doc/exit_values.md

it's a feature pry and IRB support but rib and ripl don't appear to. imagine a scenario like:

value = binding.repl.rib; "exit 42"
p value.object # => 42

[godfat]

It seems not very easy to implement this in rib without adding a rib
provided exit method. So I assume in order to provide this, we must
override exit in rib, which I am a bit hesitate to do so.

Is there a real world scenario which really needs this functionality?
For example, somewhere in the code would call exit, and we would want
to examine the exit status somehow?

[ghost]

irb provides 'exit' through a module that is mixed into the binding scope it is evaluating code over. it is messy, since if i say binding.repl.irb, followed by binding.repl.rib in the same irb session, exit for rib will now be IRB's own version that it uses to carry a value back to the caller.

I don't have a good use-case in my mind, but i think pry used that feature to support runtime development. the idea is/was you could pass a value back to the calling scope.

[godfat]

Umm... indeed. I guess that's probably not a very good idea when we
have multiple layers.

In my mind, an interactive shell is more a place for inspecting and
testing results, not really for development. That's probably why I
can't think of any good use case here. Please let me know when you
find a good use case for this, otherwise I guess we could just leave
this as it is now.

(Try to store the value somewhere and retrieve it after exiting the
shell could be a workaround. It's not as good as passing it back since
it could have thread safety issue, but anyway... it would be even more
complicated if threading is involved :o

Oh, or I could provide something like Rib.exit to do something like
irb/pry's exit, which could avoid overriding kernel methods.)

[ghost]

Rib.exit sounds like good middle ground - if you think the feature is worth it. it looks like IRB and pry are the only two repls(I know of) who support this feature. ripl also does not support it. pry avoids the situation we spoke about above by implementing 'exit' as a command that overshadows Kernel#exit(the method). if you provide Rib.exit, I can update the docs and include the version of rib which supports it. it's not an important feature but i noticed the difference today.

[godfat]

I guess I'll leave it as it is for now until there's a good use case,
or there's another reason to introduce a real command system. For a
real command system, I mean before passing the input to eval, parse
it and process it first.

That means, exit 42 could be a command, but send(:exit, 42) would
be a ruby code which would be evaluated. I guess this is also how pry
implemented this?

[ghost]

in a similar way, yeah. commands are mapped to a Proc/method by reading through user input and mapping exit to a command instead of Kernel#exit. Rib.exit seems like a clean solution to me and solves the problem without polluting the repl's scope but a command system would be the better alternative, I think.

[godfat]

My concern regarding a command system is that it's a separate system,
an extra layer. If we try to make the command syntactically compatible
with ruby, then we might need to worry about something like exit 41+1. It can't really be compatible with ruby unless we're really
treating them ruby, but if we're treating them ruby, then why not just
make them ruby?

So I still hesitate to add it.

[ghost]

yeah, something like pry's command system isn't easy to get right and cover the edge cases. exit 2+2 would actually work in pry because 2 + 2 is an argument to the command who gets evaluated as ruby and passed back to the caller. to keep it simple, Rib.exit() seems okay to me.

[godfat]

:)
Please let me know if there's other commands which would be good to
have, then I guess I'll add them via Rib namespace.

[ghost]

will do. so far i've only come across exit.
to extend a console or repl custom commands or methods become very useful though, so I might come up with more later :)