Fundamental distinguishing features of Rebol

Usage Philosophy
1

Perhaps foolishly, I offered to give a talk at my local Functional Programming meetup next month. Given my recent interests, I’m thinking of giving an intro to Rebol and its basic concepts.

So that’s gotten me thinking: what are the basic concepts of Rebol as a programming paradigm, which distinguish it from all others? Here’s what I’ve come up with so far:

  • Everything is a datatype: Rebol was built for networking. This means you should be able to take any value, serialise it in a human-readable way, and parse it back into a value. This means a lot of built-in datatypes for useful concepts.

  • Data is code: Everything starts out its life as data. If you want, you can evaluate it in some way to get a result. Naturally, you can evaluate it using any rules you want, which gives you dialecting as a corollary.

    (It’s worth noting that this is the converse of Lisp’s famous maxim, ‘code is data’.)

  • Binding: Word values are associated with their storage. This can be arbitrarily manipulated by the programmer, leading to definitional scoping.

  • More generally, I might summarise all the above points as natural consequences of computing with evaluation: the fundamental operation of Rebol is taking values and extracting some kind of result from them. This necessitates the other points above: a rich set of datatypes to store both the original value and the result, the ability to treat those datatypes as code which can be evaluated, and a way to look up references during the evaluation process.

Does this all seem reasonable? Have I missed anything?

3 Likes
2

Cool! I gave a talk to a small group at a functional programming group in Philadelphia in 2019. I'm afraid I don't have any useful slides, as it was mostly an off-the-cuff demo.

I did have a slide that quoted Greenspun's Tenth Rule :slight_smile:

I used the web console, which you can Ctrl+ and zoom up big to type in demo code, and it has undo/redo/Shift-Enter to edit multiline code.

The new binding should be mainline in time for your talk!

One of its most successful concepts--the one that inspired JSON--is the "it's okay to imply semantics" anti-XML worldview:

Writing interpreted Dialects is truly at the heart of the value proposition. But it hasn't historically been "taught" as a first principle (instead focusing misguidedly on 'things you can do in one line of code' out of the box).

One of my first Rebol experiments was the implementation of USCII. When I revisited the project many years later, it was an example of "seeing the light":

UPARSE is the most evolved dialect in existence, and breaking new ground by proving it can do what it does as usermode code. I think a good demo would be to contrast it with how other languages do parser combinators... the leverage of parts with tags like <here> and <end>, with GROUP!s for code, and string literals or quoted values to match. No one's really put together that comparative study yet... because parser combinators weren't really well-known around the time of Rebol's release (and most Rebol people won't use Haskell or similar, so they act like RegExp is the only competition)

The "Amish Programming" angle... that the deep dependency footprint be small (including compiler, libraries, make tools)... is core to the mission, and can't really be fully separated from the language concepts.

3 Likes
3

Ooh, this is great! I’d suggest making this more prominent on the repository, because I had absolutely no idea it existed. (I’ve been using the command-line interface instead.)

Though, that being said, if I do a live demo I’ll probably end up using Red — not because it’s great as a language (it isn’t), but because it has a nice GUI with View dialect support, and it’s closer to baseline Rebol than Ren-C is.

That’s a good one! More related to data transfer than programming, but then data transfer is a pretty core part of Rebol in any case.

I don’t see the relation of that with dialecting, though… unless I’ve accidentally grouped together two separate paragraphs?

Also, how does one treat dialecting as a first principle? As someone who hasn’t actually used Rebol very much, I’m not sure I see how that’s possible.

As someone who loves parser combinators, I feel that UPARSE is actually really similar. I’ve suggested before that dialects are Rebol’s answer to monads, and it does feel like a similar style to what I’d do in Haskell.

Another good one, thanks! Though I’m not sure I agree with ‘can’t be fully separated from the language’… I see no contradiction in writing a bloated Rebol implementation, even if that would be a stupid thing to do.

4

A post was merged into an existing topic: "On Building Ren-C With C++ Compilers"

5

It's a spectrum. From his example on the blog, I would say this is "not dialected":

customer: [
    name:  "Bob Smith"
    email: bob@example.com
    site:  http://www.example.com/bob
    age:   27
    phone: #555-1212
    city: "Ukiah"
]

And then I would say this transformation he gave I would call "dialected":

