I think @Gregg Irwin works on it?

I haven’t used it, but I’ve been reading about for some time — looks very interesting.

I think development slowed down a couple of years ago due to funding reasons.

I'm on Team Red, so yes I use it. Development has slowed, for a couple reasons, but we're still kicking. The big limitations today are pending I/O redesign, so that branch can be merged, and still being 32-bit, which means installing 32-bit libs on many Linux distros and not being able to run on new MacOS at all. Older MacOS is still fine.

My bias is heavy, of course, but I'm happy to answer any questions. I used Rebol before Red, and these langs make it really hard to go back to others after you get used to them. They do suffer some of The Lisp Curse, where people roll a lot of their own stuff, and there's not a full ecosystem yet. If nothing else, they stretch your mind and let you think in new ways.

which resources provide the best overview of the language?

github.com/red/docs is reference material, and covers the GUI, parse, reactivity, datatypes, and some other aspects pretty well. The best overview is still, ironically rebol.com/docs/core23/rebolcore.html Red is a direct descendant of Rebol, and that was written by its designer, Carl Sassenrath. red-by-example.org has specific examples when you need help. And there is help built into the consoles while you're actively working. We're active on Gitter, which is the best place to chat.

One thing that the old docs don't cover at all, because Rebol didn't have it, is the Red/System (R/S) dialect. It's a C level systems language. Red compiles to R/S, which then compiles to machine code (no external compiler needed), and R/S is, itself, a dialect of Red, so it takes the whole metacircular idea to another level. We describe Red as "A full stack language, from metal to meta". Other key aspects are that it's small, and you can build standalone programs with it. Easy to get started, as it's just a single EXE, no install required. Well, there are 3 now, because the text and GUI consoles and toolchain are separate.

The closest I can think of is enso.org

Yeah I came here to say Enso.

Also wanted to note: I assume you meant “statically”, and it got autocorrected to “statistically”. But I really, really like the idea of a statistically-typed language! Maybe you could declare variables like (30% int, 70% string) myVar .

not the same but I've seen some tools that allow you to express confidence intervals and they propagate through the calculations, they even are displayed in charts, can't remember the tool

Found it docs.causal.app/formulas/values-with-uncertainty

Ranges and the Monte Carlo method

When variables are in the format of a range (e.g. 0 to 100, uniform(0,100), a

is run to estimate the possible outcomes of an uncertain event. Monte Carlo will randomly pick a value from the distribution and compute the whole model as if it were that random constant value. This process is repeated multiple times to generate distributions for the output variables.

The use of the simulation allows Causal to perform computations using values with uncertainty that are not possible without it. Due to this method of handling uncertainty, you may notice that the range of the cell and the value are not the numbers you inputted or would expect, but only by a trivial amount.

yep, typo, thanks 👍 . You could have an int or string type in a statically typed lang: ‘Either[Int, String]’ 😄 , the percent can’t be static since it depends on runtime information about the distribution on data.

haha where did that emoji come from :see-it:

i gotchyou

I don't get this, like 90% of what Lu Wilson does 😄 But I gather that's at least partly the point? ♥

What is a LINE?

a visualised LINE of memory

Sorry, this is probably obvious but I don't know what a line of memory is

Can you help me out? 🙂

found a few more possibly valid lines 👀

Ok this might be a bit of a stretch (what IS a LINE??) but there's some overlap with how tables work (the free form ones that you can draw on a paper or a spreadsheet). Tables are basically a bunch of interleaving lines thrown together on a surface.

Not sure if these are related (again), but here's some more LINES I've been drawing on tables recently. I posted a bit about it 💬 #thinking-together@2023-12-14T10:04:32.780Z.

Lu Wilson This might interest you: I've found that LINES of similar width (measure by the green and red rectangle's width) always block each other – or at least they never overlap.

oh *of similar width and direction

@Rafi Khan sure thing :)

data is stored in our computers. it's stored in "memory" so that it can be retrieved, and edited, and moved, and manipulated, etc.

that memory is often stored in an arrangement of a "line". for example, in an array, or a stack, or a heap, a register, RAM, list, etc...

