Boron Language

Hi, thanks for speaking up...

I'd certainly be interested if you could post some code snippets where you feel it demonstrates the features of the language--any notable design deviations.

I remember Ultima IV. Played it on the C64. :slight_smile:

Ren-C uses the "UTF8-Everywhere" philosophy:

Realistically Migrating Rebol to "UTF8 Everywhere"

R3-Alpha had gone ahead with the idea of ISSUE! being read-only, so I just merged ISSUE! and CHAR! together as one immutable type. If the UTF-8 data for an ISSUECHAR! (tentative rename: TOKEN!) is small enough to fit in a cell, that's where it lives.

>> first "abcd"
== #a  ; an ISSUECHAR! that fits in a cell

Ren-C unified mechanics behind PATH! and TUPLE!, making both read-only. A BLANK! (similar to NONE! but represented as _) will be invisible when rendered in a path. This unified REFINEMENT! with PATH! as /a is just a path representation of the array [_ a].

These representations are compressed by means of every series type having a "flavor byte" (kind of like cells having a type byte in them). If a PATH! points to a series that's a "spelling" (e.g. the backing store for a WORD!) then it knows it's either /a or a/, and it only needs a bit to resolve which.

PATH! and TUPLE! compression, explained

I wouldn't say that I'm fully uninterested in such things. But my concerns regarding Redbol languages really revolve around their fitness for purpose.

Right now the great unknown remains binding. One recent advancement was the so-called Sea of Words... a firm decision that the mere incantation of a WORD! did not allocate a variable. This decision has brought more control to the problem, but many questions remain.

Rebol And Scopes: Well, Why Not?

2 Likes