mattjquinn / jcompiler Goto Github PK

In ijconsole, writing a verb like + and hitting return results in the text representation of that verb being printed to stdout; jcompiler should do the same.

Compiler should replicate interpreter's behavior/wording:

$ ijconsole
   1 2 + 3 4 5
|length error
|   1 2    +3 4 5

Benchmark both compiler speed, and the speed of compiled binaries.

https://code.jsoftware.com/wiki/Vocabulary/dollar#dyadic

Compiler is correctly assigning global identifiers ids into the global table, but not enforcing requirement that identifiers must have been assigned to. Simple change to llvm.rs needed for this - if an ident hasn't been declared/initialized yet, refuse to compile.

Run with all warnings switched on, stop build if any warnings/errors.

i.e.,

a =: 2 3 $ 1.2323 4.43435 9.23333333333333 8.32 9.1121111111111 5
a

currently causes an unsupported message/exit. Add in appropriate snprintf/printf calls as was done for integers.

Above a certain magnitude, J displays numbers in scientific notation, i.e., 5e36. Modify jprint to handle this.

• Possibly use Cargo's workspace feature to contain both the compiler crate and the dylib runtime crate so that they can share definitions such as type and verb enums.

A subset of J programs that use a wide subset of J should be benchmarked to ensure compiler/runtime changes don't cause performance regressions.

Will improve performance when using large arrays that either:

• don't have their internal elements accessed at all (i.e., $ 100 100 100 $ 9999)
• only have parts of their element space accessed

Running the tests in parallel (cargo's default) fails due to memory corruption; this is likely due to something being mismanaged in llvm.rs.

i.e., in compiler_tests.rs

For example, global_idents map on Module struct should not be accessible outside module.

The PEST parser already provides good error messages, but compile-time failures need improvement.

J's focus on arrays lends itself naturally to parallelization, experiment with ways to harness SIMD/CUDA for extra speedups.

• This will allow writing of tests that ensure code doesn't expect that all expressions are known statically at compile time.
• Use C's srand(seed) to implement.

i.e., string concatenation

i.e., if a program doesn't call any monads, there's no need to import jmonad from jverbs.c

Current print code has a large amount of overlap due to need to detect table column widths; format specifiers are used multiple times rather than in a single place. This should all be consolidated.

Because one is not enough...

Use criterion's comparison feature to compare benchmarks with the previous commit; if a performance decrease occurs, the build should fail.

Using cargo doc-upload gives inconsistent results from the Travis build; it worked at one point but now it doesn't. Rather than use GitHub pages, something like S3 should be used to prevent use of a repo branch itself to store the documentation.

Also note that benchmark reports using criterion should be placed in a subfolder of the built docs so that the latest reports can be linked to from ie README.md.

all arrays should have multi-dimensional characteristics by default (i.e., shape and rank).

Parser currently gets tripped up on escaped single quotes within strings.

4 % 0 is represented as inf, should be represented as _ as in J.

For performance reasons, as much as possible should be allocated on the stack. Currently malloc calls are favored to keep the code understandable in its early stages, but in the future stack-only allocations should become a focus.

For instance, rather than malloc arrays we can decrement the stack pointer continually until we reach the end. The number of decrements is the length of the array. We can then apply a monadic function directly to this array, or for dyads, we remember the verb, store the next array, and intelligently operate on the two arrays. As a rough example:

1 + 2 3 4 becomes: sub $sp, store 1 $len1, (remember "+"), store $sp,
sub $sp (3 times), store 3 $len2, then call add 3 times

Arrays of random length, or whose length are unknown at compile time, should have the same thing done; the number of decrements to the stack pointer simply becomes variable and verb code will need to handle it accordingly.

Arthur Whitney seems to use only the stack in his B language interpreter, so maybe get some inspiration there:
http://kparc.com/b/
https://docs.google.com/document/d/1W83ME5JecI2hd5hAUqQ1BVF32wtCel8zxb7WPq-D4f8/edit
https://github.com/tlack/b-decoded

And while this early interpreter for J uses malloc, there should be something to learn here as well:
https://code.jsoftware.com/wiki/Essays/Incunabulum

http://www.jsoftware.com/help/jforc/contents.htm#_Toc191734291

APL: A Glimpse of Heaven: https://news.ycombinator.com/item?id=19325361
K7 Tutorial: https://news.ycombinator.com/item?id=19418570