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

Domains R3C
#1

Users of Ren-C are allowed--in fact very much encouraged--to create "skins" of the language that reshape it to their tastes.

The goal of the Ren-C core is merely to offer the most flexibility to those wishing to do this bending.

Christopher Ross-Gill is about as long-time a Rebol user as they come, with many opinions on the topic of Rebol semantics:

So he is particularly passionate about the semantics of his "skin", which he calls R3C.

This category is for him to document and discuss his work and findings, and to point out where Ren-C has or hasn't allowed him to achieve his goals.

#3
#4

Rebol was always very much a do it my way language. And why not? That's the point of open source. But there's also the attraction of a stable language which doesn't morph with the wind.

#5

If I have any regrets about the process I've undertaken, it's to have not made a Rebol2 compatibility layer sooner. Then I could have handed over the reins of deciding how and when to change each construct to other people, so they wouldn't blame me--which seems to have been the default.

But bygones are bygones--and so let's just think of that as how we should do it today. I'm urging Chris to start from Redbol, and then pick a-la-carte any new features he wants, one at a time.

Ideally that would give him his own lib... from which anything a script overrides can be re-fetched in the original customized form. But we should still make the un-customized Ren-C baseline lib available to pull from (newlib or lib.ren or something...maybe just call it base, and have it available regardless...so lib starts out defaulting equivalently to base, but these personal libraries would change lib...not base.)

Rebol was always very much a do it my way language.

I wonder if your interests and Chris's interests are more closely aligned than yours to mine, in terms of what the language baseline is. Your choices would be:

  • Redbol

  • My Ren-C baseline

  • R3C

  • R3G ("R3-Graham", with double-meaning of whatever adjective you like that starts with G)

But like I say, the thing is to not consider all this divergence to be bad--but good. Ren-C just needs to be adept at bending.

1 Like
#6

Ultimately I am a pragramatist. There is no other rebol language that works in the browser.

1 Like
#7

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
The Canonical List of Non-Negotiables
#8

It's just a tag I thought looked good for use with the COMPOSE feature of a skippable FILE! or TAG! that shows you which slots to compose. I think that's pretty great. If you want you can pick another tag.

(The predicate functionality is currently disabled, pending more research on how predicates will be done system-wise...)

There's definitely a lot to think through regarding this. I'll be the first to say that.

But I feel like /foo/bar being legal is feeling fairly close to non-negotiable for me. And if /foo/bar is legal, I don't want that to be a PATH! and /foo to be a REFINEMENT!.

I wish there was more experience with this. :-/

This might be something you find you appreciate more with time. Hopefully you can be happy enough by virtue of getting back #issue as a string type, and there is %file ... that's pretty good coverage.

It was historically the case that quoted values returned a distinct type, so this isn't a new behavior.

rebol2>> (type? first [x])
== word!  ; new plan would be @[word]

rebol2>> (type? first ['x])
== lit-word!   ; new plan would be @['word]

I would counter that I am skeptical of the use cases for such an indiscriminate "I don't care if it's quoted or not" test. I've previously pointed out that if the default is for dialects to treat quoted items the same as non, there is no incentive for users to be clean about stripping quotes off...and things will become a mess, making it hard to reclaim quoting for real purposes later.

I just don't see it coming up that you want to ignore how many quote levels there are and treating everything the same regardless. The cases where this would make sense seem covered by NOQUOTE.

THEN and ELSE are Essential
#9

Hopefully you're warming up a bit to the generalized paths and tuples, and how they can be COMPOSE'd with pieces spliced, etc. I mentioned there was a long way to go on mechanics, but progress has proceeded one hard-won fight at a time...

Example: Tonight while firming up the idea that BLANK! is matched literally in PARSE for arrays, I found it instantly applicable to a significant step ahead in processing refinement-y things:

>> refinement-rule: [subparse path! [_ word!]]

>> parse [/foo] [refinement-rule]
== foo

SUBPARSE is basically like "INTO AHEAD", so it parses into the rule product of its first argument. (The first rule doesn't have to be a pattern on the input series, it could be a GROUP! that synthesizes any arbitrary series or sequence.)

So recall that:

>> as block! /foo
== [_ foo]

Also, that BLOCK! rules evaluate to the last matched thing.

NewPath has come, and seen, and is now conquering. :crossed_swords: What about composing paths where a slash before an array spreads it out?

>> parse 'a/[b c]/d//[e f] [collect some [keep [spread [_ any-array!] | <any>]]]
== [a [b c] d e f]

When you see /foo and foo/ fitting into this general mechanism it makes it worth figuring out how to negotiate their new nature.

1 Like