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

relative expressions

 [1/21] from: brett:codeconscious at: 29-Mar-2003 15:39


I feel that the process of authoring of REBOL scripts and messages is habitually thought of as programming and I wonder if there are other ways to design and think about scripts that more usefully exploit REBOL's flexibility. As a start, has anyone got any examples that they feel explain, demonstrate, exploit or point to the benefits/qualities of the "relative expression" concept in REBOL? Thanks Brett.

 [2/21] from: tim:johnsons-web at: 30-Mar-2003 13:04


Hello Brett: * Brett Handley <[brett--codeconscious--com]> [030328 21:14]:
> I feel that the process of authoring of REBOL scripts and messages is > habitually thought of as programming and I wonder if there are other ways to
<<quoted lines omitted: 3>>
> exploit or point to the benefits/qualities of the "relative expression" > concept in REBOL?
I honestly don't know what is meant by "Relative Expression". I thought maybe RT like the word "rebol" and reversed-engineered the acronym :-) I use rebol to dynamically produce javascript (which is another programming language, of course) - would that be an example? What about dialects? Andrew, feel free to jump in here... -- Tim Johnson <[tim--johnsons-web--com]> http://www.alaska-internet-solutions.com http://www.johnsons-web.com

 [3/21] from: antonr:iinet:au at: 31-Mar-2003 12:36


I had a long email ready to send, but at the end, I decided I wasn't sure I was answering the question or providing a decent example. 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. Anton.

 [4/21] 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

 [5/21] 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
<<quoted lines omitted: 3>>
> 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
<<quoted lines omitted: 6>>
> 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
<<quoted lines omitted: 4>>
> 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

 [6/21] 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

 [7/21] from: g:santilli:tiscalinet:it at: 1-Apr-2003 14:57


Hi Gregg, On Tuesday, April 1, 2003, 6:00:25 AM, you wrote: 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? GI> Good example. I think a good plotting dialect would become a standard; GI> then people take that dialect and change the actions behind the rules GI> to do what they want in a new context. That brings up an important GI> design point. How to implement dialects so that kind of thing is as GI> easy as possible. This is something I've been thinking about too; actually, my custom-types ides came out from this thinking. If you think about REBOL's function interpreter, you see it is based on values. An expression is just a sequence of values, and depending on the type and the content of these values you get a result when it is evaluated. When we implement dialects using block parsing, we are using the same REBOL values to describe something, and the parser to interpret this and make actions or translate to something else. Now imagine if we had types of values that were designed specifically for our problem domain. In such a case, you would not even need PARSE rules, but only something that makes the correct actions for these values. (Notice that in REBOL the "methods" for datatypes are called "actions". I wonder if this is a coincidence.) This would solve the reusability problem, because you just have to change the actions. However, you still don't have an easy way to "write down" the values; this is where PARSE comes. You design a dialect with the rules to parse it and translate it to a (sequence of) (custom) value(s). It is like VID, that just translates to a FACE, which is then used by View. I really think that having custom types helps a lot with this; just having objects is fine with things like View, because you only have one kind of object, i.e. the FACE. In domains that are more complicated (maybe just because we are not smart enough to make them simpler...) you can easily have the need for many kinds of objects. So you get three layers: Language (dialect) ------------------ Values ------------------ Actions The "values" layer is something that you don't have in languages other than REBOL (at least that I know of). It is the layers that allows dialecting, and that gives REBOL all of its simplicity and flexibility; I think we should use this approach too! What do you think? Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [8/21] from: greggirwin:mindspring at: 1-Apr-2003 9:11


Hi Gabriele, Yes, I think you're right. I *still* have to go back and look at your latest dialect builder stuff (sorry I've dropped the ball on that)! I bet there's a great deal of leverage to be applied between this concept and the "teaching REBOL" thread as it relates to dialects. Sometimes the best way to find the answer to a problem is to explain it to someone else. -- Gregg

 [9/21] from: ingo:h-o-h at: 1-Apr-2003 20:24


Hi Gabriele, Gabriele Santilli wrote: <...>
> Now imagine if we had types of values that were designed > specifically for our problem domain. In such a case, you would not
<<quoted lines omitted: 8>>
> value(s). It is like VID, that just translates to a FACE, which is > then used by View.
<...> You are right, I wrote a webbased calendar using pliant. I wanted to be able to write dates, but with some added sugar. 2003-01-01 would be the first of January 2003 01-01 First of january in whatever year 03/-1 the lasst of february in whatever year and some more like this. I missed my 'parse badly, but then I found the possibility to create new types, along with the to/from string rules - in a way it's even more powerfull then parse, because it is saved in the corresponding variable _as_this_new_datatype_. Having real userdefinable datatypes on the Rebol level would be great. Kind regards, Ingo

 [10/21] from: maarten:koopmans:surfnet:nl at: 1-Apr-2003 22:16


