Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ jsonnet_evaluate_snippet_aux
• jsonnet_realloc ⇒ from_string

Using double precision floating point has its flaws, e.g. rounding errors. It makes sense to use arbitrary precision rational arithmetic in Jsonnet. We will have to find a library with a decent license that does not bloat the binary size too much, and then replace the current number representation.

Implementing something like the Python % operator seems like the best plan. Although other solutions would also be possible.

I develop jsonComm format with comments in JS or Yaml style.
https://github.com/spmbt/jsonComm
It need mach more simple code for coding and decoding (2 KBytes in JS only).

We should add an entry to github/linguist for Jsonnet so that GitHub can 1) add proper syntax highlighting for displaying .jsonnet files and 2) include them in the language stats for repositories.

The interpreter currently knows how many objects are live, but not how large they are. If it had this extra information, it would be possible to place a bound on the amount of memory that can be used during execution. This makes it safer to run Jsonnet in a server environment.

"foo"[1] should return "o".

Jsonnet would hardcode some paths

/usr/share/jsonnet
/usr/local/share/jsonnet

You would also be able to add additional search directories with a JSONNET_PATH environment variable.

Perhaps the hardcoded paths would have version numbers in them.

There are contexts where allowing Jsonnet programs to access the file system is inappropriate, for example when a server executes code provided by a user. In those cases, it may still make sense for the import keyword to do something useful, but the service that is using the Jsonnet library needs to provide some sort of callback to handle the import construct in that case.

Jsonnet will still cache the result of the import to maintian referential transparency.

HOCON is a configuration language that is part of the typesafehub config library https://github.com/typesafehub/config

It has some similarities with Jsonnet.

JsonNet for PHP : http://pecl.php.net/package/jsonnet

git: https://github.com/Neeke/JsonNet

It is currently possible to write programs that run for a long time, such as computing the Ackerman function. This is bad news if Jsonnet is integrated into a server, where such programs will use excess CPU resources and block other users.

Jsonnet should count the number of loops around the VM, and bound it either in number of instructions, or in time by calling the time syscall every 1000 instructions (or whatever).

The current implementations of foldl (and similar routines) rely on tail call recursion, but currently they blow the stack when operating on arrays that are too long. This can be fixed by optimizing tail calls to re-use their current stack frame.

I think an explicit construct for enabling the optimization is better than applying it for all tail calls, because then you preserve stack traces in the majority of cases where the optimization is not required.

Currently, list comprehension only supports a single 'for' and a single 'if'. In Python, an unlimited number of these can be specified, and they can be interleaved arbitrarily. Consider extending Jsonnet to be equally expressive.

I expect that exception handling is usually supported by a C++ program. I wonder why your function "main" does not contain corresponding try and catch instructions so far.

How do you think about recommendations by Matthew Wilson in an article?

Would you like to adjust the implementation if you consider effects for uncaught/unhandled exceptions like they are described by Danny Kalev?

I find that include guards like "AST_H" and "VM_H" are too short for the safe reuse of your header files (when they belong to an application programming interface).

This can easily be done if you miss a }, but the error message currently complains about the lack of comma after the e.

$ ls folder
input.jsonnet
$ cat folder/input.jsonnet

import "" {
    cocktails +: {
        "Whiskey Sour": {
            ingredients: [
                { kind: "Scotch", qty: 1.5 },
                { kind: "Lemon Juice", qty: 0.75 },
            ],
            garnish: "Lemon Peel",
            served: "On The Rocks",
        }
    }
}

$ ../jsonnet folder/input.jsonnet
terminate called after throwing an instance of 'std::ios_base::failure'
what(): basic_filebuf::underflow error reading the file
Aborted

Currently only ASCII is supported in strings. It should not be too hard to accept UTF-8 (raising an error for invalid input), and adjust internal string routines to support unparsing those strings correctly, as well as routines for iterating over codepoints, correctly determining the length (in codepoints), etc.

I suggest to reuse a higher level build system than your current small make file so that powerful checks for software features will become easier.

• CMake
• Autotools

Code to convert to/from tuples like {year: x, month:x, ... seconds: x } into textual / other structured representations (seconds since epoch, etc).

ES6 has some wonderful functionality based on strings wrapped in the back-tick (`) instead of the standard double-quote (") and single-quote (') characters.

Please, PLEASE add full support for the ES6 back-tick functionality!

I forked and converted to use Visual Studio, and I also changed support from Python 2 C API to Python 3.4 API. It wasn't horribly difficult to do either task, but the project is there for anybody who needs or wants it.

Add std.codepoint("f")
Add std.char(50)

There should be a syntax sugar for just if e then e, that expands to if e then e else null.

It may be useful to import from a URL, or otherwise contact an external service. The current semantics would be a special case of this, i.e. file://path.

It is not clear whether the request should be parameterizable.

Either way, Jsonnet will still cache the result of fetching the URL to enforce referential transparency.

The behavior is the same as //

The purpose is to allow "hash bang" lines at the top of the file, and also be consistent with other syntaxes such as Python and YAML.

It would be good to have an import_as_string construct that behaves similarly to import "foo.jsonnet" but instead yields the contents of a file as an uninterpreted string. This would be useful for embedding bash scripts, for example.

Lexical ordering by unicode codepoint should be sufficient.

For exploring Jsonnet, it would be nice to have a REPL, e.g., via jsonnet -i. For inspiration, I would look to Scala's REPL as an example.

I think it is better if there are unit tests, such as using gtest.

This is probably a small modification to the static checking code.

Evaluate both files and check JSON output is the same.

This is useful when refactoring to know whether or not the changes were purely internal (good) or had some external effect (bad).

E.g. if you're a vim user:

jsonnet --compare Foo.jsonnet Foo.jsonnet~

Can output a diff of the two JSON strings.

Conflicts with --multi.

Runtime platform OSX 10.10.3:

# ../jsonnet --gc-min-objects 1 --gc-growth-trigger 1 error.import_folder.jsonnet
STATIC ERROR: lib:1:1: Unexpected end of file.

this error is different from the linux runtime error, https://github.com/google/jsonnet/blob/master/test_suite/error.import_empty.jsonnet.golden
so the test fails.

Suggested fix to work on multiple OS platforms might be to insert platform name (eg error.import_folder.jsonnet.darwin.golden) and test for existence of a platform-specific file within run_tests.sh.

std.substr("foobar", 4, 2) should return "ar".

{
    foo: |
        blah
        blah
    bar: 3
}

should be equivalent to

{
    foo: "blah\nblah\n",
    bar: 3,
}

This will make it much easier to inline scripts into Jsonnet.

It would be good if a computed field name evaluated to null, rather than being a dynamic error, if that field was simply omitted from the object. For example

{
    x: 1,
    [if nighttime then "light_brightness" else null]: 100,
}

Will yield either {x: 1} or {x: 1, light_brightness: 100} depending on whether nighttime is true.