Code Review Stack Exchange is a question and answer site for peer programmer code reviews. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am attempting to break down a Rebol View into a Forth style 'divide and conquer' word set, to optimize readability and organization, and to segregate the business logic from the view layout inner workings.

Business intelligence


  • declaration
  • initialization
  • processing

Software intelligence

  • view layout

Is there a way to simplify the following code?


    Result: "Test"

    field1.Process: [
                alert join  "You typed: " 
                Result: field1/text

    field1.Initialize: [do [field1/text: Result]]

    field1.Declare: compose/deep [
            field1: field

    block:     compose [ 

    view layout (block)
  • Layout block structure being

    field: field-type [field-process]     [field-initialize]

    I seek to optimize notation

    field1.Process: []
    field1.Initialize: [do []]
    field1.Declare: compose/deep [
            field1: field

    Towards minima

    field1.Process: []
    field1.Initialize: []
    field1.Declare: compose/deep [
            field1: field
share|improve this question

Try to avoid mixed casing in new dialect designs

Rebol preserves the case of characters when they match the lexical rules to become a symbolic type in the homoiconic structure being produced:

>> to-string quote field1.Process
== "field1.Process"

>> to-string quote field1.process 
== "field1.process"

Yet despite keeping the case in the symbol, it does not use this to distinguish lookups in the (DO "dialect") evaluator:

>> field1.Process: 10

>> print field1.Process

>> print field1.process

This is why you will rarely see mixed case symbols in Rebol. That is, unless they are in a block representing a dialect that was specially written to have case-sensitive behavior. Your example here is not quarantined in that way. It's all just running in the default evaluator.

Even if it were quarantined in a dialect: not only is lowercase typing consistent with the language's lookup rules, it's easy on the shift key (as is Rebol's choice of square brackets for the primary block delimiter...) Try to stick with it where possible.

Don't fight the lexer, use structure!

When you write something like field1.Process that's going to become a single symbol, you're setting yourself up for further processing work. Now you have to find the position of the period, separate things out, etc. Luckily Rebol makes that easy:

>> parse "field1.Process" [copy left to "." skip copy right to end]
== true

>> print left

>> print right

Still, it's a bit of a shame to not think a little more outside the box. Why not filenames (starting with %) to identify fields, and tags (enclosed in <>) to identify your steps? You don't need to do any extra work:

>> length? [%field1 <Process>]
== 2

>> type? first [%field1 <Process>]
== file!

>> type? second [%field1 <Process>]
== tag!

Depending on your needs, it might be good to free up ordinary words for your dialect keywords. I don't have an immediate intuition for what you are trying to accomplish here. But the point is, the more you can leverage the Rebol typeset the better. And of course there are paths, which are structural:

>> type? quote field1/Process
== path!

>> length? quote field1/Process
== 2

Don't fight the evaluator, make a dialect!

Remember that COMPOSE is (a) something you could have written yourself, and (b) there to help you as a tool in creating your own dialect. You can even use the /NEXT refinement of DO to chain to the Rebol evaluator to execute one full expression and stop:

niftyprint: function [spec [block!]] [
    pos: head spec
    reversed: false
    while [not tail? pos] [
        case [
            #backwards = first pos [
                reversed: true
                pos: next pos

            #forwards = first pos [
                reversed: false
                pos: next pos

            true [
                result: do/next pos 'pos
                prin either reversed [
                    reverse form result
                ] [
                    form result
                prin space
    prin newline

Trying it out, you'll get:

>> niftyprint [{Sum is} #backwards 1020 + 304 {,looc} #forwards "huh??"]
== Sum is 4231 cool, huh??

So you didn't have to reinvent the wheel to delegate to Rebol's inner logic of figuring out (for instance) that infix addition needs to have its two arguments fulfilled. This can be a way of reducing the need to go around putting brackets on everything, and it can become more free.

Of course, that freedom has some drawbacks. You get less checking. But when the tradeoffs are balanced you can get something that has a lot of the feeling of just writing sentences as one would in English.

Moreover, the PARSE dialect itself can be used to make processing your odd blocks all the easier. Consider an alternative implementation of the above:

niftyprint: function [spec [block!]] [

    direction: #forwards

    output: function [value [any-type!]] [
        str: form value
        if direction = #backwards [reverse str]
        prin str
        prin space

    parse spec [
        (print "hi" probe pos print "there")
        any [
           set direction #backwards
           set direction #forwards
           pos: (output do/next pos 'pos) :pos

Just a few thoughts to consider.

P.S. As with LISP eventually going with the trends and going by Lisp, REBOL has "modernized" by officially changing to Rebol (Although the originating company, currently inactive after the open-sourcing, is still incorporated as REBOL Technologies.) I personally think it looks better to start scripts with Rebol [], but as mentioned above the lookup is case-insensitive... and mixed case is discouraged. So it's up to you. Kind of a special case.

share|improve this answer
I hope my editing the question answers your "I don't have an immediate intuition for what you are trying to accomplish here." remark. – OneArb Nov 13 '14 at 20:34

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.