[REBOL] Re: relative expressions
From: brett:codeconscious at: 1-Apr-2003 10:30
Hi Tim, Anton, Gregg,
Thank you for responding.
Tim wrote:
> I honestly don't know what is meant by "Relative Expression". I
> thought maybe RT like the word "rebol" and reversed-engineered
> the acronym :-)
... REBOL was designed to solve one of the fundamental problems in
computing: the
exchange and interpretation of information between distributed computer
systems.
REBOL accomplishes this through the concept of relative expressions (which
is
how REBOL got its name as the Relative Expression-Based Object Language).
I'd hoped that RT would have provided more direction in this area. I doubt
that
many of us have had much experience design languages/grammars before, yet
the Dialect concept (relative expression) is fundamental to REBOL's reason
for existence. It wouldn't have needed to be created if we could have just
used
other languages to solve the same problems we are already solving.
Anton wrote:
> But, anyway, I reckon
> "relative expression" just means that the
> same word can have different values
> depending on the context. We are so used
> to it that we don't notice how comprehensive
> that is.
> Maybe it should be: Relative Expression Based Context Language.
I think that is a key to the whole concept. But I have difficulty whittling
down the most useful ways to choose good words, good expressions and ways of
establishing the required contexts. Maybe I'm trying too hard. :)
Gregg wrote:
> 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.
That is the promis and what I try to target, but I find the actual process
of doing that very hard. It is not easy to develop the terms that fit the
problem in the first place, there are few examples to understand and follow
in the REBOL world (VID is
my current reference).
I also wonder how multiple dialects can be usefully mixed together. I mean,
lets say we have solved two problems plotting (qplot) and pdf making
(pdfmaker) - shouldn't we aim to be able to mix them so that we could graph
the number of
words per section of a pdf file, or more usefully put a graph into a pdf?
Is this latter combination something that should be easy to solve using yet
another dialect or should it be viewed as a specific "lets hack a solution
together".
> 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".
> 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.
Yes I had been toying with the idea of using the exact same methods of VID
(stylesheet, local style words) to create a markup generator. So that the
same VID source [h1 "An example" text {This will appear on screen and in
print}] would
appear on screen and as xhtml. I suspect Carl had this in mind when creating
VID and make-doc. But I haven't seen any example of this usage. I'm not sure
yet whether make-doc-pro "honors" this latent feature.
You put it well Gregg, I wonder what other "reusable problem definition
languages" there are out there, what they might look like and how well they
mix together.
Maybe a metric for a resuable problem definition language is how many
different useful interpreters can read it?
--Brett