Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[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