Questions regarding current Spry and its future

I've tried to read all available materials (including parts of the VM implementation and Spry modules sources, all your articles about Spry on http://goran.krampe.se/category/spry/ etc.) and have many questions :wink:.

Due to their amount, I didn't create separate issue for each of them, but rather concentrated all of them here.

Is Spry case sensitive? Are Spry sources in UTF-8? How is UTF-16 supported? With string representation dualism like in Red? These questions are of fundamental importance for homoiconic languages.
Any support for chained type casting?
Support for "external" Spry modules written in Nim so that everybody can load their non-standard non-upstream binary modules from any (trusted) place (see e.g. Go-lang for the meaning of "any" - basically a string not just designating the unique name, but giving also some "human" pointers where to find the module - "human" pointers mean not necessarily "machine readable" as that's not always possible).
Could one create a "parallel" DSL with the following semantical meaning?
1. Every "statement" will get executed in parallel by default (i.e. implicit paralelism). Spry shall actually be quite well prepared for this as already now many things seem to get copied when "assigning/passing" due to the ubiquitous closure semantics.
2. This would imply introduction of means for specification of sequential evaluation parts.
3. Considerations regarding design shall include support for automigration of the computing context to another computing environment and making this fully transparent to the programmer (though influenceable) - e.g. when the current computing env will be an IoT device and the computation will take e.g. too long (or based on other clever runtime heuristic provided by the programmer for the particular program), then automatically transparently migrate to a more powerful node in the dynamically growing/shrinking non-homogeneous grid and then just send the results back.
  1. See e.g. Unison language as it does it more or less this way. Unison is also a live coding environment with very advanced support of the programmer - and I mean the language, not IDE (disclosure: it's based on an advanced typing system doing all the heavy lifting without sacrificing safety). Generally said Unison is therefore fully distributed, high level (it's rather a smaller language), purely functional, and actually fast (though not so small as its compiler is currently written in Haskell).
4. Any "traditional" means of synchronization might not be needed at all (due to being functional and having the sequential section option).
5. My proposal is somewhat semantically similar to BMDFM or ParaSail (though BMDFM is for SMP systems, but Spry would be fully computing architecture agnostic and would use a dynamic runtime scheduler - imagine SQL EXPLAIN but executed repeatedly before the operation returns - to accommodate for e.g. a single maschine with big.LITTLE SoC and one Vulkan graphics card or e.g. for a distributed network of several POWER9 servers and many smartphones and many tiny IoT devices all connected using different networks being differently reliable).
6. This parallel DSL proposal could influence performance optimizations etc. of spryvm as some of them might disallow existence of such DSL.
7. This parallel DSL proposal is more about semantics of the language and about the standard library and coining "best practices" as the VM implementation itself can actually stay more or less the same as now with the "hidden" fact, that this implementation simply doesn't take full advantage of the parallel semantics of the language and doesn't have the runtime dynamic scheduler (sure, in such case it would be wise to e.g. randomly change the parsing order etc. to cheaply "simulate" the paralelism effects of the semantics, but strictly speaking it's not necessary).
Support infinite streams of non-homogeneous data (maybe also with some syntactic sugar for chaining of one-way single-producer single-consumer pipes - see e.g. an attempt to implement it in Red) as language first class citizens to allow making the language "fully reactive" (sorry for the buzzword) in a similar fashion as Red tries to, even though by different means (see https://doc.red-lang.org/en/reactivity.html ).
Support existing Red/Rebol code to a degree?
To which degree will be static analysis possible?
1. Optional explicit specification of types possible (but not required)? This would make interfaces clearer and would ease static analysis.
Compilation to an (optimized) binary theoretically possible? By "binary" either lower-level bytecode or an architecture-specific binary is meant (but not an architecture-specific interpreter with an embedded Spry script and its dependencies to interpret).
A yield-like or similar construct (if I'm not mistaken, this shouldn't be that difficult as nearly everything in Spry is a closure).
function/routine/method arguments with default values (allowing the programmer to skip arbitraty set of them at invocation)?
A defer-like or similar construct - guaranteed execution of all conditional actions in a gathered list (see Dao [1] [2] [3] ).
Is overloading of symbols/names/labels (including "operators" which are functions) possible? At best for both:
1. functions/routines/methods with the same number of args and different types
2. functions/routines/methods with different number of args
Built-in "first class" support for versioning (might get difficult due to it being very live - maybe saving the whole context somewhere and allowing patching/merging of the currently running context with the saved version)? E.g. Erlang has such "first class" support (by allowing parallel use of the old and new version with strictly defined semantics when to use the new and the old one).
I really like among other things the infix function syntax (that allows bunch of really good abstractions like in Red/Rebol) - thanks for that!
What about performance (slower than CPython is a pain :wink:) and ways of speeding things up easily (let's assume JIT is the threshold of "easily")? Any progress in implementation of the strategies outlined in your blog posts?
A possible solution of the current overhead (both in space and time)? The scenario is thousands of millions of small "variables" like integers and operations with them.
Support for immutability, validator checking that e.g. a number is in one of the few allowed ranges, etc.? In other words values with constraints on operations with them and on the contents of the values.
What about zero copy "views" library/module (allowing working with an endless untyped stream of arbitrary data as a typed structure, but without copying anything - i.e. parsing data only on demand/lazily and only the very needed minimum)? This will be needed for any I/O including e.g. a really fast HTTP(S) server (even in case the server itself will be available through Nim, the HTTP headers and bodies must not be copied, but rather shared as read only).
Existence of an advanced UI (see e.g. https://www.red-lang.org/2016/03/060-red-gui-system.html ). As backend one could use e.g. Nuklear or Quarks (Nuklear itself has backends for basically any platform existing nowadays; there are also Nim bindings for Nuklear :wink:)?
I feel the utter need for real applications built with Spry.
1. What about an obligatory interpreter of Spry? The very minimal interpreter would be cool and could show how neat Spry is.
2. Minimal POSIX-like interactive shell (at least "commands" working with files and streams, parallel "jobs", simple parsing of binary streams of data into "variables", etc.) - no bash, no fancy stuff, just "feels like POSIX sh" - the shell itself could be fully based on some DSL of Spry to make it easier to parse and eval.
3. Server part for your Nano Wallet 2.0 would be a good fit showing all capabilities of Spry while not needing any excessive modules like UI (why actually Dart was chosen? Isn't Dart just a very mainstream language, very verbose with "just" one small advantage of full stack platform independence).
Could you add Spry to Learn X in Y minutes? It's the fastest source of syntax and semantics knowledge for many existing languages and the best primer for polyglots who would like to try a new language.
"Namespaces" in Spry do not feel good. Somehow the "live environment" with "closures" and other Spry features do not play semantically well with that. Red/Rebol uses refinements for "nested symbol contexts" which you do not like, but actually it's a way how to avoid namespaces while keeping things small (Lisp doesn't have refinements or similar and all the function/routine/method names used in practice are therefore very long).
I mentioned Red several times above. I'm curious what do you think about Red?
Could you write a new article on your blog which would list all differences (changes made) to all the information in your all older blog articles to ease "catching up" with the current state for newcomers (btw I find your articles pleasant and fun to read - good work!)?

Btw. see also a list of things which Red folks ("new rebolists") would like to change or improve or add to the Red/REBOL language as that basically lists most of the missing stuff for "everyday use" and is probably very good source of such information for Spry as well:

Spry is case sensitive. Source code are read and handled using Nim string handling, which does not enforce any specific encoding, but per convention UTF-8 is used.
Not exactly sure what you mean. First of all, Spry is dynamically typed so "casting" is a term typically for static type systems.
Today you can relatively easy make your own Spry Nim modules, but you would still need to build your own interpreter. I have not experimented with dlopen etc to be able to load modules dynamically.
Would probably not be that hard to build "something", however, the current thread code uses Nim native threads, which in turn creates a separate Spry interpreter in each thread. Using the Nim abilities to communicate between those threads one could probably make some interesting Actor model. Regarding all the other things you mention, it's a very ambitious vision, I am trying to get simpler things working well first :)
Producer/consumer pipes etc, also interesting, but nothing I am focusing on this early.
Spry has deviated quite a lot from Rebol, it's only a source of inspiration (like Forth, Lisp etc) - the "feel" of Spry is much closer to Smalltalk.
Not much :) I am not focusing on that area at all. Spry is heavily purely dynamic.
I haven't really planned to do any "lower" level compilation. Compiling dynamically typed languages and get good performance is traditionally done best via JIT-ing VMs. But again, not something I am even looking at.
Some kind of coroutines/yield etc could be fun, yes, and much more plausible when I rewrite the interpreter to be "stackless".
Default parameter values etc is... harder. Not sure really, given how Spry argument passing works.
You mean like...at end of scope? Mmm, might be neat.
In Spry arity is not declared. Overloading is possible in two ways, using modules which shadow each other in a "load order" (but a shadowed module can always be reached directly. Not exactly "overloading" but... still) and using polymethods, which is something I am experimenting with to get polymorphism. See poly.sy and poly2.sy. The idea is to be able to compose methods based on "tags" on objects. I think Lisp calls them multi methods.
Mmmm, not sure. Smalltalk uses "become" to be able to do migrations, Gemstone uses "versions of classes", and yes, Erlang also has such concepts. Nothing I have thought about yet, especially since Spry is not class based in regards to behaviors, and also not class based in regards to instance shapes.
:)
Performance is slow, but Spry is fairly "shallow" so if a Nim primitive is available things can be quite fast. And it's easy to make them. I will not focus much on any other plans, except porting the interpreter to other platforms - Dart first.
No thoughts so far.
Immutability etc, not considered yet.
Zero copy views, again, not considered.
I have indeed looked at various UI frameworks and been thinking of alternatives like Nuklear or imgUI etc. The first one I have taken a stab at is however libUI. The availability of a Nim wrapper is very important at this stage. There are a few examples now using libUI, should all run in Linux/Windows/OSX using native UI (gtk on Linux).
On "real applications", hehe, yeah, well. You need to define "real". At this point in time small experimental applications is leading things forward. Well, in regards to a "shell" in Spry, would not be that hard to make I guess. But I lack time ;) I am not working much on Canoe, too much other things on my mind. Dart is interesting because it offers a good garbage collected OO language that runs on all platforms - including mobile.
X in Y minutes, a good idea, yes. I will take a look at it. I have started making some very small Rosetta code exercises.
Yeah, namespaces... well, it's something to be experimented with further for sure. I have my "modules" idea combined with polymethods, but have not yet played much with the concept.
I know too little of Red to really comment on it.
A new article, yeah, I am about to do that.
About proposals to Red, I will take a look!

gokr / spry

Questions regarding current Spry and its future #14