Derivatives-DASIL

• Overview
• Running a script from outside ASIL
  • Running a script that lacks a namespace
  • Running a script inside a namespace, but not a module
  • Running a script inside both a namespace and a module
  • Running something else inside a DASIL script from outside ASIL
• Running DASIL code from SASIL or other DASIL scripts
  • Why doesn't that syntax use the . operator?
• Running SASIL code from DASIL
• Parameters to DASIL scripts
• Return values from scripts
• Undeclaring something

Overview

Compared to SASIL, a DASIL script can do a lot of things. But then, DASIL isn't meant for creating executables. Rather, each script is an executable. You do "compile" DASIL scripts, but more to ensure they'll run later. The "compilation" process ensures there are no syntax errors. It's unknown if the source code file would then be signed by the compiler somehow to mark that it appeared error free. The "D" in DASIL stands for "dynamically-typed". This means that DASIL doesn't check to see that when you reference a member that the type actually has that member until runtime. This means that everything is virtual like in Javascript.

Running a script from outside ASIL

Any DASIL parser must provide two ways to run a script file. Which way must be used would depend on if the script was part of a namespace. For more on namespace XML files, see [Namespaces].

Running a script that lacks a namespace

Give the interpreter the full OS path to the script file. Think of the script as a public member of a default namespace.

Running a script inside a namespace, but not a module

Such scripts can't be run directly with the OS path. That's because the script might not be public. If the script is part of a namespace, it must be declared as public in the namespace. Otherwise, you can't run it. Specify the script to the interpreter using the syntax "namespace@identifier". The "@" is a literal. You need that character. The "namespace" part must be a fully qualified namespace name. So you might need "my.name.space". The "identifier" part must be the ASIL identifier given for the script in the namespace's definition file. So if that namespace has a script named "MyScript.dasil" that goes by "MyScript" in ASIL code, call it from the command line with "my.name.space@MyScript". It's up to the interpreter to provide you a way, as a separate parameter, to specify where to locate the namespace. Once it has the namespace XML file, it should be able to locate the script on its own.

Running a script inside both a namespace and a module

Now not only must the script be declared as public by the namespace, but the namespace must be publicly declared by the module. Otherwise, treat it the same way. The DASIL interpreter should use the module registration system to locate the module.

Running something else inside a DASIL script from outside ASIL

This isn't allowed. Instead, write a brief DASIL script and make the call from there. Now call your DASIL script as described above.

Running DASIL code from SASIL or other DASIL scripts

Because DASIL allows types declared in the top level of a script to be undeclared with the undeclare keyword, types declared in a DASIL script aren't accessible outside that script. You are, however, allowed to call the script itself. However, it must exist in a namespace. You need to use the namespace syntax given above. However, if your enclosing type (or DASIL script) that is currently running happens to be in a related namespace, you may be able to truncate the namespace name.

• If your current namespace is derived from the target namespace, just use the inner-most namespace's name without the full qualifier.
• If your current namespace shares one or more parent namespaces, just use the closest namespace's name without the full qualifier followed by any differences.

So if you're calling a script in "MyNamespace.Subnamespace" and your code is inside "MyDerivedNamespace" which derives from "MyNamespace", use "Subnamespace@ScriptName".

Why doesn't that syntax use the . operator?

For one simple reason: ASIL has to be sure you want a script and not something else in the namespace.

Running SASIL code from DASIL

This is easier. All SASIL types are visible from DASIL. You might, however, need to qualify the type name with a namespace. You may also need to list the module as a dependency for you code. See the section [Modules] for more on dependencies.

Parameters to DASIL scripts

For compatibility reasons, while DASIL scripts can take parameters, the interpreter is only expected to pass an array of strings. The params keyword is treated by the interpreter as a global array containing your parameters. If no parameters were passed, the array will be empty, not null. The entries will be listed in the order they were specified by your script's caller.

When you call a DASIL script from inside ASIL, treat it as a function. Ignore the return value if you don't need it. That return value, as discussed below, is always an int. ASIL will use your toString member to convert each parameter into the string needed and then build the array for you. While from outside ASIL, you might need to put parameters in quotes, that isn't required from within ASIL code.

Note: Don't create the array yourself and pass that! ASIL would dutifully convert the array into a string and pass it as a single parameter.

Return values from scripts

If the interpreter sees a return statement at the top level of the script (not in a procedure), it will terminate the script. If no value is provided in the return statement, you're returning 0. If you need to return something else, explicitly list the value. Any valid int value will do. You aren't required to return a constant.

Undeclaring something

The undeclare keyword lets you undeclare some identifiers. However, they must be declared in the same script at the top level. So something in a type can't be undeclared. For more information, see the undeclare keyword's own page.

[Will Pittenger]

I would like to allow DASIL scripts to take more a more complex syntax. But I don't know how to allow callers to call scripts from something like a BASH command line and use that complex syntax. Some form of auto-complete on the command line would be needed. But some shells, like DOS/Windows, don't support auto-complete on the command line for parameters other than file names.

If you have ideas, bring them up.