Long-Term Strategy

[nordlow]

Are there any plans for scaling and delegating the development of Vox to more developers?

And is there any ordering of priority for implementing the features in todo.txt?

[MrSmith33]

Scaling is definitely a goal. With linux builds working and tests passing it is now easier for other people to get into development.
I need to spend more time on docs about Vox and implementation.

todo.txt is mix of ideas and actual tasks mostly grouped by topic, not priority.

You can consider yourself as a first major contributor 😃

Edit: I didn't do a major announce on D forums yet.

[nordlow]

I could help out improving diagnostics. 😊

[nordlow]

How do I build for Linux?

[nordlow]

I could help out improving diagnostics. 😊

And add a flag for syntax and semantic checking only.

[MrSmith33]

It is in the readme https://github.com/MrSmith33/tiny_jit#running--testing
For that you would need to add flag to CompilationContext in context.d and in cli.d. Also pass structure must be changed for that, as pass list is hardcoded rn in passes.d.

[MrSmith33]

Easy way would be to modify https://github.com/MrSmith33/tiny_jit/blob/master/source/cli.d#L135 to strip unneeded passes.

[MrSmith33]

I've split them https://github.com/MrSmith33/tiny_jit/blob/master/source/passes.d#L62-L91, so you need to choose between commonPasses and frontendPasses.

[nordlow]

Ok, thanks. What do you want the flag be called?

BTW: Why do you call this repo tiny_jit instead of vox? Isn't this Vox's compiler an AOT-compiler?

[MrSmith33]

No idea. Probably the same as other compilers.
Vox as a name of the lang came much later.

[MrSmith33]

I guess the earlier I rename it, the better

[MrSmith33]

Let's try --check-only

[nordlow]

I don't get it. Is there support for Linux ELF output for not? I'm sitting on Linux. And the produced binary on Linux is a Window binary. Linux supports executing Windows binaries now, thought. But still, is there Linux support?

[nordlow]

No idea. Probably the same as other compilers.
Vox as a name of the lang came much later.

Is this a JIT (just-in-time) or AOT (ahead-of-time) compiler? I presume AOT. If so, why the name tiny_jit? Did you plan to design/implement a jitted-language initially?

[MrSmith33]

Currently there is no support for building ELF files, only PE files. But on linux you can run in JIT-mode (as tests do)
Initially I toyed with amd64 instruction generation at runtime, hence the name of the repo.

[nordlow]

How do I run a hello world in JIT-mode?

[nordlow]

Are there any special kinds of diagnostics you are planning?

[MrSmith33]

Is there something Vox will never do but D can because of time/space complexity?

I didn't find such things yet.

Are there any special kinds of diagnostics you are planning?

Some static analysis on SSA IR would be nice I think.

[nordlow]

I didn't find such things yet.

Great.

Are there any special kinds of diagnostics you are planning?
Some static analysis on SSA IR would be nice I think.

Do you mean unused variables, duplicate variable writes etc?

What about null pointer derefs?

[MrSmith33]

I will add ability to enable do runtime checks at first. Then I may try some global analysis / asserts / annotations / special pointer types etc.

[MrSmith33]

But that requires suitable IR

[nordlow]

How are run-time checks for pointer deref better than segfault with stack trace a la D?

[MrSmith33]

for me D doesn't show stack traces, you need to add segfault handler for that (at least on Windows). With checks you can catch null earlier than with segfault. Just having reliable segfault handler would help.

[nordlow]

for me D doesn't show stack traces, you need to add segfault handler for that (at least on Windows). With checks you can catch null earlier than with segfault.

Can you give an example of such an earlier null catch?

[MrSmith33]

When you call method with null this

[MrSmith33]

Just made syscalls into usable state. Still a couple of quirks with register allocation to fix, but:

enum u32 stdin = 0;
enum u32 stdout = 1;
enum u32 stderr = 2;

@extern(syscall, 60)
void exit(i32 error_code);

@extern(syscall, 1)
void sys_write(u32 fd, u8* buf, u64 count);

void write(u32 fd, u8[] data) {
    sys_write(fd, data.ptr, data.length);
}

void main() {
    write(stdout, "hello linux\n");
    exit(0);
}

$ ./tjc ./hello_linux.vx
$ ./hello_linux.exe
hello linux\n

Need to implement escape sequences in strings.

[nordlow]

What are your plans for D-style ranges or Rust-style iterators? I'd like to see Vox picking a Rust-like iterator API [1] with, say, next returning an optional T?.

[1] https://doc.rust-lang.org/std/iter/trait.Iterator.html

[MrSmith33]

For now I like Jai-style iterators, which are done via macros. But they can't passed as a value like ranges can, so composability is worse.
Do Rust iterators support random access, bidirectionality etc features of D ranges?

[nordlow]

For now I like Jai-style iterators, which are done via macros.

Do you have link to Jai-style iterators? Why macros?

But they can't passed as a value like ranges can, so composability is worse.

That's in, imho, a show-stopper.

Do Rust iterators support random access, bidirectionality etc features of D ranges?
random-access: https://doc.rust-lang.org/1.0.0/std/iter/trait.RandomAccessIterator.html
bidirectional: https://doc.rust-lang.org/1.0.0/std/iter/trait.DoubleEndedIterator.html

Note that a Rust-iterator is similar to a range in D and C++20.

[MrSmith33]

Is there any in-depth comparison between D-style ranges and Rust ones?

[nordlow]

I haven't seen any. Rust has no concept of infinite ranges. There might be more differences.