General questions & thoughts

[dumblob]

Cool take on Rebol/Spry/Tcl like language! I'll follow to see where it goes.

1. Any plans for ahead-of-execution correctness checking? E.g. compile-time checks, or some "assert" run before the actual main function gets executed, or some static analyzer tool, ...

2. Seeing the stack is "reified" (i.e. can be read & manipulated explicitly by the programmer) I wonder whether you thought about adopting more from concatenative languages (see also https://concatenative.org/ ) to get rid of the lambda calculus curse (requiring labeling all variables and/or functions)?

3. I'd be interested if you could list which features from this list does Arturo implement and how. Could you comment on that?

4. Have you thought of transpiling Arturo to C like e.g. V does (to get performance "for free" as well as sub-second compilation times allowing for "interpreted language" experience)?

   Note I read https://github.com/arturo-lang/arturo/issues/3 , but I'm still convinced it makes sense as V gracefully proves. Benefits include:

   1. Significantly lower development effort (full standard library for free, bindings do not have to be manually/automatically generated but just "used" as e.g. Visual Basic allows to use DLLs on Windows, etc.).
   2. Full interoperability with any ecosystem (from Android/iOS through Windows/macOS/... up to embedded) "for free" as nowadays everything has bidirectional integration with C (or at least FFI if C is not directly supported).
   3. Partial ahead-of-execution correctness checking "for free".
   4. Very high performance of the resulting program "for free".
   5. Speed of compilation "for free".

5. Why does Arturo have a three-state logic (true false null)? And how is null handled compared to true and false (neither Core nor Comparison don't say anything about it)?

   Yeah, I know that lambda calculus kind of pushes one to return "null" but it's a trap (it prevents chaining, it totally clutters the code and it's highly error-prone due to three-state logic). Even optionals (i.e. "always return two values - one primary and one secondary whereas primary is the intended result and the secondary is an automatically propagated alternative result with stop_propagation&read&discard manual operation") are a better way.

[drkameleon]

OK, first of all, thanks a lot for the interest!

Questions and ideas contribute to projects getting better and better.

So, let me go through your points:

Any plans for ahead-of-execution correctness checking? E.g. compile-time checks, or some "assert" run before the actual main function gets executed, or some static analyzer tool, ...

Absolutely. I've been studying a lot different Design by Contract options, and Arturo will definitely adopt some relevant ideas. Something like assert you mention, or even more specific for pre- and post- conditions.

Seeing the stack is "reified" (i.e. can be read & manipulated explicitly by the programmer) I wonder whether you thought about adopting more from concatenative languages (see also https://concatenative.org/ ) to get rid of the lambda calculus curse (requiring labeling all variables and/or functions)?

First of all, Arturo is stack-based and, thus, in large part shares concatenative features. (Personally, I'm really interested in the Forth-family languages and also studying what features I could use from there too) Have a look at this:

I'd be interested if you could list which features from this list does Arturo implement and how. Could you comment on that?

I'll go through it carefully and reply in a separate message.

Have you thought of transpiling Arturo to C like e.g. V does (to get performance "for free" as well as sub-second compilation times allowing for "interpreted language" experience)?

To be perfectly honest, I've been thinking of many different things (along these lines). First, transpiling to C. Then, if we're thinking of C, why not transpile to Nim - in which Arturo is written after all and get the best of both worlds?

Then - warning: extremely ambitious ideas coming lol: write an LLVM compiler for Arturo and then write the interpreter in Arturo as well, thus become 100% self-hosted. :)

(Regarding V, yes, it is an interesting project, and one of the 20+ ones I've been following closely and studying...)

Why does Arturo have a three-state logic (true false null)? And how is null handled compared to true and false (neither Core nor Comparison don't say anything about it)?

Very good point here. It's something I've been thinking of as well. Practically null indicates nothing but a failed command/function call. So, yes, you have a very valid idea here - I'll think about it.

[theAkito]

transpile to Nim

In my opinion, a great idea.

write an LLVM compiler for Arturo and then write the interpreter in Arturo as well, thus become 100% self-hosted. :)

Indeed, obligatory. 😄

[drkameleon]

In my opinion, a great idea.

It's just sounds a bit like a weird to-infinity-and-beyond scenario lol. I mean think of it: Arturo is written in Nim which is basically transpiled to C, and then have Arturo transpiled to Nim to get transpiled again to C.

Joking aside, it would seem like the most plausible solution.

Indeed, obligatory.

It's just too.. tempting. :)

[drkameleon]

So, a few comments on the list you pointed me to:

1. Reducing the number of nested brackets.

Although Rebol-inspired and thus prone to sea-of-square-brackets syndrome, Arturo already supports enough syntactic sugar (see: -> and => sugar) to make them as rarely used as possible. Although not documented, arrows basically wrap the following command automatically (into a block), so no brackets necessary at all.

if x=2 [ print "it's 2!" ]

; the code below is 100% equivalent
if x=2 -> print "it's 2!"

; also, we can do things like
map 1..10 => 2* ; which would return [2, 4, 6, ... 20]

Regarding parentheses, as you may already have noticed, given the way expressions are evaluated, if you write your code the right way, you may be able not to use a single ( ever.

2. Introducing syntactic sugar similar to Smalltalk's splitting of method names...

Here, Arturo mixes a bit of SmallTalk and a bit of Rebol/Red, does its own magic, and uses... attributes. Basically, every command does a specific thing. If you want to slightly alter what a command does, you would add attributes (they behave somewhat like in Rebol, but look more like in SmallTalk).

E.g.

read "some.txt"                ; reads the file
read.json "data.json"          ; reads/parses it as JSON

split "hello"                  ; returns ["h" "e" "l" "l" "o"]
split.by:"ll" "hello"          ; returns ["he" "o"]

5. Incorporate first class support for an ordered key-value heterogeneous map

This is already included. E.g. this for example is a "dictionary":

dict: #[
     name: "John"
     surname: "Doe"
     age: 101
]

(Hint: dictionary or its alias # do nothing but get a dictionary with all the defined symbols inside the block, after it has been calculated)

6. Change :nil to :false and completely & forever avoid 2+ value logic

As I said above, this is something that will seriously be considered.

8. Add first class support for "spaghetti stack" - maybe even something like CSP threads.

I'll have to read up on this :)

9. Easy merging of lists. Easy merging of maps.

That's already included (for blocks/lists that is). It's the append function (or its Haskell-inspired ++ alias). For set operations, intersection/union/etc, more interesting stuff is on the way...

11. Easier metaprogramming

Well, I think this one is covered almost by... definition, given the nature of the language: a block is nothing but a list of words and symbols without any meaning, until they are given some meaning within a specific context.

15. Introduce a simple "object model"

This one is tricky. Given the fact that Arturo is Dictionary-based, converting :dictionary values to some type of Dictionary-with-context would definitely be an option. I don't know though how far I'm willing to take it. Some features could be included. But suddenly going full OOP is pretty much out of the question - I've never been a real fan.

16. Add "live variables" (one-to-many multiplexer)

Adding "reactive" features to Arturo is one of the things that are definitely in my mind. But... first things first. Once the core is as-bug-free-as-possible, I will include it in my TO-DO list ;-)

[dumblob]

Reading your comments you've almost convinced me already that I should pay more attention to Arturo than I initially planned :wink:. If you don't mind, some more questions & clarifications follow.

transpile to Nim

I'll second this idea as it's much easier (thousands of manhours saved!) and safer to generate than C or any bytecode. I'd even consider transpiling to V to have significantly faster compilation times than Nim and to have just one statically linked small binary.

On the other hand I wouldn't recommend transpiling to LLVM IR or even directly emit x86/ARM/... assembly as it's really a thrownaway time. LLVM IR is super slow, quite low-level, doesn't support non-SIMD parallelism, etc. Assembly is even worse - it has comparable speed of compilation as compiling to C and running it with TCC, but the performance of the resulting binary would be much lower than the one produced by TCC - just look at V as it can emit x86 assembly (it's unfinished so it works just for very simple programs) but the resulting code is not optimized at all (yeah, even TCC makes many valuable optimizations).

Any plans for ahead-of-execution correctness checking? E.g. compile-time checks, or some "assert" run before the actual main function gets executed, or some static analyzer tool, ...

Absolutely. I've been studying a lot different Design by Contract options, and Arturo will definitely adopt some relevant ideas. Something like assert you mention, or even more specific for pre- and post- conditions.

It is absolutely crucial for any language wanting to become practical to have very powerful compile-time correctness checking ability.

In other words, a programming language must consist of two languages fully interleaving - one for compile time compilation the results of which will be put at places where the compile-time-lang-code resided and then this "merged output" fed into the final compiler which'll compile it to binary (or just interpret it). It sounds too "macroish" (which I dislike), but imagine not working with string representation of the code, but e.g. with pure abstract syntax tree or even some generic graph of nodes. Then the compilation would do this: read source (strings) and transform it into one huge graph of nodes (no more strings). Then find nodes which shall be evaluated in compile time, evaluate them, put the resulting nodes to the graph and then run the resulting graph.

Sounds better? Yeah, we're not in Tcl but in a high-level language :wink:.

Design by contract can't be simplified to an assert as that's only a runtime concept (which can be substituted by if cond then exit 1 and therefore adds no value). Much more important is sassert ("static assert") & claim I proposed in the other thread (or at least their less expressive substitutes like compile-time type systems). Both sassert & claim are compile-time concepts and both closely correlate with (or can even be identical to) the metaprogramming as described below.

Do you mean to add compile-time ahead-of-execution correctness checking? That's usually the hardest and most time-consuming job when developing a language :wink:.

Btw. I think NimContracts are by far not enough with regards to metaprogramming :wink:.

First of all, Arturo is stack-based and, thus, in large part shares concatenative features. (Personally, I'm really interested in the Forth-family languages and also studying what features I could use from there too) Have a look at this:

That's a nice take on how to make the lambda calculus curse beast listen to taming lullaby from time to time. Though it's still the cursed beast above all :wink:.

Can you imagine that Arturo won't need to use variables, but will implicitly use what's on the stack currently (so no need to use x twice in the function definitions you showed)? Or better will implicitly use what's in the parts of stack matched by a given pattern (not just a structural one but an advanced one with filtering - a tiny DB query micro language) allowing skipping arbitrary parts of the stack?

I actually could imagine Arturo can have stack pattern matching built-in due to its reified stack. Just find good APIs & syntax and it could work and one could get rid of many labels (named variables, named functions, etc.) and leave labels in other cases where it improves readability.

Here, Arturo mixes a bit of SmallTalk and a bit of Rebol/Red, does its own magic, and uses... attributes.

Can multiple attributes be used simultaneously in an arbitrary order? How would you express e.g. this API from Python (i.e. arbitrary default values of arguments)?

Can existing attributes be changed (or overwritten) "ad-hoc" by the programmer so that already existing (e.g. built in) standard library can leverage the new behavior?

For set operations, intersection/union/etc, more interesting stuff is on the way...

Yeah, that's what I meant (adding/removing from alist is too basic and building own abstractions would be too slow - better to have built-ins).

11. Easier metaprogramming

With metaprogramming I meant "as unconstrained programming in compile time as possible".

15. Introduce a simple "object model"

I'm also not a fan of OOP. The idea is much more generic that OOP - namely to have a way to somehow tell the compiler that it's not a plain dictionary, but that it's somewhat special. Imagine e.g. a "tagged" dictionary with arbitrary number of tags (like class="c1 c2 c3" in HTML :wink:) allowing to skip some boilerplate when using such dictionary (because the compiler would know based on the "tags" how to generate the boilerplate - be it in compile time or runtime). In addition to that, it'd be very useful useful for compile-time correctness analysis.

Thoughts?

[theAkito]

@dumblob

You mention some pretty good points, though to be honest, I oppose the whole V thing and the notion of connecting this project with V, in any way. I am following V for a very long time and long story short, I just don't believe its vodoo. That said, even if you believe in the V-oodoo, then there is still the argument that V is still a super immature language, which additionally leaves a bad taste in my mouth, when thinking of connecting this language with V, in any way.

Therefore, I would go for the safe and in my opinion better way, which is staying with Nim and its natural C connections.

[drkameleon]

@dumblob @theAkito

Well, I think we all agree that if Arturo gets a compiler/transpiler, the natural way would be to transpile to the language it is itself written in. To be honest, I absolutely love the idea. However, until then, my main goal is to deal with any issues with the current compiler first - and there are some. Let's say we are at the point of the first working version of the whole language implementation.

It is absolutely crucial for any language wanting to become practical to have very powerful compile-time correctness checking ability.

Regarding this, Arturo right now has different levels of correctness checking:

• first, the source goes through the parser, which means that we are looking for syntactical correctness (and given that Arturo is syntactically as lenient as Rebol - and perhaps much more), there isn't really much to be checked.
• second, we go through the evaluator, which basically tries to put things in order. Given that there is no strict definition of a "command" in Arturo, we absolutely have to figure out how and when to push things on the stack.

For example:

print add 1 2 print "hello"

The above is absolutely valid code. OK, I admit I personally wouldn't write it exactly like that (though I can), but pretty much like:

print add 1 2
print "hello"

Still, this extreme flexibility (and avoiding parentheses and semicolons and all that) comes at a price. We have to figure out what goes with what. And the golden rule here is arity. We may have a function with different argument types, or even attributes (see: optional named parameters), but we cannot have the same function with a different number of arguments.

So, for example, we know that print takes 1 parameter. The evaluator will keep consuming words until it finds all its parameters. Then it comes across add. That's a function, the "command" is not over, let's push 2 to the stack (the number of arguments add takes) and look for them now. Once every parameter has been found we pop the required params from the stack until we're left with nothing. When the required-args stack it's empty, it's time to finalize the corresponding bytecode, so the final result would be something simple like:

     push 2
     push 1
     add
     print
     push "hello"
     print

• the last remaining part happens during the execution of the generated bytecode, where we simply verify before every function call that the corresponding items on the stack are of the required type.

I know it's not complete by any means. But I think it's a sufficient basis to start building upon.

Can you imagine that Arturo won't need to use variables, but will implicitly use what's on the stack currently (so no need to use x twice in the function definitions you showed)? Or better will implicitly use what's in the parts of stack matched by a given pattern (not just a structural one but an advanced one with filtering - a tiny DB query micro language) allowing skipping arbitrary parts of the stack?

The answer is: yes, I can surely imagine such functionality integrated - though as I said, I would prefer to stick to "stabilizing" the core features for now and then move on to more... exotic experiments :)

Can multiple attributes be used simultaneously in an arbitrary order? How would you express e.g. this API from Python (i.e. arbitrary default values of arguments)?

Can existing attributes be changed (or overwritten) "ad-hoc" by the programmer so that already existing (e.g. built in) standard library can leverage the new behavior?

Regarding the last part, I cannot say much - basically attributes can be interpreted by a function at will (that is: the function may make use of them or ignore them), so I don't think that's the case.

Regarding the first part, have a look at this -- attributes can be set in any order and consumed in any order:

So, practically print color.bold.red "hello" should be exactly the same as print color.red.bold "hello"

(* Since you mentioned it, I discover a bug in the attributes stack, which is what I will be working on today :)) (Just fixed it: 8fbf10a69ed4b79deecea4b66f67104a85f82875)

I'm also not a fan of OOP. The idea is much more generic that OOP - namely to have a way to somehow tell the compiler that it's not a plain dictionary, but that it's somewhat special. Imagine e.g. a "tagged" dictionary with arbitrary number of tags (like class="c1 c2 c3" in HTML 😉) allowing to skip some boilerplate when using such dictionary (because the compiler would know based on the "tags" how to generate the boilerplate - be it in compile time or runtime). In addition to that, it'd be very useful useful for compile-time correctness analysis.

That's pretty much what I was thinking :)

[drkameleon]

Btw, since you mentioned HTML/CSS and attributes...

...let me show you all something (it's no hidden project, you can run it yourselves too, provided you install the html module: sudo arturo -m install html)

We setup our server, routing and generate the HTML (all in Arturo):

And here's the result:

Here's what you'll see in the terminal, while our server is running:

---

As a matter of fact, the "official" website is already running on Arturo. :)

[dumblob]

@theAkito yes I fully agree.

I'm new to Arturo so I don't know whether the first beta release is planned in several years or weeks - for the former V might still be a viable second option after Nim as it's highly unlikely Nim will get significantly faster due to its comprehensive feature set but it's likely V will stabilize and mature in a few years. For the latter Nim or anything else than V is a better choice.

I just think working on compilation to Nim/C/... is a better investment than developing bytecode etc. as the TODO in readme states. But of course, first the language itself must stabilize disregarding how it's implemented.

I know it's not complete by any means. But I think it's a sufficient basis to start building upon.

Indeed, it sounds like a good starting point. I'm afraid though I still can't see a clear way how the first two compile time stages shall allow for more compile-time correctness checking than they do already as there doesn't seem to be anything instrumentable. I.e. I can't see it's possible to build any comprehensive metaprogramming upon the current set of primitives and information available in these first two compile time stages.

Btw. it's always possible to introduce an optional delimiter and specify, that arity is not fixed, but "the longest match" (which the delimiter would cut down if needed). So I don't see arity as the only good way to tackle some of the "free syntax" issues.

Regarding the last part, I cannot say much - basically attributes can be interpreted by a function at will (that is: the function may make use of them or ignore them), so I don't think that's the case.

But technically function definitions can be merged with an arbitrary "block" and the result assigned back to the original function label, right? During such overwrite/redefinition one can add/remove/change any attributes, right?

How would you express e.g. this API from Python (i.e. arbitrary default values of arguments)?

...basically attributes can be interpreted by a function at will (that is: the function may make use of them or ignore them), so I don't think that's the case.

With "named arguments" with default values there is a simle and IMHO "acceptable" workaround - enforcing a list as first argument (for positional arguments) and a map as the second argument (which together with the "merge" functionality I asked for above makes it extremely easy to check for superfluous/missing/wrong/correct values in the given with some pre-defined map content embedded in the function) and maybe with some syntactic sugar on top this could be enough

let me show you all something ... install the html module: sudo arturo -m install html ...

Nice example where the ahead-of-execution correctness checking could be applied a lot! E.g. some html elements can't nest in others and some have a pretty limited attributes, some have either-or relations etc. This reminds me a lot of the html module for Dao which offers at least this hierarchy guarantees and attribute guarantees and relations guarantees due to its type system. I hope Arturo will offer many more guarantees that Dao once compile-time correctness checking gets designed and implemented.

---

One more less important question. Does Arturo provide any means (sugar, etc.) to change its prefix notation to postfix one (infix notation seems already partially supported) like e.g. Haskell allows for function composition?

I'm asking because naturally it's about 50:50 when to use prefix and when to use postfix "mental model" (look at natural languages). Sometimes it's rather "sculpting" (have a pile of data which gets first roughly worked on and while diving more and more into them, everything gets more and more precise; in other words mentally a "breadth first search") which favours postfix notation (so common for concatenative languages like Forth) and something is more like eagerly looking for the final result and "ignoring" details at first and getting to them later ("drill down") and then mentally jumping to the "next big envisioned result" out from the depths you're now in and again immediately "drilling down" (in other words mentally a "depth first search") which favours prefix notation and is common for functional lambda-calculus based languages.

So instead of print add 1 2 one could write e.g. 1 2 @+ @print (i.e. @ would mean "take your already evaluated arguments from the stack instead of looking for non-evaluated arguments on your right side and evaluating them first in some given order") or even better 1 @@+ 2 @print (i.e. @ with the meaning as before and @@ applicable only to functions having exactly two arguments and making them infix). This can be then extended to designating whole "blocks" as postfix or infix or whatever to allow writing mathematical expressions very simply or writing postfix notation for many situations where nesting is too deep to make it comprehensible in prefix form (which demands "jumping" in the form of lookaheads to see what will be actually passed as argument).

This syntax is a bit crazy, but it demonstrates the concept. Two more notes on the syntax. First, I'm convinced in majority of cases one wants to specify the postfix/prefix/infix order at the place of use and not at the place of function definition. Second, infix syntax can represent anything prefix or postfix syntax can (binary tree can represent any arbitrary tree) and I've noticed that infix syntax is a good compromise between prefix and postfix (compare infix 1 + 2 + 3 + 4 versus postfix 1 2 + 3 + 4 + versus prefix + 4 + 3 + 1 2) and assuming infix is the default for everything in a language then if combined with just one of postfix or prefix syntax, it becomes much closer to natural thinking while not requiring any more parenthesis than plain prefix/postfix syntax if properly thought out (e.g. including syntax sugar etc.). I'm biased and prefer combination of infix by default with "postfix on demand" but Arturo seems to prefer prefix by default with "infix on demand".

Have you thought about how would Arturo look like if it was infix by default with "prefix on demand" or even infix by default and "postfix on demand"? E.g. instead of if? x>0 -> print x you'd write for infix+prefix x>0 then _ print x or equivalently x>0 then x print _ or equivalently x>0 then (_ print x) (assuming _ is a void symbol to satisfy the parser expecting infix notation everywhere) or equivalently x>0 then @printf x (assuming @ tells the parser the function is in prefix form and thus is allowed to have just one argument skipping the _ boilerplate) and for infix+postfix x>0 then x @print.

After more thinking & trying one usually realizes that pure infix syntax & API with some sugar on top allows actually for improved readability and higher level mental model than pure prefix or pure postfix disregarding how much sugar there is. This is (by coincidence or maybe not) what RDF triplets do.

[drkameleon]

During such overwrite/redefinition one can add/remove/change any attributes, right?

Exactly.

---

Regarding the last part of your question, here's an interesting feature I've been experimenting with (it's obviously not documented since it's experimental - see: quite buggy for now - but documentation is the number 1 thing I've been working on these last day, Library Reference is at last complete... the Language Reference is still pending)

So, here's what's already included in arturo...

Original Example (the most verbose version, no symbols used, no syntactic sugar)

(the basic idea: take an array with the numbers from 1 to 10 (inclusive), add 2 to each one of them, select only the even ones and print the array)

print select map range 1 10 [x][add x 2] [x][even? x]

Using symbol aliases and literals for parameters:

print select map 1..10 'x [x + 2] 'x [even? x]

Using pipes(!)

1..10 | map 'x [x+2]
      | select 'x [even? x]
      | print

Using pipes + thin right-arrow operators (syntactic sugar)

1..10 | map 'x -> x+2
      | select 'x -> even? x
      | print

Using pipes + thick right-arrow operators (more syntactic sugar!)

1..10 | map => 2+
      | select => even?
      | print

All of the above is (or will be) 100% equivalent.

As you can, there is a lot of flexibility :)

[dumblob]

The pipes and the thick right arrow "operators" might be the thing I was looking for in Arturo! Eagerly awaiting documentation to understand also their "future" :wink:.

Once you'll have more information regarding other discussed points (e.g. after you decided something "new"), feel free to share them here. I suppose now you need a little bit of time to wrap your head around the points and to decide what everything you want to see part of Arturo and how to achieve that.

Once that stabilizes, I hope there'll be some more room for PRs :wink:.

[drkameleon]

I've just finished the first (quite) complete reference draft: https://github.com/arturo-lang/arturo/wiki

• Language Reference is in and rather exhuastive
• Library Reference is also in (and with tons of example for almost all of the built-in functions)
• Instructions for the packager and command-line reference is also in

Please, have a look and feel free to share any feedback, ask me any question you have, anything - it's more than welcome :)

[dumblob]

Please, have a look and feel free to share any feedback, ask me any question you have, anything - it's more than welcome :)

Great, now it's well summarized. I've skimmed through it and what I'm missing is any insight into future changes to the language - basically everything discussed in this thread :wink:.

[drkameleon]

Please, have a look and feel free to share any feedback, ask me any question you have, anything - it's more than welcome :)

Great, now it's well summarized. I've skimmed through it and what I'm missing is any insight into future changes to the language - basically everything discussed in this thread 😉.

Well, I get what you're saying 100%. But I'll do it one step at a time.

For now, my # 1 priority is to make sure that everything in the reference works exactly as supposed to, cleanup the source code and do several low-level optimizations.

Once this is resolved, future changes and a roadmap will come :)

