He also really wanted library-in-one-file. He's doing advent of code.
(not wildly though. and it simplifies usage.)
I did a bit of terminal hacking in 2020 and have various options in mind that should work for that.
and I also have better abstractions now. I've already implemented most of them on the terminal side.
I've been working on a command interface system called klish. it's an embedded product type of thing written in C and using XML command definitions.
i'm off to bed. g'night!
I stopped when I ran into a philosophical issue of the nature of things.
The completion is where I ran into a philosophical problem.
@promovicz Well, I want in the end something like CLIM where you maintain the relationship between a thing and its on-screen relationship ... and since types aren't values in Rust, I run into some issues there ... and I didn't have a solution that I liked at the time (some years ago now) for how to handle a system of types for values.
1 reply
You probably mean
nu ... I've submitted fixes for it in the past. They end up having a whole language and data type system, but it isn't actually all that powerful (the type system).
Such that doing almost anything I wanted to do would require significant foundational work.
I think I looked at that a few months ago, but it might've been last year already.
Like you have DataFusion, which leverages Arrow and supports a bunch of the needed stuff at that level.
but Arrow is basically primitive types and I need something far richer atop that.
I do have an idea of how to do all that generally, but I'm not committed to doing it yet.
I also need to dig up my design notes on a data fingerprinting / detection system ... would be relevant to some contract work that I'm doing (in Rust).
Where given lexical values, determine which possible types they might be, especially in the context of a column of data and a possible header / key name.
Which is also useful in the command stuff, since you want to take lexical values and convert them to useful types.
ideally the command language should have three grammar levels: lexical (obvious, improve existing lexer), phrasal (some simple parser, pipes and command sequences, maybe blocks) and the command grammar. I'm on the fence about blocks because that would be a clone of unix shell. but why not. it's "easy" to do.
and then do object pipes and some table printing. and at some point do it in graphics because I like PowerGUI.
"given the time". but what exists in command-interface fits into that.
shorter-term goal: file completion. locators can't do it. that's a solvable problem.
and I'm going to generalize and remix the shell/editor classes so they are easy to use. that involves a trivial activity system on the terminal.
yeah, that sort of lexical option is why I allow for command grammar ambiguosity. that is specifically to allow for using external parsers and spares the command interface from any sort of lexing beyond string quoting.
and yeah .. it would be separate, but I needed to find a good trait / design for integrating with completion and never ended up doing that.