hacker-007 / envious Goto Github PK

The function call expression needs to have the code generated for it. This will probably involve adding a function in the compiler.rs file to handle function calls. Also, function calls to the standard library will also need to be implemented. For example, a function call to print should result in "print EXPRESSION". An easy way of detecting standard library functions will need to be implemented as well.

The language needs to have a garbage collector, which would improve the languages merit. Libgc may be an option, however, I still do not know how to integrate that into the program.

The current system executes all of the previous statements entered as well. This system is inherently flawed and needs to be changed so that only the current statement entered is executed.

Okay! I'm not super familiar with the Rust ecosystem, but I finally got cargo build to succeed in the envious-tui directory. (I'm planning to submit a PR for how to get that to work on OSX if the dependencies aren't already installed. There was a lot of work to do around the LLVM version, but I figured it out!) But now what? cargo run gives me:

$ cargo run
error: a bin target must be available for `cargo run`

Just hoping to get the TUI up and running so I can play around. If you let me know what I'm missing, I'll file a PR to help others get started, too.

If a method is declared and as the expression, an if expression is used, then the method may produce unexpected output if no else section is provided. Currently, the compiler can not detect this issue. This may require some changing of how expressions are detected and if the else section is necessary for certain things.

Currently, the type checking system points to an arbitrary point for errors. To resolve this, a ParenthesizedExpression is needed. The changes would not be that hard to make.

The current implementation for the type inference algorithm is not able to infer the return types, especially if they are not used in any other context.

This will require a change to the actual algorithm used, which is currently the Wand Algorithm.

Expected:
Output to be 'Y'

Observed:
error: expected define, or extern

First, this project is super exciting!

I'd love to see an explanation of supported types pretty high up in the readme. As this project is influenced by Rust, it's notable that the landing page of the docs features all of the supported types.

Fully going on opinion here, but that's also a good way to grok what a language is about. For example, if you come to a language like Go from a language like Ruby or JavaScript, one of the first unique aspects you're likely to come across is the difference between a string and a byte array.

So like, when I first come to a language, the first thing I do is decide what are going to be the mind-bending aspects of the learning curve, and types give a hint in that regard.

For me, it's like this. With Rust, that's borrowing. With Go, it's the lack of generics. With Haskell, it's that there's no NULL.

So what's going to blow my mind about Envious?

The current architecture of the CLI forces the programming language to route through the runner while having a lot of the actions regarding arguments also occurring there. This may need to be changed to have the run function in the main.rs file take in a reference to the arguments and have the code run through there instead.

A REPL will be very useful for programmers and is somewhat expected these days. The REPL will have to support lots of features such as support for multiple lines, in-built commands, support to edit previous commands and code, and autocompletion just to name a few. This will probably get its own Kanban board in the Github projects tab. For now, a basic REPL loop should suffice. Additional features can be added as the project grows.

The CLI will need to take a new parameter called -f or --format-output to force the compiler to generate well indented code. This will require a couple of changes to the arguments.rs file.

Return statements are able to be parsed and type checked, however, code generation still needs some work. The problem lies within the fact that return statements can not be placed in the middle of entry blocks. Therefore, even if the code is syntactically valid, during the code generation, the return statement is placed incorrectly.