Rye Language (?)

So here's another language which doesn't look very Rebol-like but is by Refaktor who is Rebol-inspired:

Notably, it is written in Go. (I've mentioned that increasingly I have been leaning toward modeling things after Go for a runtime. It would of course be easier to do by actually writing the runtime in Go, vs. trying to reproduce the effect in low-level C code. :frowning: )

It's probably very interesting, but I don't really feel like looking at it right at this moment. Maybe someone else can study it and explain what it's about in a reply here.

The main carry-away I'll take for the moment is the 1:1 language-designer:user ratio that Rebol users are inevitably converging toward.


This Rye language also is inspired by Rebol.
An odd thing that strikes me is that "inspired by" often means that a lot of Rebol is recognisable, and some changes have been made to not resemble Rebol too much, resulting in exchanging good choices by worse. In this case interchange squared brackets with horrible curly's.

I just had an interesting discussion with the creator of Rye about how they implement binding. It’s a little hard to tell, but it sounds like Rye uses basically the same system as R does, with some additional restrictions to keep it more tractable. It’s certainly less flexible about it than most Rebol languages are.

1 Like

Glad to hear there's a move to the environment/inheritance idea. Suggests moving in a direction of greater restraint with binding is a recognized need...at least somewhere else.

Stopping to briefly look over the language further now, I don't really see much Rebol in it. Can't find any dialects, e.g. no PARSE equivalent. No COMPOSE?

It's piping-focused, in a way I can hardly read (English-like readability is supposed to be a goal in Rebol, that's clearly not a goal in Rye). The idea of piping things seems better addressed to me by a construct like:

>> chain [
       [1 2 3]
       reverse <$>
       map-each x <$> [x * 10]
== [30 20 10]

(Choice of <$> here is arbitrary and something you should be able to override.)

It could be useful, so I should probably rename what's called CHAIN today as CHAINER since it produces a function. Then CHAIN can be used for one-offs.

But I think people who find data piping is their true quest in programming would go for paradigms that are more mature at that.