readline
Pipefish
readline | Pipefish | |
---|---|---|
2 | 36 | |
23 | 138 | |
- | - | |
10.0 | 9.2 | |
about 3 years ago | 11 days ago | |
Go | Go | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
readline
-
Charm: a new language in, with, and for Go
... I kind of am, though. Which is why I didn't know what to do. I don't see a lot of free open source projects with extensive documentation in their README. Some, yes, but for example here's the readline library I'm using. I, in my well-meaning ignorance, supplied 50 pages of documentation and people are behaving like I ate a baby 'cos it's in the wrong format. I will now put it all in the README as people would like, but I did genuinely act out of ignorance and not out of a wish to insult the customs of the tribe.
-
Guide: Hush Shell-Scripting Language
> I would like to see a framework for creating rich REPLs that would be language agnostic, so that I could get a state of the art auto-completion dialog no matter which language I decided to make into a shell.
It's doable with existing tools. You have LSP to provide the syntactical framework and there's no shortage of alternatives to readline (I'd written my own[1] to use in murex[2], and open sourced that).
[1] https://github.com/lmorg/readline
[2] https://murex.rocks
The problem you still face is that a good shell will offer autocompletion suggestions for strings that aren't language keywords or function names. eg
- file names; and there's a lot of hidden logic in how to do this. Do you build in fzf-like support, just include fzf wholesale but increase your dependency tree, or go for basic path completion. Do you check metadata (eg hidden files and system files on Windows), include dot-prefixed files on Linux / UNIX, etc. How do you know when to return paths, or paths and files, or even know not to return disk items at all? (see next point)
- flags for existing CLI tools (assuming you want compatibility with existing tools). Fish and murex will parse man pages to populate suggestions, others rely entirely on the community to write autocompletion scripts.
- Are you including variables in your completion of strings. And if so are you reading the variables to spot if it's a path and then following that path. eg `cd $HOME/[tab]` should then return items inside a your home directory even though you've not actually specified your home directory as a string. That means the shell needs to expand the variables to see if it's a valid path. But that's a shell decision rather than a language feature.
Some of these lists might take a while to populate so you then have another problem. Do you delay the autocompletion list (bad UX because it slows the user down) or provide the autocompletion sooner. And if the latter, how do you do that without:
1. changing the items under what you're about to select causing you to accidentally select the wrong option
2. communicate that there are update clearly
3. ensure the UI is consistent when slower loading entries might not fit the same dimensions as the space allocated for the list (if you dynamically size your completions to fit the screen real estate)
4. ensure that there's still something present while you're lazy loading the rest of the suggestions; and that those early entries on the completion list are worthwhile and accurate
5. what about sorting the list? Alphabetical? By feature? etc
The REPL in murex was inspired by IDEs so I've spent a lot of time trying to consider how to provide the best UX around autocompletion. One thing I've learnt is that it's a lot harder to get right than it seems on the surface.
Pipefish
-
Charm 0.4: a different kind of functional language
Charm is a language where Functional-Core/Imperative-Shell is the language paradigm and not just something you can choose to do in Python or Ruby or PHP or JS or your favorite lightweight dynamic language. Because of the sort of use-cases that this implies, it didn't seem suitable to write another Lisp or another ML, so I got to do some completely blank-slate design. This gives us Charm, a functional language which has no pattern-matching, no currying, no monads, no macros, no homoiconicity, nor a mathematically interesting type system — but which does have purity, referential transparency, immutability, multiple dispatch, a touch of lazy evaluation, REPL-oriented development, hotcoding, microservices … and SQL interop because everyone's going to want that.
-
Charm 0.4: now with ... stability. And reasons why you should care about it.
I think it's fair to call this a language announcement because although I've been posting here about this project for a loooong time, I've finally gotten to what I'm going to call a "working prototype" as defined here. Charm has a complete core language, it has libraries and tooling, it has some new and awesome features of its own. So … welcome to Charm 0.4! Installation instructions are here. It has a language tutorial/manual/wiki, besides lots of other documentation; people who just want to dive straight in could look at the tutorial Writing an Adventure Game in Charm.
-
Programming in Plain Language?
In my own language there is some syntactic flexibility but the only thing that describe pretty table could mean would be the second of the possibilities above; the first would be expressed by describe prettyTable and the third by describe PRETTY, table. This makes it more readable from the point of view of a coder, and who else is going to want to read it, my mom?
-
Embedding other languages in Charm: a draft
I've been trying to think of a way of doing this which is simple and consistent and which can be extended by other people, so if someone wanted to embed e.g. Prolog in Charm they could do it without any help from me.
-
Lazy Let: A Cheap Way and Easy Way to Add Lazyness
Charm does this for declaration of local constants in functions (there are no local variables in functions). So for example if you wanted to write the Collatz function this way (which you wouldn't, it's just a minimal example) then you could do so without worrying about a computational explosion:
-
[OC] Median yearly salaries in the US for all programming languages with more than 200 respondents in the StackOverflow Developer Survey
I guess it's time for me to put aside my exploration of Charm and set up a collaboration with my son the lyricist.
-
Global and local variables, a choice of evils
In fact that's how a lot of Charm programs end up getting written, because you want to pass a whole bundle of stuff to the functions. For example.
-
What the imperative shell of an Functional Core/Imperative Shell language looks like
No, it's "shell" as in "shell of the code". The idea is that the imperative bits of the language, the bits that do the mutation of state and the IO, can can call lovely pure referentially transparent functions. But functions can't call commands (otherwise by definition they wouldn't be pure). So all your imperative-ness is reduced to about 1% of your code which lives right at the top of your call stack --- the "imperative shell" of your code. See [here](https://github.com/tim-hardcastle/Charm/blob/main/examples/adv.ch) for an example. The "imperative shell" is the main function --- all 13 lines of it --- and everything everywhere else is pure and immutable.
-
What are some cool things you've built using your own language?
I'm not sure what counts as cool. It's just dogfooding at the moment. I did a bunch of other languages (only the BASIC and the Forth are up to date with the current version of the language I think), and I did a tiny adventure game (and used it as the basis for a tutorial).
- Langception VIII: Ourobouros — I wrote Forth in Charm again
What are some alternatives?
Lisp-in-Charm
utop - Universal toplevel for OCaml
stshell
sprig - Useful template functions for Go templates.
hush - Hush is a unix shell based on the Lua programming language
butter - A tasty language for building efficient software. WIP
u-boot - "Das U-Boot" Source Tree
wyvern - The Wyvern programming language.
shelljs - :shell: Portable Unix shell commands for Node.js
subtex - Lightweight latex-like language for authoring books
go-regex - A High Performance PCRE Regex Package That Uses A Cache.
Skript - Skript is a Bukkit plugin which allows server admins to customize their server easily, but without the hassle of programming a plugin or asking/paying someone to program a plugin for them.