I think we may end up in an operator overloading discussion. But then -as always- more elegant in Rebol. --Maarten

 [11/21] from: g:santilli:tiscalinet:it at: 2-Apr-2003 9:58


Hi Maarten, On Tuesday, April 1, 2003, 10:16:20 PM, you wrote: MK> I think we may end up in an operator overloading discussion. But then MK> -as always- more elegant in Rebol. REBOL natives are highly overloaded; in particular, ACTION!s are basically methods that can be applied to values, and whose action depends on the type of the value. Of course, this can get confusing. However, having a different function for each different type would be even more confusing: if you are doing the same action, use the same ACTION!. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [12/21] from: Maarten:Koopmans:surfnet:nl at: 2-Apr-2003 12:20


Hi Gabriele, I agree and am on your side. I was just warning for these kind of discussions in general ;-) You should browse some Java and C++ mailing lists! --Maarten

 [13/21] from: brett:codeconscious at: 2-Apr-2003 19:40


Hi Gabriele,
> If you think about REBOL's function interpreter, you see it is > based on values. An expression is just a sequence of values, and
<<quoted lines omitted: 3>>
> something, and the parser to interpret this and make actions or > translate to something else.
It took me ages (over a year) to come to realise this about REBOL despite the fact that it is fairly plainly described as you have just done (good work!) and that it is described in the Core manual!
> Now imagine if we had types of values that were designed > specifically for our problem domain. In such a case, you would not
<<quoted lines omitted: 3>>
> coincidence.) This would solve the reusability problem, because > you just have to change the actions.
So, custom types would allow the REBOL interepreter to interpret these expressions directly. Another benefit is that our normal understanding of how REBOL interprets values is used when thinking about these custom values. But I don't think that changing the actions will be entirely sufficient for reusability, although I do agree it could be very powerful.
> However, you still don't have an easy way to "write down" the > values; this is where PARSE comes. You design a dialect with the > rules to parse it and translate it to a (sequence of) (custom) > value(s). It is like VID, that just translates to a FACE, which is > then used by View.
Agreed, though VID does more than create FACEs, it also arranges them (layout). VID is building/maintaining state (e.g offset) as it processes the dialect. I know this seems obvious but I feel it is important to highlight that dialects may have this extra "between the lines" - value adding aspect. I think this relates to Nørretrander's "Exformation" concept(http//www.quinion.com/words/turnsofphrase/tp-exf1.htm). Also in relation to parsing dialects, I'd like to see a methodology for designing dialects so that they can be usefully mixed together (as I mentioned). Some sort of grammar convention might help here.
> I really think that having custom types helps a lot with this; > just having objects is fine with things like View, because you > only have one kind of object, i.e. the FACE. In domains that are > more complicated (maybe just because we are not smart enough to > make them simpler...) you can easily have the need for many kinds > of objects.
Yes custom types could be very important. Though they may not be so good for message passing between distributed systems because they might introduce unwelcome dependencies ("do you have custom type xyz-floating-graphic?").
> The "values" layer is something that you don't have in languages > other than REBOL (at least that I know of). It is the layers that > allows dialecting, and that gives REBOL all of its simplicity and > flexibility; I think we should use this approach too!
That's a really interesting observation. Deserves more reflection :^) Regards, Brett

 [14/21] from: g:santilli:tiscalinet:it at: 2-Apr-2003 15:39


Hi Brett, On Wednesday, April 2, 2003, 11:40:50 AM, you wrote: BH> So, custom types would allow the REBOL interepreter to interpret these BH> expressions directly. Maybe not directly from the function interpreter, but directly in the same way as you can now handle blocks, dates, urls, and so on. You can have a set of generic functions that work on any new type you happen to add to your application in the future... BH> But I don't think that changing the actions will be entirely sufficient for BH> reusability, although I do agree it could be very powerful. Of course we'd really require that creating new datatypes was allowed by the interpreter, and not just by using "hacks" like custom-types.r. BH> VID is building/maintaining state (e.g offset) as it processes the BH> dialect. I know this seems obvious but I feel it is important to highlight BH> that dialects may have this extra "between the lines" - value adding aspect. Yes, and in some cases you'd need to make this "information" explicit in some way, if you want to push reusability. However, since dialects are domain specific languages, usually this between the lines is part of the specific domain too, so it doesn't necessarily have to be made explicit. Take a FACE as an example: it has everything it is needed to render it, and you could render it on a PDF file instead of on a window. If you had something that translated to PDF starting from a FACE, you could use LAYOUT to create graphics for a PDF file. You don't need to know how LAYOUT works internally etc. You just need to know the concept of a "face". BH> Also in relation to parsing dialects, I'd like to see a methodology for BH> designing dialects so that they can be usefully mixed together (as I BH> mentioned). Some sort of grammar convention might help here. Maybe, but it is very dialect-specific anyway. I don't think it is possible to have a solution that is so general to allow you to mix any two dialects, mainly because mixing does not have any sense for most two dialects. BH> Yes custom types could be very important. Though they may not be so good for BH> message passing between distributed systems because they might introduce BH> unwelcome dependencies ("do you have custom type xyz-floating-graphic?"). Of course, and that is the reason why we have View as a single executable. However, as soon as we try to modularize, we get to this problem. A good solution is probably that of having all instanced well synched, so that it is not possible to have two different versions of the same application at the same time. (With IOS you have this automatically, because your reblets are synched, and if you change a reblet the change is reflected to all the users.) Another way is to always provide fallbacks and default behaviors in case of failure. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [15/21] from: greggirwin:mindspring at: 2-Apr-2003 10:54


