Design Guidelines
Erlbol is client-driven.
In other words, the client side (REBOL) initiates an exchange (send - receive) with Erlang. The design does not handle a continual or intermittent flow of data from Erlang.
Be internally modular.
1. Erlang: Create interface code that does not require any modification of the functions that 'do the work'. This allows for quickly 'putting a face' on Erlang code. The Erlang functions should continue to work normally in an Erlang console.
2. REBOL: Allow for quick and easy window layouts. Do not process data in REBOL. Use REBOL to provide a GUI for Erlang.
Simplify the data interchange
3. Use Erlang's 'external term format' for binary data transfer between the programs. Details of ETF are here.
Assign responsibilities
4. REBOL: Hold REBOL code responsible for sending a list of strings to Erlang, properly converted into a binary that Erlang can convert back using binary_to_term/1.
5. Erlang: Hold Erlang code responsible for turning the list of strings into appropriate data types before sending the output to Erlang processing functions.
6. REBOL: Hold REBOL code responsible for converting the binary sent to it from Erlang into the equivalent to Erlang's binary_to_term/1.
Do I have to learn REBOL?
No, but you should look at lots of examples that create windows, then design a bunch without making them do anything, trying little changes, so you see how they look. Once you see how easy it is to make a window (compared to using the Erlang gs module or something else), you may decide it's a small price to pay to learn more about REBOL.
The basic REBOL code example requires you to fill in the fields and click a button. The modified versions use clickable lists to select the Erlang function. If you compare the window layouts, you'll see there's not a whole lot of changes that you have to make to add that kind of feature.