[
    "Bob Smith"
    bob@example.com 
    http://www.example.com
    "Ukiah"
    [age 27 phone #555-1212]
]

Dialecting is that reliance on the types and the ordering to cue you into the semantics. Whether you use that to represent code, data, or a mixture isn't so important. It doesn't suddenly go from not being a dialect to being a dialect if I throw a GROUP! in and say that runs code at some point.

[
    "Bob Smith"
    bob@example.com 
    http://www.example.com
    "Ukiah"
    [age 27 phone #555-1212]
    (
         all [
             date.day = 21
             date.month = 4
          ][
              send-email "Happy Birthday $(name)"    
          ] 
    )  ; if this code is run daily...is it a dialect now?
]

By having early exercises iterate on a problem, where the solution the user is guided toward as the exercises go on is the development of a dialect to solve that problem.

Giving people the Rebol language and VID + PARSE as the two showcase dialects--it just feels like using a language, because they're just handed down to you and there's no code for them.

But writing non-trivial dialects that build on the existing parts is hard. My attempt to do something relatively "simple"--e.g. tailor the language for writing Whitespace Interpreters--brings up all kinds of challenges. As we push on binding, we're pushing on some of the biggest pain points.

I'd like to see tutorials that walk people through something like that, instead of "here's how to use a thing that builds forms".

It constrains the space of acceptable ways to solve problems in the language. So there are features and behaviors you won't see in the language if they can't fit into a certain je ne sais quoi of how it can track in an implementation.

You can write a bloated implementation of the language spec that comes out as the product of that thinking. But the bloated implementation couldn't have driven the mentality that produced that spec, and features that depend on the bloat would be disowned as "non-Rebol-y".

It's very much a Zen and The Art of Motorcycle Maintenance thing. :motorcycle:

Guess it's good for you to get experience with it, so long as when you hit something nonsensical you know where to ask about "is there a better answer for that?" :slight_smile:

6

I really love this definition, thanks! (Hope you don’t mind if I steal it for my talk…)

I’d love this. It reminds me a lot of how Lisp tutorials introduce macros — not as special magical predefined things, but as a useful tool for solving problems, which you can and should be writing yourself.

That being said, as you note, writing non-trivial dialects is much harder than writing macros. For (at least unhygienic) macros, it’s simply a matter of transforming one data structure into another. But for dialects, you also need to take care of evaluation, which makes it more difficult.

Oh, I know that Red has missed out on a lot of good approaches which are present in Ren-C. (Something which, unaccountably, their documentation fails to mention…) It’s purely a matter of which implementation looks nicest in a quick demo. Personally, I think the most compelling of the ‘standard’ dialects is VID, so in a demo to non-Rebolers I’d like to use an implementation which supports that. By contrast, Ren-C’s changes are great, but their need isn’t so immediately obvious in a demo.

2 Likes
7

I'll mention the discussion of "what makes Rebol different" and "how do you explain the value" has happened a fair bit...it's hard because it's weird, but people try. Here's an old post I've cited from DocKimbel:

Rebol's Target Market: Newbies, Experts, or Other? - #3 by hostilefork

Of course the devil's in the details of these examples with things like binding. But you might find interesting thoughts in those threads if you dig around.

I'm the wet blanket who says nothing is that notable about it if it doesn't work, so I couldn't really demo what I find fundamental about it in Red/Rebol2/R3-Alpha, because they're just missing too much.

8

It all feels depressingly familiar to me. The thing about Rebol is that it’s a different programming paradigm… on a par with the major language families of ALGOL-like, Lisp-like, ML-like, etc. And people are strongly resistant to learning new paradigms, because it requires them to learn a new way of thinking and problem-solving.

I see this problem in Haskell all the time. Newcomers often have a very hard time dealing with the nature of the language: ‘What do you mean, I can’t do IO everywhere? Monads are complicated and stupid! This language is weird!’ If they persist, it eventually ‘clicks’ in their brain… but many people give up before that point, and just go back to using Python or Java or whatever.

(It works the other way round, too. I’ve seen a few people who learnt Haskell as their first programming language, and they find Python and Java horribly difficult and counterintuitive to use.)

1 Like
10

Reflecting further on this statement, I think it’s true not just of dialects as such, but of the whole Rebol language more broadly. Rebol code is very free-form: a lot of the time, it’s simply a list of values without much further structure. Thus, it’s possible for dialected and regular code to ‘feel’ very similar with minimal effort — both can appear reasonably free-form, with only the interpretation rules changing. In both cases, you are reliant on the types and ordering to understand the semantics.

11

I also pretty much only use the web console on my PC though my other stuff runs in GitHub actions etc.

True we don't have a GUI but you can link to JavaScript for some flashy stuff. I have a demo that brings up a JS chess game. But I wish it were easier and we didn't have to rely on Red/view for those things in the shell.

12

Shortly after finding Rebol (circa 2008), I wrote "Computer Languages as Artistic Medium"

"What does it mean for a language to be a truly new medium, as opposed to a variation on a theme? That's rather debatable. A language I have been looking at lately is called Rebol, and its advocates believe it to be a unique new medium. This is despite the fact that on first glance, it is an incredibly small box of crayons with a special color or two added, and lots of "ugly" colors taken out."

"Yet to them it's also not like any other language that already exists. So if it were a product being introduced at Toys R Us, it wouldn't be a LEGO set with square plug-knobs instead of round ones....nor would it be finger paint that was merely a little stickier or a little easier to clean up. Beyond it's new-ness, its champions say it also has the property of good-ness: a hopeful new way to build fun art."

I link to "What is Rebol?" on rebol.com, and do note how the dependency control and smallness of the system is very much forefront.

For reasons you may be gathering, I really want Ren-C to be under the radar until the hammering through of things is done. Too much is in flux. I don't want it to be on hackernews or anything like that. Raising the bar to participation is deliberate... though I'm glad you found it! :slight_smile:

2 Likes
13

There’s a trade-off, though… more users can also mean that there’s more people to interrogate the design, suggest new ideas, and help with the implementation. I’d suggest that Ren-C be slowly made more accessible as the design grows slowly more stable. It already seems a lot less in-flux than it was a few years ago.

14

A post was merged into an existing topic: Racket's Language-Oriented Programming

15

A post was split to a new topic: Feb 2024 Talk, Functional Programming Sydney

16

I think an important point I hadn't articulated before is this:

17

Just to add to this thread, the fundamental distinguishing feature of Ren-C...

1 Like