[dumblob]

For now, my # 1 priority is to make sure that everything in the reference works exactly as supposed to, cleanup the source code and do several low-level optimizations.

Understood. If I'll find some more time, I might test some "special cases" if I'll come up with any :wink:.

Once this is resolved, future changes and a roadmap will come :)

Looking forward to that :wink:.

[drkameleon]

Feel free to... shoot me with anything.

I'm really passionate about this project and feedback is what will make it even better :)

[PeterWAWood]

I saw a mention of Arturo on a Red Gitter channel. From a quick look it seems very interesting with a clean design and has been soundly produced. I have a couple of questions related to extensibility. Do you envision adding the ability to write & compile Arturo functions in Nim in a similar way that Red routines can be written and compiled by Red/System. Do you envisage a library the provides a foreign function inteface (at least to C) to enable access to external libraries?

Finally, do you ever see Arturo being embeddable into apps wrtten in other languages (Nim, C, etc)?

[drkameleon]

@PeterWAWood

Peter, Hi!

And thanks a lot for your kind words! :)

Do you envision adding the ability to write & compile Arturo functions in Nim in a similar way that Red routines can be written and compiled by Red/System. Do you envisage a library the provides a foreign function inteface (at least to C) to enable access to external libraries?

Well, as you may see from my answers above... absolutely.

