"Arturo is a modern programming language, vaguely inspired by various other ones - including but not limited to Rebol, Forth, Ruby, Haskell, D, SmallTalk, Tcl and Lisp."
1 Like
I'd seen that when it showed up on reddit. Not really sure what to make of it.
1 Like
Arturo author here 
Since the language is rather new and Rebol-inspired (although by no means a Rebol derivative or compatible with any version), I would really like to hear your feedback.
Ideas / suggestions / contributions / anything are more than 100% welcome!
2 Likes
Hello Yanis,
I must say, not bad for a one man project. (I should translate that 'not bad' to 'well done').
There is a lot of similarity with Rebol. (In the end all programming languages will develop looking more like Rebol aren't they?)
So why the need to develop yet another new programming language, other than the fact that you must have learned very much in the process by just doing it?
Hope you will have a lot of followers and contributors, because there are too many talents going to waste in the giant populations of the top ten languages.
Best,
iArnold
Arnold, Hi!
I appreciate your comment a lot.
And you sure do have a point - I'm not pretending I have the solution to a problem than nobody else thought of.
Basically this is the way the story goes: I've been programming since I was a kid, back in 1994, and I've always had a deep interest not only in programming but also in the things many could probably find boring: programming languages, compilers, kernels and chess engines.
Guess what, 26 years (and a weird choice of deciding to study... medicine) later, I'm still interested in the very same things lol - and have designed at some point all of these in different languages and different implementations.
Although my main "business" is publishing and mac applications, I still keep coming back to what I really love. And although it doesn't pay the bills by itself, it's surely very rewarding.
This is how the idea of Arturo came up (aside from being my little pet Emperor scorpion that is):
to make something that I myself will use as an easier do-it-all scripting language, you know... automation scripts, templating, latex generation and perhaps help me a bit in the packaging of webview-based applications (think of Electron, but something far more manageable and without having to deal with Node.js and the likes).
As to what this language would look like, believe me, I've drawn numerous (read: LOTS) sketches throughout the years. Adding, removing, re-thinking (and again rethinking things over). And that's pretty much how the language has been shaped
Basically, the main ideas behind Arturo are:
-
Simple, flexible syntax (hence the REBOL inspiration; perhaps it's the best least-known language out there - not that I don't see why...)
-
No OOP, nor anything overly bloated like that
-
Ability to create whatever DSL you want easily
-
Easy access to functional programming
-
Keep the easy'and'readable part of REBOL but still allow for shorter, more symbolic syntax if needed (there's already a lot of such syntactic sugar in Arturo). I'm not saying it has to resemble BF, but I definitely appreciate lots of relevant features of Ruby or Haskell.
-
Be fully independent, no install 1-2-3 in order to get something working (btw, although I've obviously written my share of Rebol/Red code, I've never managed so far to get them working on my Catalina 64-bit MacOS - Docker-based aside)
-
Batteries-included philosophy (I hate to have to import one million different libraries only to do something simple and also remember what they are called. Most core functions should already be included.) Also, size doesn't matter. (not meaning that I'm willing to end up with a 10MB binary)
-
Ambitious, but oh well: go full self-hosted. (Basically, my next step is to write an Arturo to Nim transpiler in... Arturo)
Whether Arturo and me will make it or fade into history, remains to be seen.
Sure thing is the journey has been more than awesome
So... if you want to participate in any way (even constructive feedback is more than enough), you'll be all 100% welcome!
1 Like
Greetings, thanks for posting.
although I've obviously written my share of Rebol/Red code, I've never managed so far to get them working on my Catalina 64-bit MacOS - Docker-based aside)
The Ren-C branch runs on many a thing...besides 64-bit, there's Android and WebAssembly.
If you didn't see last year's conference videos:
So... if you want to participate in any way (even constructive feedback is more than enough), you'll be all 100% welcome!
My version of this statement would be: "if you think you've resolved any of the thousands of open questions about Rebol language semantics or mechanics, feel free to participate by posting your feedback on an issue". (!)
The problem I see with starting over from scratch is that it will lead to running into the same issues years down the line. Several smart people tried for years to work on the many unanswered questions of Rebol and most gave up on it--including Carl himself. Projects that ignore that do so at their peril...and run the risk of making something that is easily dismissed as broken and brittle.
Ren-C has been about clawing one accomplishment at a time on the basic issues. It's a slow and difficult path...but by locking features and invariants down one at a time I believe the chances of ending up with a notable language artifact are much higher.
3 Likes
I perfectly understand what you are saying.
However, there is a catch: when I started designing Arturo, I knew nothing about Rebol. Basically, I knew the name, but that's pretty much it.
I started reading about it and playing with Rebol only when I discovered by chance that what I had designed was apparently similar with something that already existed. And even then, apart from trying things and reading up the basics, I've decided - 100% on purpose - not to delve too much into it, so as to avoid being too influenced and ending up with a copy of something (undoubtedbly very insteresting) that was already there.
So, I total get your point. I'm not even saying that I've done the things right.
But the way things have been done in Arturo, I wouldn't be too sure that the language shares its issues - simply because I highly doubt it even shares its virtues, or anything at all that is - apart from superficial similarities. (If you try it out, perhaps you would be the ideal candidates to tell me if it does and at what degree )
If you have an example of what you think is virtuous Arturo code, then I could probably offer an alternative rewrite of it to show another way to look at the same problem.
loop 1..10 'x [
if? even? x -> print [x "is even"]
else -> print [x "is odd"]
]
Decorations like ? on if? are something that Rebol generally tried to avoid. Ren-C is taking it further, e.g. by making OF an infix function that quotes a reflector word on its left... so you write type of x instead of type? x. (There was a push among the open-source Rebol users to say that ending in a ? was reserved for boolean functions...due to disapproval of the idea of ending things with ? to signify that they "are functions returning a value")
Historical Rebol avoids the idea of an ELSE. But Ren-C has it...written as a generic "void+null reactive" infix operator. If what is on the left is VOID or NULL then it runs.
>> null else [print "left was null"]
left was null
>> if true [10]
== 10
>> if false [10]
== ~void~ ; anti
>> if false [10] else [20]
== 20
This makes ELSE work with other constructs (like SWITCH or CASE) or anything that produces nulls. There's a complementary THEN:
switch x [
1 [print "it was one"]
2 [print "it was two"]
] then [
print "it was either one or two"
] else [
print "it was neither one nor two"
]
You can also make the branches functions instead of pure blocks, and use lambdas to get the results. (x -> [code] is a shorthand for func [x] [code], except it has no RETURN of its own...hence a return inside of it is still bound to the containing context's return)
switch x [
1 [<one>]
2 [<two>]
] then arg -> [
print ["branch runs if arg is <one> or <two>:" arg]
] else [
print "it was neither <one> nor <two>"
]
We unfortunately don't have much going on in terms of looping dialects, just a few different limited variants.
count-up 'x 5 [
print [x "is" (if odd? x ["not"]) "even"]
]
1 is not even
2 is even
3 is not even
4 is even
5 is not even
I'd like to see something as powerful as Lisp's LOOP macro, but ideally more accessible. Seeing language like [1 to 10] (not including 10) vs. [1 thru 10] (including 10) would be nice to flesh out vs. going too heavily into shorthands and symbols for the same purpose. But I mention that .. is something that might be interesting.
But the way things have been done in Arturo, I wouldn't be too sure that the language shares its issues - simply because I highly doubt it even shares its virtues
I looked at the page again, and you do say "vaguely inspired". So truth in advertising, I suppose. 
IMHO, there's some pretty amazing machinery in Ren-C. Again: the best I can offer is just to show you "this is how we would do that" for any definition of "that".
1 Like
Here I was probably more influenced by the way Ruby does things, but taking to an extreme level: if we use ? to signify something, then we'd use it in every single such case - even if it is by convention.
So, if ? is meant to signify returning a boolean, then every single function returning a boolean would be suffixed with ?, while the ones who don't, won't. For me, that's consistency. When I noticed that Rebol's type? just returned a value, while other ?-suffixed returned a boolean, and other functions returning a boolean had no ?, I was totally perplexed to be honest.
Btw, in Arturo, there are two different ifs: if and if?. The first one just checks the condition and executes (or not) the following action block. if? also returns the value (of the condition). This way (and this is the only one) it can be branched with an else (basically, else works pretty much like you say - by checking what's left in the stack, in this case by the preceding if? -- again, I had no idea Ren-C was doing it like that. It just seemed to me as a natural way of having an else statement, that could work for ifs, switch-type statements, and even try-catch statements.
To highlight my point, this in Arturo would be like: false else [print "here"]
It's not about me trying to "market" the language as something that it's not. It's just that I mentioned Rebol so that - one already knows the language - would get an idea of what this new language is about. As something similar, which it sure is.
Again, the perfect truth is, when I was designing Arturo, I had no clue what Rebol already did. And I'm still amazed that I keep coming across details that I hadn't even heard of: e.g. the thing you mentioned about the else statement. I guess I'm re-inventing a wheel whose existence I totally ignored lol.
I will absolutely do that and give you many "that"s. Just give me some time.
I already totally appreciate your input
1 Like
The exact same thing written in Arturo:
which - with a tiny bit more syntactic sugar - could be written like:
loop 1..5 'x ->
print [x "is" if odd? x -> "not" "even"]
Output:
1 is not even
2 is even
3 is not even
4 is even
5 is not even
That was presumably born of the feeling that TYPE was too much a "noun" variable name to be "verbified"...so it was chosen to use the ? to "queryify it". I'd like to see more nouns retaken by default, e.g. switch to HEAD OF instead of HEAD.
The ability to make fast specializations with POINTFREE comes in handy here. I think it's more about letting people bend to what they want...fast...than any particular prescriptivism.
The design of VOID is such that it represents a "non-value", e.g. it cannot be put in a BLOCK!. It is chosen as the exclusive "non-result"...returning void means no branch ran. So if a branch happens to incidentally evaluate to void or null, it becomes something known as a "boxed void" or "boxed null"... in a multi-return parameter pack antiform with only one item in it.
>> if null [<x>]
== ~void~ ; anti
>> if okay [void]
== ~[~void~]~ ; anti
This allows one to discover from the outside of a branching construct whether a branch was taken or not, with only one version.
Note: Generalized isotopes were added after this thread was initially written, and are more nuanced than what was originally referenced. This thread has been mercilessly wiki-edited to reflect the modern concept.
loop 1..5 'x -> print [x "is" if odd? x -> "not" "even"]
I do think that the arrows have a disadvantage vs blocks in that they aren't paired delimiters, so you're paying two characters already without establishing the pair. (That, and I've found them very good for lambda.)
One advantage of VOID being non-valued is that it is unambiguous what you mean when you say:
>> compose [<a> (if null [<b>]) <c>]
== [<a> <c>]
The VOID can't be mistaken for anything that could be put into a block (as opposed to Rebol2's #[none]...Ren-C uses several other placeholder types, like _ as BLANK! and ~ as "TRASH"). So VOID really can vaporize.
2 Likes
In case you are interested in seeing a bit more about what I'm working on, I've just published a first (quite complete) reference of the language:
It sure needs various revisions. But in the meantime, feel free to comment on anything. (If you spot things that you consider really different than in Rebol/Ren-C, I would also be interested to know)
1 Like
if x=2 -> print "x was 2!"is the same as writing:
if x=2 [ print "x was 2!" ]Just remember that
->can wrap only one terminal value.
But how can you calculate how big "one terminal value" is? Especially when it's a branch you are skipping for some reason... quite possibly because the very things needed to run the branch aren't defined?
Pseudocode:
if function? :foo -> foo bar baz
If foo were a function, then perhaps you could get its arity...and look up bar and if it's a function or terminal, and proceed down the line. But we're trying to skip it because it isn't a function. And nothing guarantees bar is defined either. It's the branch not taken.
You can do this kind of thing in a compiled language where definitions are pinned down and not able to change. But a dynamic interpreted language needs the blocks.
From time to time, people who think saying append/dup [a b] 'c 2 = [a b c c] separates /DUP from its 2 argument, will suggest moving the /DUP to be nearer the 2. They want something like append [a b] 'c /dup 2 or append /dup 2 [a b] 'c.
But this causes trouble when what you supply to those arguments have optional parameters as well. You get into a prioritization question of "whose /dup is that". It means that people adding optional parameters to a function that didn't have that parameter before can break existing code.
We might soon have a working answer to the desire. Due to having an interesting ability to mix TUPLE! and PATH!, I've considered options like:
append/dup.2 [a b] 'c
append/dup.n [a b] 'c
append/dup.(n + 1) [a b] 'c
append/dup [a b] 'c 2 ; would still be legal
But generic TUPLE!s are new, and the optimizations and formalizations behind PATH!/TUPLE! are new. So it will be some time before that
print user\name
Backslashes are problematic in a lot of scenarios...and if you're passing code fragments around in C strings or to shell scripts it gets pretty ugly.
Characters in Arturo can be declared using backticks:
\w
Backticks are another one of those "problem characters", used typically in Markup to call out code. In fact, in the quote above of \w it lost the backticks.
Ren-C got rid of the idea of a separate character type and instead has a non-series string form that is immutable, e.g. ISSUE!. This means #a can act as a character and be asked for its codepoint, but #abc is also in the same family. They're not technically strings so it's not an infinite regression:
>> first "abc"
== #a
>> first #a
== 97 ; codepoint value, so you don't get #a again
I think it's pretty fantastic, and it's especially nice to be able to have so many common characters not require delimiting. #a is very clean.
"inline"
Not using Rebol's name PAREN! is an important thing to reject. Terrible name.
But I think GROUP! is a much better name for (...)
2 Likes
Good morning (here it's 6+am) and thanks a lot for your points!
Let me go through them.
But how can you calculate how big "one terminal value" is? Especially when it's a branch you are skipping for some reason... quite possibly because the very things needed to run the branch aren't defined ?
Regarding the first point, you're obviously right. In general, given that the only way to figure what goes with what (I mean what is whose parameter) is to know all of the functions beforehand, deferred evaluation (anything in a block practically) certainly makes things complicated. However, I'm still trying to figure out how this could be approached. On one hand, I absolutely love the idea of being able to write more terse code like the one allowed by adding some "sugar". On the other hand, this would probably add at least another pass of the parser/eval. We'll see...
As you can already imagine, I'm also in the process of deciding several things. (Btw, regarding the interpreter/compiler divide... one thing I've been thinking of is to re-shape the current implementation into an Arturo-to-Nim transpiler, and basically rewrite the whole interpreter in Arturo - and slow move to a more... self-hosted implementation. But we'll see - this may be too ambitious).
At time of writing, imagine that CALC-SPLIT-VAL is a function that gives back an integer. Then one day someone edits CALC-SPLIT-VAL so it gets its own .OPTION.
If the only solution to such brittleness is parentheses...then people will start adding parentheses as a "best practice, just to be safe". Pretty soon you wind up back to traditional looking function calls with parentheses again.
Right now, the way "attributes" work in Arturo is a bit... weird (I have no idea at all if refinements work in the same way): basically, you can set an attribute ANYWHERE in your code, it's not directly tied to a function-call. Think of it as a separate stack. An empty attribute (:attr), let's say .always is like pushing a tuple ("always", true) to our attribute stack. An attribute label (:attrLabel) is the same thing only with a user-defined value (.every: 3).
Now, it is the functions that "consume" these values and pop attributes from the attributes stack at will. For example:
f .with: z g x
(where f, g are functions, .with: z is our attribute, and x is the value passed to g).
In theory, in the above example, the attribute "goes with" function f. In reality, it is available to both functions, until one of them needs it or checks it... so... then it would be popped from the stack and consumed. So, if g consumes it, there's no .with for f. And if it doesn't, f may consume it. And if both still don't, it will remain on the stack. If we wanted to use the exact same attribute for both functions, we would have to push it twice: f.with: z g.with: q x (and no, the attributes don't have to follow the function's name necessarily, it just looks better than saying: .with: z f .with: q g x. Although we obviously could.
Backslashes are problematic in a lot of scenarios...and if you're passing code fragments around in C strings or to shell scripts it gets pretty ugly. I think slashes look better and they are in a more comfortable position to type on most keyboards.
I know Rebol/Ren-C use / as a path-delimiter. However, I needed a different symbol for that... simply because the "natural" use of / for me would be to denote division (and I think for the vast majority of programmers). And if I had used it there, using it for something so distinct would be confusing even for me.
That said, I must admit that the whole story with paths (especially in one case: where one of the indexes is not a constant... e.g. user\name looks acceptable, but user<variable> has to be handled somehow) is something that has been bugging me... and it will change this way or the other. I'm not sure if I'll change the symbol used, but I'm 100% sure that I will change something.
I think it's pretty fantastic, and it's especially nice to be able to have so many common characters not require delimiting. #a is very clean.
Again, this is one of the things that confused me. Basically, this is the way I see it:
I wanted to have two functions/symbols used to "arra-ify" and "dictionar-ify" a block - basically, the first one would calculate the block and get the values on the stack (I think that's pretty much what reduce does, no?), and the second one would calculate the block and get the declared symbols into a hash table). For the first case, we use the function array (or @) and for the second one, the function dictionary (or #). Both of the symbols are one of my earliest commitments and preferences regarding what would symbolize what.
So, basically, the # is already reserved for some specific use case. And a rather super-common one (at least for me). Wasting it that on character literals would be a shame. (basically, I get your point, although to be honest I've been tempted to totally eliminate character literals. Initially, the only way to create a character was like to :char "x". I'm not sure I wouldn't revert back to that...)
Not using Rebol's name PAREN! is an important thing to reject. Terrible name.
But I think GROUP! is a much better name for
(...)
Well, PAREN does sound a bit weird, truth be told lol. I basically chose inline quite naturally. It was the "inner" way I distinguished them between square-bracket blocks. And since, the basic difference is that the ones call for inline evaluation while the second ones don't, hence the name).
Cheers
You seem to have been inspired by the "no keywords" part of the philosophy of Rebol. (If, for instance, true and false can be redefined...it was non-obvious from your documentation that they could.)
But "space significance" is another pretty big premise in the Rebolverse. There's a near-majority agreement that the only things that should be allowed to break the rule are ][, )(, ](, and )[
There's only so many ASCII characters. And having spaces between things can be a virtue. I think that [a+b/c] has no particularly obvious virtue compared to [a + b / c]. And when you are willing to let spaces do their visual magic as the most natural way to seeing where symbols end...you gain access to more lexical space.
Regardless of what "most programmers" may be used to, I think it's fairly easy to see a/b and a / b as distinct...not much harder than seeing ab and a b as distinct. And if you're habituated to that kind of thinking, it opens many doors.
Right now, the way "attributes" work in Arturo is a bit... weird
Your description does sound... weird.
Guess I will just cite Alan Perlis:
"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy."
Compare with:
>> append [a b c] [d e] ; append is arity-2 by default
== [a b c d e]
>> append/dup [a b c] [d e] 2 ; /dup adds an integer parameter to be arity 3
== [a b c d e d e]
>> apd: :append/dup ; make APD as specialized form, assumes /DUP
>> apd [a b c] [d e] 2 ; APD is thus arity 3
== [a b c d e d e]
>> f: make frame! :append ; make an object representing call frame for append
>> f.dup: 2 ; set the DUP field in the frame to 2
>> apd2: make action! f ; create an arity-2 function out of the frame
>> apd2 [a b c] [d e]
== [a b c d e d e]
There's a lot of deep detail in the mechanics; e.g. of how that F can remember it's a frame for APPEND, and moreover if it were a frame for a RETURN function instance, it would even remember what function it was a return for.
2 Likes
Checked in on Arturo, and it has assembled an extensive gallery of examples:
Examples | Documentation - Arturo
We should aspire to do something of this kind. Maybe by the time Ren-C is ready, AI will help...assuming we are not all underwater or on fire by that time. 
1 Like
So... here I am again thanks to the ping by @hostilefork 
And yes, we are totally keeping at it... examples included haha.
Basically, as I said, we've used it as a form of spotting missing features or issues, using them as unit-tests for Arturo itself and... in the meantime providing some initial material in the language. So, that has been quite a winning combination. Right now, Arturo is the 41st language in Rosetta Code in terms of problems solved, with a total of 779 solutions, and above languages such as... Pascal, Basic, Fortran, Swift, Elixir, PHP, V, etc... which is amazing! Although it's been some time since we last added a solution, so... we'd better probably get back to it!
Btw, re: AI
I haven't personally experimented with it, but apparently it looks as if the very latest ChatGPT models can grasp the... idea really fast and produce Arturo code with spectacular results. Just have a look:
A web browser written in Arturo, with ChatGPT and the help of some prompts...
1 Like
Needs a discord account?
; Define a function to load a URL and display its content
loadPage: function [url][
; Update the Webview to display the URL in the iframe
eval ~{
document.getElementById("webpage").src = `|url|`
document.getElementById("addressBar").value = `|url|`
}
]
; Initialize an empty list to keep track of navigation history
history: []
currentIndex: 0
; Define functions for navigation
goToURL: function [url][
; If navigating forward after going back, trim the history
if currentIndex < size history [
history: take history currentIndex
]
; Append the URL to the history and update the current index
history: append history url
currentIndex: size history
loadPage url
]
goBack: function [][
if currentIndex > 1 [
currentIndex: currentIndex - 1
loadPage (history@(currentIndex))
]
]
goForward: function [][
if currentIndex < length history [
currentIndex: currentIndex + 1
loadPage (history@(currentIndex))
]
]
; Start the Webview with the initial UI
webview.debug {!html
<style>
body { font-family: Arial, sans-serif; margin: 0; }
#toolbar { padding: 10px; background: #f0f0f0; display: flex; align-items: center; }
#addressBar { flex: 1; padding: 5px; margin: 0 5px; }
#content { padding: 0; }
button { padding: 5px 10px; }
#webpage { width: 100%; height: calc(100vh - 70px); border: none; }
</style>
<div id="toolbar">
<button onclick="goBack()">◀</button>
<button onclick="goForward()">▶</button>
<input type="text" id="addressBar" placeholder="Enter URL" onkeydown="if(event.key === 'Enter'){ navigate(); }"/>
<button onclick="navigate()">Go</button>
</div>
<div id="content">
<iframe id="webpage"></iframe>
</div>
<script>
function navigate(){
var url = document.getElementById("addressBar").value;
if(!url.startsWith("http")) {
url = "http://" + url;
}
arturo.call("goToURL", url);
}
function goBack(){
arturo.call("goBack");
}
function goForward(){
arturo.call("goForward");
}
// Update address bar when iframe navigates
document.getElementById('webpage').addEventListener('load', function() {
var iframeUrl = this.contentWindow.location.href;
// Update the address bar only if the URL is accessible
if(iframeUrl && iframeUrl !== 'about:blank') {
document.getElementById('addressBar').value = iframeUrl;
}
});
</script>
}
; Load an initial page
goToURL "https://example.com"