The R3C Branch ("Chris's Rebol" or "Rebol 3 Conservative")

I don't know that anything I have is above negotiation, I suppose. I've used Rebol long enough and am generally productive with it and would prefer something resembling that language at the end of day.

I have my biases:

  • Data/messaging come first, and words without qualifying symbols be the premium currency.
  • Source should as much as possible resemble the molded representation of said source loaded.
  • Now that PARSE returns a position rather than a confirmation, I'm not sure I'd tolerate going back.

Will likely revisit these after mulling them over a bit, don't consider them to be dogmatic.

Rebol tries to straddle being a soft, human programming language against something that is more rigorous and consistent. Ren-C does move the needle more toward the latter and I consider that almost universally better, with one or two areas of reservation.

My other thoughts would relate to the meta, so I'll hold on to those (save to say, if you are going to introduce a Java dependency, then Rebol being dead might just be a mercy).

Update:

I'm not saying these are non-negotiable and it may be the form and not the substance that I object to. I know these are not necessarily behavioural facets of the language, but as we don't have a page for that, I would like to have them on record:

  • I don't like the @inert form. I have a strong preference for @name string sub-type (or just a variation of the email type).

  • I'm uncomfortable with new considerations for the /refinement form.

  • I've spotted <*> in some areas of source. I'm not sure what it means, but it looks intimidating.

  • I need to better understand the rationale behind type-of returning quoted types. My preference on the face of it would be type-of 1 be the same as type-of '''''1 with a different operator determining quotedness.

2 Likes