stshell
grammars-v4
Our great sponsors
stshell | grammars-v4 | |
---|---|---|
2 | 29 | |
0 | 9,786 | |
- | 1.4% | |
0.0 | 9.6 | |
over 2 years ago | 6 days ago | |
Smalltalk | ANTLR | |
- | 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.
stshell
-
Evennia a MUD/Mu* Creation System
It's slowly getting traction - Kotlin on Android has a "live update" feature (in development, only available in alpha release), for example. Multiple less mainstream languages also offer the feature. Nim got it in the last major release, for example. V has it as one of the base features. Erlang and Elixir had it since forever. Common Lisp as well. Racket and Clojure are a little more limited than CL, but also support it. Many interpreted languages offer some degree of this, either by default (JavaScript) or as a library/package (Python, Ruby).
In general, programming language features take about 20 to 30 years to go from obscure niche implementation into the mainstream. Look at lambdas - anonymous function literals - they're now everywhere, including Java and C++. Ten years ago, though, only some scripting languages had it. The feature itself is as old as the bones of the Earth (LISP, 1960, 63 years old). The same is true for many other "advanced" features. I think this is tied to generational changes - each generation of programmers has a chance to bring one or two lesser known features into mainstream, and then they're content with that. Other features have to wait for the next generation to discover them.
As for Smalltalk - I made a mistake and based the implementation on GNU Smalltalk, which is unmaintained. I should have gone with Smalltalk/X, Visual Works, or (begrudgingly) Pharo (or Cuis). I started the project as yet another attempt at making a MUD, but then changed focus to making a productive command-line-based programming env for Smalltalk. Then I changed my mind again and tried to make it into a usable shell. Here's the project: https://github.com/piotrklibert/stshell/ The screenshots focus on the REPL/shell side, but in the source you'll see things like "server", "player", and "world". There are a few locations IIRC and you can move your character between them still. It was an interesting project, but without a clear vision of what it should be it lost focus and I left it to rot after a while :(
-
Guide: Hush Shell-Scripting Language
> We need better shells.
Obviously. I don't think this is the most important missing part, though. I would say it differently: we need way, way better REPLs.
IPython is an example of a REPL that's passable as a shell. It can run in a terminal and has a GUI version based on Qt, which allows displaying images inline. You can drop into a "real" shell with a single `!` character (you get pipes, output capture, and (Python) variable interpolation), and it even has some syntactic shortcuts for the parts where Python's own syntax is irritatingly verbose. If you like Python, then IPython can be your day-to-day shell right now. You just need to remember not to start ncurses programs from within qtconsole (works ok in terminal). I used it for a few years when I was forced to work on Windows. Before my time, I heard it was popular to use tclsh as a shell on Windows.
I think that it proves that almost any language can be used as a shell, as long as its REPL is as rich and featureful enough. Since you can use Python as a shell, which as a language is not exactly the epitome of terseness and expressiveness, you could definitely make do with almost any other interpreted language, too. The problem is that very, very few languages have REPLs that are anywhere near IPython. It's so bad sometimes that you're advised to use `rlwrap` just to get basic line editing and history!
I've been working on a new shell based on GNU Smalltalk[1]. I really like the syntax - or lack of thereof - and being able to dump an image at any time seemed like a good idea. The only change I needed was to add the `|>` pseudo-operator, which puts what's on the left into parens. Being able to introspect the running session was my primary motivation: I wanted to make the shell and the whole environment as discoverable as possible. I wrote some code for that and then realized that the default REPL uses readline from C, so it freezes the entire VM when waiting for input (including all background threads). My workaround was to set up a socket server and connect to it via rlwrapped telnet...
Anyway, I think "do we need a new shell" is the wrong question; instead, we should focus on improving REPLs to the point where a separate shell becomes unnecessary.
[1] https://github.com/piotrklibert/stshell
grammars-v4
- Operadores de adição e subtração
-
Visual Basic for Applications Language Specification [pdf]
Perhaps the one from ANTLR's collection [0] is a good start (there are also others ANTLR VB6 grammars documented elsewhere). It does require knowing ANTLR, but that should be less effort for someone already familiar with language implementation, particularly, the visitor pattern (my favorite reference [1]).
[0] https://github.com/antlr/grammars-v4/tree/master/vb6
[1] https://craftinginterpreters.com/representing-code.html
-
Postgres Language Server: Implementing the Parser
Where is the SQLite test suite, please? I'd be very interested.
There are already SQL grammars, check https://github.com/antlr/grammars-v4 specifically in here I think https://github.com/antlr/grammars-v4/tree/master/sql I contributed to one of them, and I wrote my own for some personal work. Be warned, it's very involved, very complex and MSSQL is rather ill-defined.
Names bracket identifiers) in SQL are bloody awful. Sometimes square brackets are even compulsory, and why you can usually replace [...] with the SQL standard "..." , not always! Trust me, it gets worse.
I don't find antlr grammars to be brittle, and while they can lose in performance (by how much I don't know, perhaps quite considerably) they are very easy to maintain and I am very fortunate to have antlr to work with.
-
Llama: Add Grammar-Based Sampling
This grammar "library" was cited as an example of what the format could look like:.
https://github.com/antlr/grammars-v4
There is everything from assembly and C++ to glsl and scripting languages, arithmetic, games, and other weird formats.
-
Structured Output from LLMs (Without Reprompting!)
> Which brings me to the other approach: steering the LLM's output __as it is generating tokens__
A relevant PR:
https://github.com/ggerganov/llama.cpp/pull/1773
The plan is to support arbitrary grammar files to constrain tokens as they are generated, like the ones here:
https://github.com/antlr/grammars-v4
-
SQL-Parsing
Have a look at jooq - I know this has been used to rewrite SQL from one dialect to another, so it MUST be capable of collating code activity metrics. Look here. Otherwise, you might want to look into writing your own parser. ANTLR has a T-SQL dialect parser script here.
-
How should I prepare for AI-driven changes in the industry as a Software Engineering Manager
Find a Perl grammar file for ANTLR, like https://github.com/antlr/grammars-v4/tree/master/perl Save the grammar file as Perl.g4 in your project. Now, you can create the Kotlin program: import org.antlr.v4.runtime.* import org.antlr.v4.runtime.tree.ParseTree import java.io.File
- Can you create a cpp file in a program like you could a txt file?
-
DELD: An experimental HTTP-Client
Antlr is another option. You could generate a parser using the JSON antlr grammar.
- Are there any resources available to convert a code from Basic to C++? need to do this for the sake of an assignment. anything will be helpful
What are some alternatives?
busybox - The Swiss Army Knife of Embedded Linux - private tree
ANTLR - ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.
readline - Pure Go reimplimentation of readline
tree-sitter-sql - SQL grammar for tree-sitter
lash - A modern, robust glue language
lezer-snowsql
Wormies-AU-Helpers - Helper scripts to make maintaining packages using AU even easier
rewrite - Automated mass refactoring of source code.
u-boot - "Das U-Boot" Source Tree
tree-sitter-sql - SQL syntax highlighting for tree-sitter
oil - Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!
go-mysql-server - A MySQL-compatible relational database with a storage agnostic query engine. Implemented in pure Go.