Dialects represent a keystone concept in the REBOL package and present a major justification for calling REBOL a messaging language.
As a concept, a Dialect is not too dissimilar from specific XML languages, though in my opinion far more accessible from user and developer perspectives.
Dialects hide in full view in REBOL, some examples include VID (Visual Interface Dialect), the rules of the Parse function, security settings, etc. As a result it is not until someone has used and absorbed REBOL for a while that they turn their thinking towards dialects and how they can use them.
Some time ago I asked the participants of the Rebol list about their use of the dialect capabilities of Rebol. Below are the lightly edited responses to my query. I hope you are inspired by what you find. You will find more dialect implementations in the projects section of REBOL page and newer dialects on rebol.org.
If you develop your own dialect, develop some techniques relating to dialects, or just want to inform me of a new link - send me a message and I'll add them to the site.
I implemented a lego-dialect. You can control a Lego-Cybermaster Robot, and write and download programs on it.
You can have a look at math-do.r.
Which shows, how to use my parser-object (Observer-Model) for implementing dialects.
My irc-protocol uses a dialect to produce irc-messages.
REBlog is a prolog-dialect for REBOL
(new version comming soon, i hope :)
One interesting point: When I started working on the lego-protocol, i just wanted to do something like "motor left on" etc. to control the robot directly. A non-dialecting sollution might look like:
lego/motors/left/power 10 lego/motors/left/start
But I decidet for dialecing:
insert lego [motor left power 10 start]
But after a while I wanted to extend the protocol to download tasks that run on the robot itself. Now I was able to allow:
insert lego [ task 0 [ motor left power 10 start ..... ] ]
And, of course, you have variables, too. This would look ugly if there were no dialecting. The reason is that it is no longer commands, what I write down, but data. Method-Invocations are more like commands, which are evaluated at invocation-time. Also they are often used to represent data-structures. (Like building a user-interface with java-awt). Dialecting allowes it to write down data more elegant and more explicit.
No grandiose claims here (TMTOWTDI), but you might find the GENERATE-DATA dialect article useful. It can be found at
- It's very nice to be able quickly to craft a mini-language for a specific problem domain.
- The effectiveness of such a mini-language depends on having a "critical mass" of processes that are enough alike to make extracting the engine worthwhile.
- Deciding on the syntax of the mini-language can be the hardest part (I punted on this and stayed at the "assembler" level rather than trying to create an entire high-level language).
- The classic trade-off between generality and speed; a custom-crafted solution is usually faster, but also more work to maintain/extend; a general solution is more flexible but not as fast.
- The biggest danger of becoming too context-dependent IMHO is the potential confusion from overloading the terms that have different meanings inside the dialect than outside, and from having unmet expectations set up by the choice of common terms with everyday "baggage".
REBOL certainly has the chops to make dialecting a more feasible practice than most languages.
Ingo runs through the process of creating his TUI dialect (Wayback machine).