Gabriele and Brett, Not much time, but a couple thoughts: 1) Combining dialects isn't something I see as simpy a UNION of two or more, but what we do is build up phrases, idioms, and dialect nesting . E.g. maybe there's a dialect for medical terminology. Now, you have messages from people that contain "my doctor said I have..." or "my doctor told me..." which could be used like a switch to jump INTO another dialect (like INTO being used with sub-blocks). In this case, you jump from your main messaging dialect to the medical dialect; maybe even try a list of alternate dialects. Where messages go, and how they are used, will also vary widely. There will likely be cases where a message header will contain metadata that will help tell processors what to do, or what can be done, with them. Think how things like JINI and WSDL are used as an example. 2) The dialect/action combination is a many to many relationship. We may want to replace the actions behind a dialect, but we may *also* want to put a different dialect over basically the same set of actions, or at least achieve the same end result (e.g. parse the data for values, build up a record, put it in a DB). 3) If you've looked at the "programming by example" paradigm, imagine designing dialects by using example text. A sentence contains a subject, a verb, an object, and sometimes some adjectives. "Mr. Morton walked down the street." In this sentence Mr. Morton is the subject walked is the verb the street is the object --- A data record contains 3 fields: first name, last name, and phone number. E.g. Gregg, Irwin, 000.000.0000 Brett, Handley, (00) 00.000.0000 For something like English, or other natural langugages, this could obviously be a bit of work, but there is a lot of text out there that could be used as examples. :) PARSE itself is amazing, but imagine what we can build on top of it! -- Gregg

 [16/21] from: tbrownell:L3TECHNOLOGY at: 2-Apr-2003 14:55


I've found that all data and functions have a natural language "definition", much like pseudocode.... Take all the numbers from the group N, multiply each by 3 and print the result. Becomes... TakeAllNumbersOfN-MultiplyBy3AndPrintFunction: Func [N] [Foreach val n [print val * 3] Every sentence has a subject and a predicate. In the sentence above, the subject is N and the predicate is the function. As I mentioned in earlier posts, there should be a "standard English" (any symbols would do as long as we all agree) to represent the predicates, in this case functions, and what I call LFReD names to represent subjects... which is why 'everything needs an LFReD name" http://LFReD.L3Technology.com/LFReD This concept can carry into other areas; NLP... (Rebol) (rocks the house). Subject: =RebolPredicate: Excellent Semantic Networks... =Rebol= IsA ProgrammingLanguage =Rebol= hasPart GUI Terry

 [17/21] from: brett:codeconscious at: 3-Apr-2003 16:54


Hi Gabriele,
> Maybe, but it is very dialect-specific anyway. I don't think it is > possible to have a solution that is so general to allow you to mix > any two dialects, mainly because mixing does not have any sense > for most two dialects.
I'm not looking for a general way to mix any two dialects, I'm looking for a more general way to design dialects so that they can be easily mixed. Such a thing may not solve all problems but if it solves many problems it has value. I know a solution exists already - write a REBOL script, though I hope for something with a little more leverage. On the other hand maybe the REBOL script is the best solution and I just don't know how to leverage it in the best way. Here's a situation I'm looking/hoping for. Assuming I have the components, it should be easier/faster for me to describe using dialects a given application than using Excel. For example, lets say I want to do a discounted cash flow, calculate an internal rate of return and show me the workings in a grid. Right now, despite having an IRR and NPV functions, I would do this in Excel because it is a non-trivial ad-hoc application and I am confident that I'll achieve the result this way without spending too much time. But then I end up with a non-reusable application (ignoring highly complex MS technology to make it reusable). I would prefer to describe the application using dialects and for that process to be cheaper (in time and effort) than the Excel solution and still end up with an application where I can reuse most of my work in another situation. In fact using VID and a pre-existing function I did write an ad-hoc options-valuation program (for myself) that was faster to do in REBOL than Excel. I want more wins like this - all the time - it should be the default case. I want a quantum leap in productivity using dialects. But I'm susceptible to dreaming ridiculous things :^) Regards, Brett

 [18/21] from: brett:codeconscious at: 3-Apr-2003 17:41


