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

[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