In Arturo's case, since it is itself written in Nim (which, in turn, transpiles to ultra-efficient and portable C code), the first option would be the obvious one: that is transpiling/compiling to Nim. The idea is very tempting and also very exciting.

As a matter of fact, I have already started experimenting a bit with the concept: for now, rough sketches of an Arturo->Nim transpiler written in... Arturo. I'm nowhere near showing anything to anybody, but the first preliminary results show that it should be perfectly possible. (And the latter part of the first question, could easily follow)

Regarding the last question:

Finally, do you ever see Arturo being embeddable into apps written in other languages (Nim, C, etc)?

Well, although I haven't even touched the subject... at all, until now, given the way Nim is built and the options it gives you, converting Arturo into a library that could, for example, be used from C, etc should be very easy. (I've done that in the past, with different programming language experiments, and it could probably take a couple to a few days...)

Hmm... I think you've just given me a great idea for a super-interesting subproject :)

P.S. Any other idea/question/suggestion is more than welcome! (Code contributions as well 👍 )

[MichaelCMcCann]

Hey, I recently discovered Arturo and I'm enjoying its simplicity. I saw how to create and iterate across an associative array (dictionary) from the examples, but I'm wondering how I would add and edit items in an existing dictionary? Thanks!

[drkameleon]

@MichaelCMcCann Hi!

