Fundamental distinguishing features of Rebol

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: