What's The Scoop On REBOL?

muggs asks: "After reading this article in Byte, I'd like to hear people's experiences and opinions about REBOL." The language's creator, Carl Sassenrath, describes REBOL (Relative Expression-Based Object Language) as "a highly dynamic, polymorphic, reflective, context-dependent, symbolic, functional language...a powerful tool that provides great productive leverage." How well does it live up to this description?

Quick summary of the language...

[emmons]

It's not very C-like; if I had to pick a language it _is_ like, it'd be Forth, but with the ability to have syntax. Not at all unpleasant.

Anyhow, one interesting result of the Forth-like nature is that there are a huge number of datatypes which are not possible in other languages; for example, URLs are actually formal datatypes, not just another string (a malformed URL is a compile-time error).

They've obviously learned from Perl and Python otherwise; it's a nicely dynamic language which seems to be error-tolerant, and has quick, easy syntax for most needs.

I'm reasonably happy with it. It doesn't look as _nice_ as Python, but at least its braces and brackets have a purpose. It's not nearly as messy as perl can get, either.

I like it.

[Any_User]

It seems like a simple to use language for prototyping quickly. Maybe to get a program laid out before you start to code it up and optimize it down in C++.

Re:Quick summary of the language...

[Ian Bicking]

To me it looks very Logo-like. Using [] for lists and blocks of code is from Logo, for instance, as is the parsing that uses the arity of a function. I don't know REBOL well enough to give a real example, but in Logo you might have something like:

penup setxy 100 200 pendown

Which parses as (in a C-like syntax):

penup(); setxy(100, 200); pendown();

It knows that penup takes no arguments, so setxy must be a new statement, and so on. This avoids a lot of the parenthesis that exist in Lisp code (which is, of course, closely related to Logo).

I don't know what the semantics of REBOL are like -- I get the impression this might be more similar to Forth in some ways.

Re:Quick summary of the language...

[Kaufmann]

Actually, REBOL is much more like a little Common Lisp subset with different syntax. It's very list (they call it "block") oriented, has dynamic typing with a lot of predefined types, and some nice functional features, although it hides them well for the benefit of the imperative freaks. (I can't see the similarity to Forth; first of all, REBOL's not stack-based...)

It's not bad at all...

[tgv]

I have written a few small applications in REBOL to index web sites and it was quite easy to do. To achieve the same thing in e.g. C/C++ would have taken much, much more time. The language has some really useful built-in functions for processing urls and html documents. This, together with features such as list processing and simple string manipulation functions, make it a very powerful (scripting) language for certain tasks (such as indexing web sites or maintaining mailing lists, etc). In my opinion, it is much more powerful than e.g. Perl. The syntax and semantics of the language are also quite neat and better thought out than it might seem at first sight (IMHO), although it takes some getting used to. I had some initial problems with the "by reference" mechanism. However, it is not your ideal language for all uses. I found file management somewhat problematic: files are apparently maintained in working memory until you close them, which caused massive swapping in my indexing application as soon as the file size grew over 100Mb... There are ways to overcome this, though, but it's not the most elegant thing I ever saw. Conclusion: check it out, it may have something that you might need or never thought possible in a language. Theo

Re:Quick summary of the language...

[Kaufmann]

Well, I know all that (and yes, I have programmed in REBOL a bit). My point concerned semantics (as apparent to the user), not syntax:

Forth programming relies on the concept of computing as pushing and popping values on the stack (1 2 + means "push 1 on the stack, push 2 on the stack, pop them both into hidden registers, have the ALU add them, push the result from the result register into the stack").

Whereas in REBOL, non-continuation-based Lisps, etc. it's mostly an implementation detail ((+ 1 2) could mean the exact same thing - hell, I myself have implemented a little linear Lisp that compiled to asm for an old stack machine -, or it could mean "put 1 and 2 into the i1 and i2 registers, look up the address of + in a symbol table, jump to that address", or even just "let k be a closure such that k x = x + 1; then the result is k 2").

Re:Scripting V. Nonscripting?

[PD]

You can write a game in any language. If you're thinking of a graphical game, sure, you can write one of those too.

Example: check out Python's binding to the Qt library. Python will bind to other things too, like OpenGL. The main deal will be the speed. If you don't need it, Python's great. Otherwise use a compiled language.

questions to ask

[q000921]

Is it free and open source? If not, you risk investing a lot of time and effort in something that may go away when the company disappears.

Is it well designed? Proven? Can standard tools (emacs, etc.) cope with the syntax? Too much flexibility in defining and extending the syntax can be disadvantageous for languages, in particular if you expect to have multiple programmers working on a project.

Are there available alternatives? There are zillions of nice little scripting languages for all sorts of purposes. Many of them have extensive tool support. Just some that come to mind are Perl, Python, PHP, Lua, Scheme, Pike, Tcl/Tk, JavaScript, VBScript, and Visual Basic.

Altogether, I'm doubtful that the world needs another scripting language, in particular one that seems to allow tricky syntactic redefinitions and appears to be proprietary as well.