And thanks a lot for your kind words! Really appreciated! 👍

Have a look:

[MichaelCMcCann]

Great! Thanks for your reply!

I should also have asked how to:

• add a second value to a key:

a #[ children: “John" "Joan”]

• remove a single value from a multi-value key by name

• remove a key and its values altogether

(tried… remove.key a … both as string and literal, but to no avail.)

Thanks!

I have been looking for a new language after learning that Rebol/Red would not work on my new 64-bit OS, and Arturo seems to fit the bill!

[drkameleon]

I should also have asked how to:

• add a second value to a key:

a #[ children: “John" "Joan”]

• remove a single value from a multi-value key by name
• remove a key and its values altogether

(tried… remove.key a … both as string and literal, but to no avail.)

Hi!

I've opened a new issue for the question and I'll try to reply there (just to keep things organized and in case somebody else looks for the same thing): #47

I have been looking for a new language after learning that Rebol/Red would not work on my new 64-bit OS, and Arturo seems to fit the bill!

Glad to hear that! I'm very happy you found Arturo and even happier that you are playing with it. I've taken a very short break from its development (real-world non-opensource projects calling) but I'll be 100% back to it very soon.

It's been a love child of mine and - even though I haven't intentionally copied Rebol/Red (as a matter of fact, I didn't even know about its syntax), Arturo does share many similarities with them, aiming to be even more easy to use, and of course portable.

Any feedback/question is more than welcome! (And any potential code contributions as well :) )

