This page lists some desirable features we might want to add to Vesta SDL (the language that Vesta builds are written in).
Contents
Primitive Functions
Text to Int
This can be written in SDL but it's cumbersome and performs poorly.
We might want options for parsing the text as decimal, hexadecimal, octal, or potentially some other base. strtoul(3) could be used as a model.
Int to Text
This can be written in SDL but it's cumbersome and performs poorly.
We might want options for whether to format it in decimal, hexadecimal, octal, or potentially some other base.
Printf
It would be nice to have a version of printf usable from SDL. We have to be sure that the same parameters give the exact same result string regardless of which platform the evaluator is running on. This will probably require implementing our own printf code rather than using a function from the C run-time library, as it seems unlikely that the results are completely identical across all OSes and OS versions.
Split Text
Split a text string into a list of text strings on ocurrences of another text string. This can be written in SDL but it performs poorly and can recurse deeply and run into stack space limitations.
Join Text
Join a list of text strings with some text string placed between each pair of strings. This can be written in SDL but it performs poorly and can recurse deeply and run into stack space limitations.
Pragmas
nocache for models
Currently the /**nocache**/ pragma doesn't work on models. It would be nice if it did.
pkextra
See RFE titled "New pragma for moving secondary dependencies into PK".
Function Calls
Specifying function args by name
It would be nice to be able to specify arguments to SDL functions by name:
c = foo(a=3, b=2);
Skip function arguments with defaults
See RFE titled "Skip argument with default value in function call".
Wildcard Files Clause
Some people would like to be able to write something like this in SDL:
files c_files = [ *.c ]; h_files = [ *.h ];
And have the shell-style glob patterns "*.c" and "*.h" expanded to all the filenames in the immutable directory matching those patterns.
The syntax might need to be different.
See RFE titled "wildcards in files clause of models".
Overlay Assignment in Files/Import Clause
Sometimes people are forced to write things like this:
from /vesta/foo.example.com/foo import
stuff_1 = [ pkgA/3, PkgB/7 ];
from /vesta/bar.example.com/bar import
stuff_2 = [ pkgC/5, PkgD/12 ];
{
stuff = stuff_1 + stuff_2;
// ...
}It would be nice to instead be able to write:
from /vesta/foo.example.com/foo import
stuff = [ pkgA/3, PkgB/7 ];
from /vesta/bar.example.com/bar import
stuff += [ pkgC/5, PkgD/12 ];
{
// ...
}
Multi-line text strings
It's currently kinda awkward to specify multi-line strings in SDL because it requires something like this:
hello.c =
"#include <stdio.h>\n" +
"int main( void )\n" +
"{\n" +
" printf("Hello World!\n");\n" +
"}\n";With python-style multi-line strings, it would be easier & prettier to build quick-little in-line programs (written in C/perl/python/etc.), and thus there'd be less pressure to add native language features to SDL:
hello.c = """
#include <stdio.h>
int main (void)
{
printf("Hello World!\n");
}
"""(KenSchalk) Is there a particular reason why such multi-line strings couldn't be put into a file in the same directory as the model and then used through a files clause? That would seem to have several benefits over writing a multi-line string in-line in the SDL code. I'm not clear on what the counter-argument is for the use case you mention here. (I can see how it might be useful for some shorter multi-line strings that get appended or pre-pended to other files.)
(BrannonBatson) The usage models I had in my head were reasonably short (5-20 lines) sed/awk/perl scripts (used for text processing tasks) and things like blocks of html boilerplate--where SDL is used to populate a table in the middle of a largely static html document (perhaps with a few other small SDL generated text fields). In both cases, the user wants to interleave multi-line text gracefully in with other SDL code without the overhead of a bunch of small little text files (you have to create them, name them intuitively, find somewhere for them to sit, import them). And it aids readability & maintainability of the code if pieces of it aren't hidden through a level of indirection.