sometimes we might want to "visualise" this line of memory, so that a person can "see it". maybe to understand it better, maybe to debug a problem, maybe to learn.

so... how do we visualise it? what's the best way? I've been collecting up this list of visualised LINEs to learn about what's already been done.

Kartik Agaram this explanation might help you too!

@Prabhanshu Gupta yes! spreadsheets visualise the line(s) really well. that's what started me on this project. programming environments that arrange memory in a GRID already visualise it really well (eg: spatial computing in cellpond), so my research question is: can we bring this strength to one-dimensional memory as well? the answer might be no and that's ok

Yeah I think so? I've been thinking of 1D ranges as just a degenerate case of 2D tables and it all works out the same way (wrt visual LINES). I'm curious about what other kinds of 1D visualisations you're thinking. The examples you've collected seem to cover a wide variety already.

yeah i find it interesting how there doesn't seem to be a universally agreed way of representing it visually. i don't think it's because of domain-specific differences. to me, it suggests that it hasn't been figured out yet

In some of the examples I'm squinting and it seems like the lines would apply to any representation, not just drawing out memory (that's how I made the jump to tables).

I'm guessing since memory is sequential physically, drawing a line to talk about it would come naturally: "follow the line from left to right, that's how the memory is laid out."

could you expand on what you mean by "apply to any representation"?

So if you want to visualise a list of Names, putting them in a LINE makes sense because you can follow it from top to bottom. If there is some sequence applied to it (let's say alphabetical), the sequencing is inferred by which name comes up first in the LINE. On top of this, you can put a "label" at the start (at the green rectangle) to give the line a name.

This is not representing physical memory, it's some abstract list of names.

I'm really liking how LINES sounds when I say it.

This is not representing physical memory

i would challenge that :) it's a 'representation', not a photo, so it doesn't need to be accurate. I'm not interested in accurately depicting memory - i want to visualise it in a helpful way, even if that involves lies

i want to visualise it in a helpful way, even if that involves lies

Haha I see. That is an interesting problem.

it's a 'representation', not a photo

wdym? I think I might've misunderstood what you mean by representing memory.

wdym? I think I might've misunderstood what you mean by memory.

when we're coding, we often try to imagine what the memory in our program is doing.

"ok so the array looks like this... then it changes to this.... oh wait i can see the bug"

"ok so these three variables are in the local heap with these values... and i read from this one and... oh wait I can see I'm reading from the wrong one"

"ok so the buffer for the image looks like this... and I'm getting the coordinates from the index like this... and... oh wait i can see an off-by-one error"

it's helpful to visualise the memory in our program. maybe we visualise it in our head, or on a drawing, or maybe our tooling visualises it for us.

in all of these cases, the visualised representation is a highly abstracted view of that memory, because its purpose is to be helpful to a person - to help us reason about our program.

if they were accurate portrayals of the memory in our program/computer, then they wouldn't be helpful at all. they would be completely obfuscated with strange symbols and numbers, with lots of boilerplate not intended for humans. the compiler's (or runtime's) optimisations would further disguise the behaviour of the program, and all-in-all, it would be a confusing mess. the "true-est" representation would be seeing the binary bits in pure ones and zeros (maybe), and that's clearly not helpful.

so I'm not interested in visualising an accurate depiction - i want to visualise a helpful representation

hope that explanation helps!

That makes sense, thanks! I guess what I'm coming at is lines and tables seem like a solid starting point 😛

Ok, this is a lot less Dadaist than I first thought.

I'd like to suggest a new acronym: IANAL. Is Always Not A LINE. We have plenty of examples, now need some IANAL counter examples.

I think that Dali painting is a counter example, for example. Thoughts everyone?

The best way to visualize a LINE might not always be a line. For example, merveilles.town/@akkartik/111356122874372588 uses a few different methods, particularly time.

bit of a naughty sounding acronym perhaps Kartik Agaram :satisfied:

maybe A-LINE (using alpha privative) or N-LINE for Never a LINE?

The joke is it stands for I Am Not A Lawyer 🙂

oh! learnt something new!