[MichaelCMcCann]

Great. Much appreciated!

On Dec 30, 2020, at 9:28 PM, Yanis Zafirópulos notifications@github.com wrote:

I should also have asked how to:

add a second value to a key: a #[ children: “John" "Joan”]

remove a single value from a multi-value key by name remove a key and its values altogether (tried… remove.key a … both as string and literal, but to no avail.)

Hi!

I've opened a new issue for the question and I'll try to reply there (just to keep things organized and in case somebody else looks for the same thing): #47 https://github.com/arturo-lang/arturo/issues/47 I have been looking for a new language after learning that Rebol/Red would not work on my new 64-bit OS, and Arturo seems to fit the bill!

Glad to hear that! I'm very happy you found Arturo and even happier that you are playing with it. I've taken a very short break from its development (real-world non-opensource projects calling) but I'll be 100% back to it very soon.

It's been a love child of mine and - even though I haven't intentionally copied Rebol/Red (as a matter of fact, I didn't even know about its syntax), Arturo does share many similarities with them, aiming to be even more easy to use, and of course portable.

Any feedback/question is more than welcome! (And any potential code contributions as well :) )

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arturo-lang/arturo/issues/23#issuecomment-752849466, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDMUTAEJO55FTOF7A63SXQDW7ANCNFSM4SZSG5HA.

