gchiu/rebolbot

Make command order be configurable

Opened this issue · 4 comments

Currently commands are loaded in the order they are enumerated by Rebol in the directory, i.e. alphabetically. This can potentially affect the desired outcome of parsing the dialect with the combined rule compiled from all commands..

An hard ordering doesn't really make sense for a system where commands can come and go (both in the dynamic sense and due to commands becoming popular, falling out of use, community provided ones being added to the mix of base commands, etc), but a sparse ordering should be OK.

Built-in commands would have a header field, e.g. Order-hint: 50 where the values would span a wide range (say, 0-200) and be set so that dialect rules can work effectively. This would leave enough gaps for community (not part of the rebolbot project) commands to be dropped in easily without needing to modify the order of existing commands.

The order of the rules is determined by the way parse works, so some rules need to precede others.
But what if we made them order independent?
So, that would mean we would run each command against every rule vs running until one is true?
And all those rules that run true action their commands.

I'm not sure I understand what you mean by the order of the rules being determined by the way parse works. I concatenate them in a particular order (that being the alphabetical order the command files are enumerated in the containing directory), but what I was saying above was that we could set a hint in the header to change this pretty much arbitrary (well, you could re-order by renaming files, but that's not a great solution) order while still leaving gaps so someone could drop in a command that they created and have it slot-in to where it makes sense for that command.

I think there were some rules that you couldn't backtrack far enough if the
order were wrong.

On Sun, Apr 14, 2013 at 12:57 PM, asampal notifications@github.com wrote:

I'm not sure I understand what you mean by the rules being determined by
the way parse works. I concatenate them in a particular order (that being
the alphabetical order the command files are enumerated in the containing
directory), but what I was saying above was that we could set a hint in the
header to change this pretty much arbitrary (well, you could re-order by
renaming files, but that's not a great solution) order while still leaving
gaps so someone could drop in a command that they created and have it
slot-in to where it makes sense for that command.


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-16343869
.

Graham Chiu

Hmm, never knew there was a max number of parallel rules. I mean it's not like you're getting deeper and deeper by having them like they are now. Maybe the limit applies to when you're calling parse again in the parens of a rule.