Read-eval-print loop is quite useful kind of tool that simplifies both learning and trying some short code ideas. REPLs are always very specific - they can be used for evaluating programming language statements, some math calculation, database management, file processing and so on. In The Console I decided having all those things and even more - way to incorporate custom REPLs.
However, idea have grown much more than expected. In this post I explain what's the big deal to talk about which shows why the development have currently slowed down.
Do we need custom REPLs?
Imagine silly string processing, like converting binary code to letters or hex numbers. Do you really need that between all commands?
Maybe you'd like to have some custom syntax? Remember DSLs? We'll get into it later.
Actually, read on.
Basic input in The Console is interpreted by this simple algorithm:
- is there any command (script or script alias) having a name of first word inside input line? If yes, then execute by passing all other words as arguments.
"Wow, it's actually REPL!" you may say.
Imagination is good, however, I won't be able to produce every type of REPL. I'd rather want to give that power to users of The Console so they can make anything for their own needs.
By having enough of power we should be able to implement better things than silly text processing:
- file processing, like file grep, data filters and converters in custom syntax, e.g. R lang
- shell for database management, e.g. MySQL or Mongo (look at MongoDB Shell)
- bindings to languages having "interactive shells", like Python, Ruby, Elixir or PHP
- dynamic texted web crawlers
REPL is a simple thing
Indeed, it is! Simply request the input, evaluate it and print result to the output, then repeat. The name says it itself, anyway. But designing API for custom REPLs surprisingly seems to be a bit more challenge than pure nature would tell us.
Approach 1. Maybe just readInput() , printInput() and that would be enough? User then would have to implement his own loop with questionable condition. And that loop would require some asynchronousness support since currently scripts are launched in synchronous manner. Already too complicated.
Approach 2. Script enters some "REPL mode" where it just listens to key events in the input? This gives a lot of power, however a lot of job needs to be done. Support every key, including ESCAPE, ENTER. And that opens new needs, like a way to stop execution, exiting "REPL mode", event processing, ... Let's aim KISS.
Approach 3. Maybe simply improve approach 2 by introducing different layers of control power. That means, if you want to interpret every key code from the input, then go with it this low level. Otherwise, if you want just single text lines, then go with this higher level. Seams reasonable, but I feel I would need to design it for custom auto-completion anyway so it gets more complicated again.
So that grows and grows and still no stable requirement was designed. In pushing the evil creature called we-need-more-power I have noticed few more wishes:
Notice no. 1. If we want to output nothing to the console we should be able to. Having a binding to external software like Octave we'd like to simply render a plot in it's own window rather than printing text in console.
Notice no. 2. By the way, having a way to bind stdin and stdout of external software would need another API.
Probably there are are more things to note but it seems too big already. Whole this topic and scripts in general lead me to modules which I'm going to explore next.
Oh, please. Boundaries?
Computers are all about interaction and information so I'd like to give as much power as possible. Every human has his own data that he'd like to process and interact with.
You may say, "Namek, stick to Unique Selling Points" - I know. But, some future version of The Console is the USP itself, in my opinion. That's why I'm going to merge all those ideas and cut out only those which are too problematic to solve or those which strongly push user away from desire to code his own REPL.
The state of development
All pieces strongly connect together - custom scripts, script sharing, installation, custom REPL, modularity, command variable auto-completion, external software execution and few more. Each one projects on each other, that's why I have a hard time designing whole thing both as a product and a development process.