Add imports

[Prime541]

This change is adding a new dimension to the Rockstar language by allowing rock file imports.
It's based on the issue #56 (and issue #63). Resolves #56, resolves #63
As a side effect it also introduces system variables with the thy prefix.

I hope you will like this contribution.
Feel free to challenge it!

Here is a short extract of the new specification:

Imports

You can import a rock file in a line statement.
Importing a file will execute its content and populate the local environment with all its symbols (variables, functions).
This will override any previously defined symbols with the same names in the same scope.

Give a hand for Rockstar Math! (import rockstart_math.rock)
Featuring Rockstar Math & FizzBuzz! (import rockstar_math.rock, FizzBuzz.rock)
Welcome to Gcd & Mod of Rockstar Math! (from rockstar_math.rock import Gcd, Mod)
Contains a sample of Power by pow, and PowerIntegerExponent by powInt courtesy of Rockstar Math. (from rockstar_math.rock import Power as pow, PowerIntegerExponent as powInt)

Multiple libraries and/or symbols are separated with one of the following: , & , and 'n'.

Featuring [ SYMBOL [ aka NAME ] from ] LIBRARY

Keyword	Aliases
Featuring	Welcome to, Quoting, Give a hand for, Contains a sample of
aka	as, by
from	of, courtesy of

System variables are like common variables but with the special prefix thy. System variables won't be imported by the import statement.

• thy Name is nobody (ie. empty string) when the script is directly executed; while it's the name of the current file, in lower case and without the .rock file extension, when it's imported.
• thy Location is the absolute file name of the current script. It's used internally to find other imported files.

[dylanbeattie]

Hey, this is great - I love the idea, and the syntax.

BUT... at a glance, the way it's implemented here, it looks like Satriani won't work in web browsers any more, which is kind of a deal breaker; you're importing fs and a couple of other modules into the interpreter, which gets bundled and minified for the browser-hosted version.

Rockstar has to run in a browser so that people can try it out on their phone, right there and then, without having to download anything or install nodeJS - that's kinda part of the joke about how anybody can become a "rockstar programmer" (and also how I give out Rockstar stickers when I'm doing talks about it!)

How easy would it be to move all the code that handles filesystem interactions into the Environment? The nodeJS runtime and the browser version use a different Environment implementation to hook into different input/output methods, so by abstracting the import mechanisms into there we could have a version that works on the server under nodeJS, and on the browser just fails with a message about modules not being supported.

What do you think?

[Prime541]

Thank you for this comment. Indeed I forgot the web-browser use case!

Now, the presence of missing dependencies is checked.
When the File System functions are not available (or not implemented, like in the current browser-mode implementation) the corresponding include files are simply ignored.

I suppose that the day we give an official support to a Rockstar Standard Library it will be nice to provide those standard library files beside the language implementation. That day, doing Featuring Rockstar Math! will work in the browser as expected.

[gaborsch]

To add another aspect to @dylanbeattie 's point of view: if we create an import feature, it will bind it to NodeJS. It will not be possible to mimic the same behavior in Java, for example. Thus it would close the path for Rocky to be 100% Rockstar compatible.

To be 100% platform-independent and 100% browser-compatible, I also recommend to have a common lib. Maybe it's worth to add packages as well - e.g. with the following syntax:
Give a hand for mighty, Rockstar Math! (import mighty/rockstar_math.rock )

[Prime541]

if we create an import feature, it will bind it to NodeJS. It will not be possible to mimic the same behavior in Java, for example.

I'm not sure to get your point. The import feature is to import '.rock' files, not to do bindings with another language.

To be 100% platform-independent and 100% browser-compatible, I also recommend to have a common lib.

Sure, that's another big topic that would require a dedicated discussion to define a 'Standard Library' for Rockstar.

Maybe it's worth to add packages as well - e.g. with the following syntax: Give a hand for mighty, Rockstar Math! (import mighty/rockstar_math.rock )

Yes, I hesitated on this point to specify or not how includes should work, like:

• in C: #include <search/in/library/paths/first>, #include "search/in/relative/path/only"
• in python: import relative.path.first.then.PYTHON_PATH.for.module
  I did not decide yet. I let the door opened to another discussion.

Notice the door is also opened for namespaces and other OOM concepts.
All this can be specified in another discussion.
At the moment we can only include '.rock' files immediatly located in the same directory as the running '.rock' script.

[gaborsch]

if we create an import feature, it will bind it to NodeJS. It will not be possible to mimic the same behavior in Java, for example.

I'm not sure to get your point. The import feature is to import '.rock' files, not to do bindings with another language.

OK, I got it, I misunderstood first. It's OK - actually Rocky already supports it, except the aliasing feature.

To be 100% platform-independent and 100% browser-compatible, I also recommend to have a common lib.

Sure, that's another big topic that would require a dedicated discussion to define a 'Standard Library' for Rockstar.

Agree. The standard library may be a dedicated Git repo, where anybody can contribute.

Maybe it's worth to add packages as well - e.g. with the following syntax: Give a hand for mighty, Rockstar Math! (import mighty/rockstar_math.rock )

Yes, I hesitated on this point to specify or not how includes should work, like:

• in C: #include <search/in/library/paths/first>, #include "search/in/relative/path/only"
• in python: import relative.path.first.then.PYTHON_PATH.for.module
  I did not decide yet. I let the door opened to another discussion.

If we are using standard library, the path should be the absolute path within the library. For browser-only compatibility this is the only option. For command line, we could allow local overrides (relative to working directory, a well-known subdirectory or even relative to a specified folder given as command line parameter). I had the same dilemma while implementing it for Rocky, I think all of them are supported.

Notice the door is also opened for namespaces and other OOM concepts. All this can be specified in another discussion. At the moment we can only include '.rock' files immediatly located in the same directory as the running '.rock' script.

Discussions are welcome. I also made proposals, and - just for my fun - implemented an OOP in Rocky. It's my concept, maybe others would do it differently, maybe worth to have a look. I'm ready to follow the defined standard in Rocky once we decide about it.

[Prime541]

If I'm correct, the follow-ups of this discussions are these 5 points:

• define syntax for import paths ('/' vs '.' vs keywords, is '..' allowed, are there relative/absolute '"' and default '<' path resolution syntaxes?) Define syntax of import paths #319
• define behavior for include default paths (ROCKSTAR_PATH variable, default official path like "/etc/rocks:~/rocks:.", implementation defined) Define syntax of import paths #319
• namespace syntax ('.' vs '::' vs '->' vs keywords)
• define a Standard Library for Rockstar, where/how should its files be found
• define OOM syntax and concepts

We can open or link existing issues to these points.
IMHO the 3 first points are the top priority (in the perspective of import). The 2 last ones can come later.