[MichaelCMcCann]

Hey, thanks for your help on this. I’ve been super busy these past two weeks with another project, but should have more time to continue exploring Arturo and Grafico this week. Thanks for being there!

On Jan 18, 2021, at 2:17 AM, Yanis Zafirópulos notifications@github.com wrote:

Closed #23 https://github.com/arturo-lang/arturo/issues/23.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arturo-lang/arturo/issues/23#event-4217357751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDPMUHCBNDVMXJQWHPDS2QDDDANCNFSM4SZSG5HA.

[drkameleon]

Hey, thanks for your help on this. I’ve been super busy these past two weeks with another project, but should have more time to continue exploring Arturo and Grafico this week. Thanks for being there! … On Jan 18, 2021, at 2:17 AM, Yanis Zafirópulos @.***> wrote: Closed #23 <#23>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDPMUHCBNDVMXJQWHPDS2QDDDANCNFSM4SZSG5HA.

The truth is... your interest in the project made me re-visit some details and... I'm 100% back to the project.

As a matter of fact, I myself was not that confident of what Arturo was capable of, but given the way Grafito turns out (I've been working on the project almost on a daily basis - and in the meantime, fixing anything that pops up in Arturo), it looks more than promising. Great things coming! :)

[MichaelCMcCann]

Great. Glad to hear it!

On Jan 18, 2021, at 9:49 AM, Yanis Zafirópulos notifications@github.com wrote:

Hey, thanks for your help on this. I’ve been super busy these past two weeks with another project, but should have more time to continue exploring Arturo and Grafico this week. Thanks for being there! … <x-msg://2/#> On Jan 18, 2021, at 2:17 AM, Yanis Zafirópulos @.***> wrote: Closed #23 https://github.com/arturo-lang/arturo/issues/23 <#23 https://github.com/arturo-lang/arturo/issues/23>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment) https://github.com/arturo-lang/arturo/issues/23#event-4217357751>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDPMUHCBNDVMXJQWHPDS2QDDDANCNFSM4SZSG5HA https://github.com/notifications/unsubscribe-auth/AAGITDPMUHCBNDVMXJQWHPDS2QDDDANCNFSM4SZSG5HA.

The truth is... your interest in the project made me re-visit some details and... I'm 100% back to the project.

As a matter of fact, I myself was not that confident of what Arturo was capable of, but given the way Grafito turns out (I've been working on the project almost on a daily basis - and in the meantime, fixing anything that pops up in Arturo), it looks more than promising. Great things coming! :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arturo-lang/arturo/issues/23#issuecomment-762393077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDI5K34L57EJ73S7QADS2RYBDANCNFSM4SZSG5HA.

[MichaelCMcCann]

Hi!

I really like what you’re doing with Grafito. I have a couple of requests/suggestions:

• The option to display the results as a hierarchy in addition to a mind map. Both have their advantages, but lists make for a neater display at times.

• Also, it would be nice if one could make certain links bi-directional. For example, rather than:

"Bob -> wife -> Sally”

A dual link such as: “Bob -> Husband/Wife <- Sally”

Many such links could be predetermined, so that “Bob -> Employee -> Google” would automatically create the connection “Google -> Employer -> Bob”

One more question: How feasible would it be to embed a Gafito database into a webpage and make it browsable in real time?

Thanks!

Michael

On Jan 18, 2021, at 9:49 AM, Yanis Zafirópulos notifications@github.com wrote:

Hey, thanks for your help on this. I’ve been super busy these past two weeks with another project, but should have more time to continue exploring Arturo and Grafico this week. Thanks for being there! … <x-msg://2/#> On Jan 18, 2021, at 2:17 AM, Yanis Zafirópulos @.***> wrote: Closed #23 https://github.com/arturo-lang/arturo/issues/23 <#23 https://github.com/arturo-lang/arturo/issues/23>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment) https://github.com/arturo-lang/arturo/issues/23#event-4217357751>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDPMUHCBNDVMXJQWHPDS2QDDDANCNFSM4SZSG5HA https://github.com/notifications/unsubscribe-auth/AAGITDPMUHCBNDVMXJQWHPDS2QDDDANCNFSM4SZSG5HA.

The truth is... your interest in the project made me re-visit some details and... I'm 100% back to the project.

As a matter of fact, I myself was not that confident of what Arturo was capable of, but given the way Grafito turns out (I've been working on the project almost on a daily basis - and in the meantime, fixing anything that pops up in Arturo), it looks more than promising. Great things coming! :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/arturo-lang/arturo/issues/23#issuecomment-762393077, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGITDI5K34L57EJ73S7QADS2RYBDANCNFSM4SZSG5HA.

[drkameleon]

@MichaelCMcCann Thanks a lot for your feedback. I totally appreciate it!

I'm moving the ideas you mentioned to separate issues/feature-requests in Grafito, so that we can continue from there:

• https://github.com/arturo-lang/grafito/issues/3
• https://github.com/arturo-lang/grafito/issues/4
• https://github.com/arturo-lang/grafito/issues/5