Add Claro to Riju!

[JasonSteving99]

Claro is my hobby language that I started working on around the very beginning of 2021. Check out the repo at clarolang.com. I provide both a compiled and an interpreted version, so there's a REPL out of the box as well. As such, I'm able to make full use of Riju and I'm extremely excited to get Claro merged and hosted to celebrate 1 year of working on this passion project!

Claro supports things like functions, loops, conditionals and variables. It also supports static type inference and strictly enforces typing constraints. Claro, however is missing a ton of functionality as it's very much a work in progress. Here's hoping that Riju's happy to be a place to host languages that are currently in development as I have many plans for this language and hope for Riju to be its home as I continue to enhance it over the coming months and years :).

[JasonSteving99]

Hi @raxod502 just cc'ing you for review since I realized I wasn't sure if you'd be notified without it. Really looking forward to submitting this contribution :)

[raxod502]

Thanks for the contribution. The build for Riju is currently failing, and I'm working on getting that sorted out so that I can merge pull requests. I also have some ideas for how Riju can be rearchitected to make it so that external updates do not cause the build to start failing spontaneously, which would prevent this sort of thing from happening in future. In the meantime, it may take a bit of time for me to get things working again. I haven't forgotten about this though.

[JasonSteving99]

Thanks for the update and thank you for welcoming contributions. No problem about the build, hopefully it doesn't cause you too much pain on your end.

Putting the cart before the horse, I'm curious to ask how often Riju redeploys, or at least reinstalls languages? Once Claro is merged into Riju, how often do langs get re-installed? Obviously I'm more than happy with anything best effort, not expecting a strict schedule, but it'd be useful to know a ballpark of if/when new Claro features would reach riju.codes/claro to play with

[raxod502]

I've pushed a commit that makes a number of improvements, including:

• Language metadata conforms to jsonschema
• Use heredoc for interpolated shell script, to improve readability
• Simplify usage of sed quite a bit
• Put assets into /opt/claro instead of /usr/local/bin because they are not binaries
• Two space indentation for consistency
• Split compile and run steps
• Initialize repl after running code (https://github.com/raxod502/riju/blob/master/doc/tutorial/run.md#languages-with-repls)

Does this look good to you? If so, I'm good to merge.

[raxod502]

✨

[JasonSteving99]

This is incredible! I just looked through the changes you've made and I can say you've definitely improved pretty much everything top to bottom. This type of low level shell scripting is absolutely not my world so I'm definitely learning from your changes, thank you.

Getting this merged is going to turn out to be the best Christmas present, I appreciate your work!

[raxod502]

Finally got the tests for other languages passing; things seem to have bit-rotted since last time anything was changed so took a while to get a successful deployment: https://riju.codes/claro

Is it possible to have the repl not clear the terminal? At present the output from executing the program gets cleared when the repl starts up. (Riju starts a repl after executing code, since otherwise there is no way to access the repl again after pressing Run.)

[JasonSteving99]

It's seriously incredible seeing Claro hosted on Riju! Thanks again.

As for the terminal getting cleared, that's a very good callout. I've finally had the chance to poke around at this a bit and it seems like the library that I've used (Lanterna) to implement the REPL has no way that I can see to determine how many lines have already been printed to the console prior to the REPL starting. This is an issue since this library requires me choosing an (x,y) coord to print all chars to the screen rather than just some higher order "append" functionality that implicitly already knows how many lines are already in the console. As a result I really unfortunately have no good way of fixing this problem, although there are 2 options that are better than the current state.

1. I can just always start the REPL on the bottom line of the terminal by forcing the console to just scroll a couple lines before starting on the last lines instead of the first. In this way, if you print more than 1 line in the compiled program run, you'll still be able to see your output after the REPL starts. This is just going to look weird in your UI since all of the other REPLs start on the top line of the console..

2. I can always start the REPL at the top line by scrolling the console a full page before starting the REPL prompts on the "first line". In this way, the compiled program output will always be hidden, but it will still be available if you (somehow know to) scroll up a page in the console to find it.

This REPL UI has absolutely not been a top priority, so none of this sounds all that great, but a better fix probably would require me investigating other terminal libraries or just writing my own from scratch.. In reality though I'd much rather be done with the UI stuff. I'm thinking I'd be happy enough with option 1) above, so I'll work on getting a change out for that, but let me know if you think I should go another route.

[raxod502]

It's fine to start the repl at the bottom of the screen, that's just an aesthetic choice. The same happens with https://riju.codes/apl and there's nothing I can do about it.

On the other hand, why does a repl need a full ncurses-style interface? Usually one just leaves the terminal device in its default mode, which makes everything work automatically like you would expect. Are there fancy autocomplete dropdowns or things like that?

Anyway, it's totally up to you. I'm just invoking the binary :)

[JasonSteving99]

Hmm, to be honest this is just the only way I could get the repl to resemble anything like the repl's I'm used to using with the most minimal amount of research (since I mostly dislike all forms of UI programming I've gone with the first thing that worked "well enough" and stopped thinking about it lol). I don't know how other repls are implemented or if there are better resources I should be using other than Lanterna. The reason I'm using this is literally just for the ability to respond to arrows/backspace/enter keys and then to be able to redraw the same lines that had already been written in cases where the user presses up/down/backspace and want to fetch history or delete an already drawn char (which is the only reason I didn't just System.out.println(...) all the text lol). But this is all a very hacky implementation, if there's some better library available to me that works better and abstracts all of this away I would love that, if you know of one please let me know :)

In the meantime, I'll probably just go with the approach of starting the terminal at the bottom for something hacky that "works". I'll probably make this change just by updating the release in my git repo so it probably would just take a restart from your end but not a pull request, so I'll let you know when I have that up and ready (I'm in the process of moving btw, so my change might take a bit depending)

[raxod502]

You should be able to simply print to stdout and read from stdin, and use a readline module (there are implementations in all major programming languages) to take care of arrows, backspacing, and history automatically. This is a pretty standard thing so you shouldn't have to implement it yourself. For example:

• https://docs.python.org/3/library/readline.html
• https://nodejs.org/api/readline.html
• https://ruby-doc.org/stdlib-2.5.1/libdoc/readline/rdoc/Readline.html
• https://man7.org/linux/man-pages/man3/readline.3.html

Or even https://github.com/hanslub42/rlwrap which can add these features to a program that doesn't already have them, which I use for a number of other languages on Riju.