[REBOL] Re: relative expressions
From: greggirwin:mindspring at: 30-Mar-2003 20:47
Hi Brett,
BH> I feel that the process of authoring of REBOL scripts and messages is
BH> habitually thought of as programming and I wonder if there are other ways to
BH> design and think about scripts that more usefully exploit REBOL's
BH> flexibility.
I agree. I think REBOL development really benefits from separating the
requirements (i.e. problem definition) space from the construction
aspect. With most development models, you have to translate the
problem into some "requirements model" for development and then you
have to build the program from those specs, which may have lost
or obscured semantic meaning in the translation.
REBOL can remove the middle-man. First, think about stating the
problem you are solving in terms that fit it best. Next, define a
dialect that understands the problem domain. Finally, implement the
dialect.
This moves us from a model of reusable function libraries and generic
components to a model of (potentially) reusable problem definition
languages. I can think of lots of reasons this could be a *very* good
thing, not the least of which is that if shifts our focus away from
code for code's sake
.
BH> As a start, has anyone got any examples that they feel explain, demonstrate,
BH> exploit or point to the benefits/qualities of the "relative expression"
BH> concept in REBOL?
I wish I had some good examples handy, that were functional. I have
ideas sketched out just waiting for the day I win the lottery. :)
One example is a screen-layout/hard-copy-report situation. In both
cases you're saying "Here's the data I want, and how I want it
formatted". One dialect can serve both needs.
Another example would be workflow/async process definition. "Send
<this-message> to <this-recipient> [at <this-address>]. If no-response
within <this-timeframe>, <take-evasive-action. When response arrives,
ensure <this-response> is valid, log <this-response>, forward to
<this-recipient>, and notify <this-recipient>".
-- Gregg
