Hi all! I first got interested in Rebol when I discovered Red a few years ago, and near-instantly fell in love with the language and its aims. Although I never did find a use for it, I continued to monitor its development peripherally. It was only a month or two ago when I started to investigate the qualities of Rebol as a programming language, and discovered a rich and fascinating design: I’d never seen features like definitional scoping before! This led me inevitably to Ren-C, as a project which has explored the Rebol design space most thoroughly.
Outside Rebol, I generally write personal projects in Haskell — plus, reluctantly, C++ and JS if required. By day I’m a physics student, most recently writing a raytracing optics simulator in MATLAB (which I’ve come to loathe). Within the field of computer science, I tend to most enjoy programming language design and development.
Hi Brad, welcome! Glad you found the forum--it's not advertised much, and Ren-C keeps a low profile. (It's enough trouble supporting just a couple of customers in the face of the desire to keep evolving the language!) So only a particular kind of person fits...seems you fit!
I am a big fan of Haskell, and if I didn't think that paradigm was already saturated I'd probably be more involved there. Here there's some fun in being able to still invent at the level of undiscovered fundamentals.
Hopefully you've seen "A Justification of Generalized Isotopes", as that is one of the biggest outcomes of that exploration. I always disliked the /ONLY refinement, and it took a long while to get to the right infrastructure to see how a lot of different problems could be seen as instances of the same problem. "There needs to be a quoting level of negative one" took a lot of steps to get to.
Binding remains the biggest open topic for me, and I'm glad you want to talk about it!
But Red (and historical Rebol) have always tended to code up simple cases, then call it a day and move on. They don't throw hardballs, and when you do so, the lack of composability becomes obvious. I'm trying to maintain the spirit of the design while still attacking those bigger issues.
The ML family is well-developed, but I don’t think it’s quite ‘saturated’ yet. To take just one example, Lean 4 is doing a lot of innovative stuff to make pure functional programming a lot more approachable.
Oh yes — that was one of the most interesting and mind-bending ideas I’ve seen in a while, and the post which got me hooked by Ren-C. I’m excited to see where this goes!
Incidentally, a question on this — what precisely does ‘quoting level’ mean? I’m familiar with how quoting works in Lisp, but it sounds like quoting in Ren-C works very differently.
I have a little bit of an ulterior motive for this… for about a year now I’ve been playing with the idea of a new kind of spreadsheet, and binding has recently become a sticking point there too. So recently I’ve been thinking about this a lot.
The issue is: often, you want to create a new column in a table by doing computations on other columns. To do that, you want to be able to easily refer to those other columns. So you want to be able to take a piece of code, and run it in such a way that the identifiers in it refer to columns of a table rather than ordinary variables… sounds familiar? (This is also how I got interested in R and its data-masking.)
To my mind, the "real" answers to most problems of representation involve getting away from text.
Graph representations where you can point at things and go "I mean that" and be able to say that via a UUID that is robust across renamings and reorganization is something that should have happened a long time ago.
Since that thread doesn’t seem to let me reply, let me ask here instead: why do quote/unquote exist when meta/unmeta do the same thing while handling more cases?
Insofar as I understand it, spreadsheets already are implemented like this (which is why you can copy/paste things in Excel without breaking formula references). There’s also Unison, which takes it even further.
In any case, my interests are less ambitious: I simply want a spreadsheet with proper data structures, and with a programming language which hasn’t remained unchanged since 1983. Originally a central part of this was going to be static typechecking and inference, but I’m slowly moving away from that idea. My current train of thought is that homoiconicity might be incredibly powerful in a spreadsheet context, but only if I can figure out some kind of coherent design for it…!
Oh, so that’s your work! I do recall having seen this video before. (Personally, I don’t love structural editing; I’ve come to feel that its disadvantages outweigh its advantages. But that’s just my opinion.)
Answered. I've bumped up your Discourse user-level so you should be able to reply to Internals posts...
Most likely just because you haven't used a good modeless structured editor, which lets you leave arbitrary blobs of text around as TBDs that you can upgrade to hardened links.
Historically, structured editors have gotten a bad rap for being modal. Being locked in situations like you've entered an IF and you have to type in a condition that's a valid boolean expression before you can move on--that sort of thing.
A painful example from my childhood:
If your opinion of structured editors is formed by things that work like this (and many people's are), I would understand being skeptical. They do not feel much like a "canvas" on which you are coding freely.
When you can code freely and the system is assisting you in translating that into structure if and when you want to, then it is pure benefit.
// Right now I am trying to go around and study uses of the word in
// and it's very frustrating, because it's such a common word...yet I
// want to use it, but it gets lost in the noise. Intentional Programming
// allowed you to not just point to the right IN and then search by underlying
// UUID, but you could also "intentionalize comments", much how I'm
// "intentionalizing" references here. I could write a Rebol program and
// talk about IN with a UUID, and then in the comments of the C++
// implementing it I could point at that specific intent. Rename it, it changes.
// Want to study the instances, you can find them with accuracy.
// Comments reflow with word wrap correctly of course because the // are
// just rendering artifacts, but not the best option, because there are many
// other ways to show the paragraphs (in the margins, connected directly
// to the exact AST points they want to document, showable by demand...)
We simply need more powerful tools for storing our hardened software intent, and text alone does not cut it. Being able to point at things and say "I mean that", and have "that" persist, is critical. And there are all kinds of things you can do with keeping a legacy name alive for some deprecation period... so it works for rendering with a squiggle but not lookup, but when the new name is committed it doesn't break anything. If you're afraid to rename things so they are more clear because you might break something, that's the tip of the iceberg of what it means to be crippled by fear of improvement...
Hmm, that’s not something I’ve ever heard of, and none of the modal editors I’ve used have worked this way.
I tend to dislike structural editing for two main reasons:
Syntax is not the hard part of programming. At least for me, it’s rare that I run into a syntax error, and they’re usually easy to fix. What’s more important for me is making editing as easy as possible, so there’s less friction when trying to solve problems.
Related to this, I’ve yet to find a structural editing UI which isn’t horrendously clunky to use. To some extent that’s sort of the whole point: it restricts what you can do with your code. Besides, navigating a cursor around a tree is inherently less intuitive than navigating around a string.
A final point is that text is everywhere, and very easy to work with. It’s easy to create and use generic tools like grep or text editors, which work for all text files; less so if you have some complicated structural format requiring specialised parsing to work with. But then there are some structural editors which do work with plain-text, so that’s not much of an argument.
This is an excellent point, but I don’t think it requires structural editing to implement — what seems to be more important is having some sort of live, introspectable, programming environment. For examples, look at Glamorous Toolkit or Unison. Neither of these use structural editing, but they both have the same sorts of capabilities you mention.
