[REBOL] Re: relative expressions
From: greggirwin:mindspring at: 31-Mar-2003 21:00
Hi Brett,
REBOL is targeting new ground. This can be tough because people have
to see the true target, and appreciate how important it is. What we do
today, myself included, is largely to apply REBOL like we would other
languages. If it were really awful in that regard, it might make it
easier to look at it as something different. Instead, it's really
good, even when applied that way.
I think RT has worked hard to provide this "conceptual compatibility
layer" and done a very soft sell on dialecting, perhaps wisely so.
It's something that you can't explain to most people; they have to
experience it. I know it took me a while to realize just how important
dialects are and, IIRC, it was CHARSET that made it hit me; not PARSE,
not VID, but CHARSET. Funny, huh? :\ It's easy to be in awe of the
PARSE and VID dialects, but all the tiny little dialects are just as
important, if not moreso, IMO.
BH> I think that is a key to the whole concept. But I have difficulty whittling
BH> down the most useful ways to choose good words, good expressions and ways of
BH> establishing the required contexts. Maybe I'm trying too hard. :)
I think it *is* hard. I know I have a hard time with it too. It's easy
to create really stinky dialects and lots of work to create elegant
ones. I think the more we do it, the easier it will get.
I know I still sometimes find myself designing a dialect so it's easy
to parse, which often makes them clunky and programmerish. That, and
I'll think it's not worth it unless the dialect is substantial. Both
ideas are wrong. Small dialects are important and powerful and
dialects should *not* be designed only in a bottom-up manner. Top-down
is the way to design you dialects. Not with a grammar specification,
but with sample text.
BH> That is the promis and what I try to target, but I find the actual process
BH> of doing that very hard. It is not easy to develop the terms that fit the
BH> problem in the first place, there are few examples to understand and follow
BH> in the REBOL world (VID is my current reference).
Have you tried playing "telephone code" to do it? That helps me
sometimes. I have to think like a user. Imagine I'm telling someone
else what I want, without regard for how they're going to do it. We
should probably also get users to help us. Pick a problem domain, find
some non-programmers, and ask them to explain the solution in their
own words.
BH> I also wonder how multiple dialects can be usefully mixed together. I mean,
BH> lets say we have solved two problems plotting (qplot) and pdf making
BH> (pdfmaker) - shouldn't we aim to be able to mix them so that we could graph
BH> the number of words per section of a pdf file, or more usefully put a graph
BH> into a pdf?
Good example. I think a good plotting dialect would become a standard;
then people take that dialect and change the actions behind the rules
to do what they want in a new context. That brings up an important
design point. How to implement dialects so that kind of thing is as
easy as possible.
BH> Yes I had been toying with the idea of using the exact same methods of VID
BH> (stylesheet, local style words) to create a markup generator. So that the
BH> same VID source [h1 "An example" text {This will appear on screen and in
BH> print}] would
BH> appear on screen and as xhtml. I suspect Carl had this in mind when creating
BH> VID and make-doc. But I haven't seen any example of this usage. I'm not sure
BH> yet whether make-doc-pro "honors" this latent feature.
That's what we're doing with the library project, at least partially.
All the static pages were generated from the VID layouts in the REBOL
librarian script.
BH> You put it well Gregg, I wonder what other "reusable problem definition
BH> languages" there are out there, what they might look like and how well they
BH> mix together.
BH> Maybe a metric for a resuable problem definition language is how many
BH> different useful interpreters can read it?
How many can you think of? I'll take a couple minutes and see what I
can come up with.............about 40, but hard to say how "reusable"
some of them would be. :)
Recently had cause to look at the GEDCOM file format - used for genealogy
data interchange - and there are probably at least 5 or 6 different
things you could do with it, just off the top of my head. Probably the
same for many data formats. Some needs will be very small but, again,
those little things can make a big difference.
-- Gregg