> 1) Combining dialects isn't something I see as simpy a UNION of two or > more, but what we do is build up phrases, idioms, and dialect > "nesting".
I agree, and that building up is real work of real value that is leveraged by people but much less easily in programs.
> E.g. maybe there's a dialect for medical terminology. Now, > you have messages from people that contain "my doctor said I have..." > or "my doctor told me..." which could be used like a switch to jump > INTO another dialect (like INTO being used with sub-blocks). In this > case, you jump from your main messaging dialect to the medical > dialect; maybe even try a list of alternate dialects.
Yes establishing a useful context for the data is critical. If we were to parse this information in REBOL we would possibly need a system that could switch in dialect interpreters as required. Of course then we need to know *what* to switch in. Yes, perhaps our alternative dialects select themselves via relevance (validation) process.
> Where messages go, and how they are used, will also vary widely. There > will likely be cases where a message header will contain metadata that > will help tell processors what to do, or what can be done, > with them. Think how things like JINI and WSDL are used as an example.
I'm not really familiar with either of those two technologies, though I suspect wsdl is a resource discovery system. A message header is just data for a "higher up" context so I see the processing of metadata as the same issue just moved 1 level. E.g in your description above "my doctor said I have" is metadata for whatever followed but is data at the same level as whatever preceeded that phrase. Such thoughts can lead quickly to confusion as I try to refocus attention on the levels of meaning. :^)
> 2) The dialect/action combination is a many to many relationship. > We may want to replace the actions behind a dialect, but we may *also* > want to put a different dialect over basically the same set of > actions, or at least achieve the same end result (e.g. parse the data > for values, build up a record, put it in a DB).
I can certainly understand replacing the actions behind a dialect, but if we were to put a different dialect over the same set of actions would it be better to call the set of actions a library or module or api?
> 3) If you've looked at the "programming by example" paradigm, imagine > designing dialects by using example text.
Yes I've tried. Unfortunately the amazing number of unlimited possibilities is somewhat of a block. I found, for me, it was more practical to reflect on VID then try things out. Then reflect on VID again and my attempt and try more things out. But now I'd rather pick up a template to fill in - but no one seems to have one.
> PARSE itself is amazing, but imagine what we can build on top of it!
I am, thats the problem, my imagination far exceeds my ability and my current reality! Regards, Brett.

 [19/21] from: g:santilli:tiscalinet:it at: 3-Apr-2003 9:47


Hi Brett, On Thursday, April 3, 2003, 8:54:48 AM, you wrote: BH> I'm not looking for a general way to mix any two dialects, I'm looking for a BH> more general way to design dialects so that they can be easily mixed. That's why I suggested the "values" layer. Whether this is done using something like "custom types" or just objects, once you have it you just need, in one dialect, to get the values outputted by the other dialect and process them. This, as opposed to studying the parser for the other dialect and replacing anything you find in parens. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [20/21] from: brett:codeconscious at: 3-Apr-2003 18:23


> BH> I'm not looking for a general way to mix any two dialects, I'm looking
for a
> BH> more general way to design dialects so that they can be easily mixed. > That's why I suggested the "values" layer. Whether this is done
<<quoted lines omitted: 3>>
> the parser for the other dialect and replacing anything you find > in parens. :-)
?! :^) So maybe you are focussing at the values layer and I'm focussing and the language layer. I totally accept that a values layer will be part of any implementation, I used the something of the approach some time ago (.../rebkit/tmd* on ios dev), but I don't feel it is enough by itself. Now where is my discounted cash flow custom type ?! ;^) Regards, Brett.

 [21/21] from: greggirwin:mindspring at: 3-Apr-2003 13:15


Hi Brett, BH> Yes establishing a useful context for the data is critical. If we were to BH> parse this information in REBOL we would possibly need a system that could BH> "switch in" dialect interpreters as required. Of course then we need to know BH> *what* to switch in. Right, which is where REBOL saves us again. These dialects can be passed around and shared as data. Now, maybe we create a dialect-interchange dialect that various processes can use, so the header/meta part of a dialect is loaded by the main processor and that gives him the clues to look for about when to apply that dialect. I'm not sure, though, how you'd handle things like a "confidence" rating of how well something parsed versus just pass/fail. BH> I can certainly understand replacing the actions behind a dialect, but if we BH> were to put a different dialect over the same set of actions would it be BH> better to call the set of actions a library or module or api? Probably so. The dialect is just a friendly interface to some underlying functionality.
>> PARSE itself is amazing, but imagine what we can build on top of it!
BH> I am, thats the problem, my imagination far exceeds my ability and my BH> current reality! Me too. :\ -- Gregg

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted