This repository has been archived by the owner on Sep 20, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
universal-shell/wip
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
Implementation Status (work in progress) ========================================== * Grammar: 99.99% done but new ideas come up every day... * Shell: implementation sorted out & working on the basic modules... * Language: The C/C++ Programming Language This is not a dead project. ;-) Planned features: - I/O Redirection (non-blocking pipelines all the way) - Background Jobs (sure) - Deferred Commands (could be more dangerous with this shell language) - Subshells (could be useful without openning a new shell) - Null Expansion Error (empty expansion stings; still has nullable expansion) - Variable Scopes (default to local scope; no implicit block scopes) - Namespaces (for module management) - Ternary Logic (needed for the 21st century) - Globbing (fail glob, null glob, fail/null regexp) - Cartesian Products (just like bash's {a,b,c}{1,2,3}) - Multi-line Strings (no here documents; echo "<multiple lines>" | cat) - String Interpolations (any handy shell script needs this feature) - Array, Unordered Map, Ordered Map (containers for text) - Perl Compatible Regular Expressions (power without perl) - Arbitrary-precision Arithmetic (calculator included) - Command Auto-completion (ease the typing) - Event Listeners/Triggers (spooky at a distance) Why another shell program? ========================================== First of all, it is not a replacement of sh/bash/zsh/... It is not intended to rule the POSIX world. It is created because many (legacy) shells just f*ck my work style. * bash: arcane syntax, RTFM first * zsh: bloated syntax, must RTFM because too magical * rc: nice implementation, poor user interface and polluted env * fish: attractive but going bad, ugly details waiting inside * ????: why bother with another true (and ugly) programming language? Good-enough things are unbelievably great excuses to kill personal styles. Now I gotta try my own implementation. Goals: * ease of typing (well, mainly for US keyboards) * comprehensible syntax * no undefined behaviors * centralized UI configuration * finely commented source code * portable across unix-y systems Non-Goals: * posix-compliant * pipe structured data * interoperable with bash or other shells * one scripting language to rule the world * provide an escape-meta-alt-control-shift ide * rich multi-language/locale support (defects: os/encoding/font/terminal) In summary, the shell should ease your typing and provide a simple scripting language that is easy to learn and master, thus more time for fun projects. Scripting Language ========================================== The shell scripts will use a new scripting language. The actual look of it is left as an exercise for other shell developers. (May there be a *Unix Shell Haters' Handbook*?) Here is a checklist: Programming Language Checklist by Colin McMillen, Jason Reed, and Elly Jones. You appear to be advocating a new: [ ] functional [*] imperative [ ] object-oriented [*] procedural [ ] stack-based [ ] "multi-paradigm" [ ] lazy [ ] eager [ ] statically-typed [*] dynamically-typed [ ] pure [ ] impure [ ] non-hygienic [ ] visual [*] beginner-friendly [ ] non-programmer-friendly [ ] completely incomprehensible programming language. Your language will not work. Here is why it will not work. You appear to believe that: [*] Syntax is what makes programming difficult [*] Garbage collection is free [*] Computers have infinite memory [*] Nobody really needs: [ ] concurrency [ ] a REPL [ ] debugger support [*] IDE support [ ] I/O [ ] to interact with code not written in your language [ ] The entire world speaks 7-bit ASCII [ ] Scaling up to large software projects will be easy [*] Convincing programmers to adopt a new language will be easy [ ] Convincing programmers to adopt a language-specific IDE will be easy [ ] Programmers love writing lots of boilerplate [ ] Specifying behaviors as "undefined" means that programmers won't rely on them [*] "Spooky action at a distance" makes programming more fun Unfortunately, your language (has/lacks): [*] comprehensible syntax [?] semicolons [_] significant whitespace [_] macros [_] implicit type conversion [_] explicit casting [_] type inference [_] goto [_] exceptions [_] closures [?] tail recursion [_] coroutines [_] reflection [_] subtyping [_] multiple inheritance [_] operator overloading [_] algebraic datatypes [_] recursive types [_] polymorphic types [_] covariant array typing [_] monads [_] dependent types [_] infix operators [_] nested comments [*] multi-line strings [*] regexes [*] call-by-value [_] call-by-name [_] call-by-reference [_] call-cc The following philosophical objections apply: [*] Programmers should not need to understand category theory to write "Hello, World!" [*] Programmers should not develop RSI from writing "Hello, World!" [ ] The most significant program written in your language is its own compiler [*] The most significant program written in your language isn't even its own compiler [ ] No language spec [ ] "The implementation is the spec" [ ] The implementation is closed-source [ ] covered by patents [ ] not owned by you [ ] Your type system is unsound [ ] Your language cannot be unambiguously parsed [ ] a proof of same is attached [ ] invoking this proof crashes the compiler [ ] The name of your language makes it impossible to find on Google [*] Interpreted languages will never be as fast as C [ ] Compiled languages will never be "extensible" [*] Writing a compiler that understands English is AI-complete [ ] Your language relies on an optimization which has never been shown possible [ ] There are less than 100 programmers on Earth smart enough to use your language [ ] ____________________________ takes exponential time [ ] ____________________________ is known to be undecidable Your implementation has the following flaws: [*] CPUs do not work that way [*] RAM does not work that way [ ] VMs do not work that way [ ] Compilers do not work that way [ ] Compilers cannot work that way [ ] Shift-reduce conflicts in parsing seem to be resolved using rand() [ ] You require the compiler to be present at runtime [ ] You require the language runtime to be present at compile-time [ ] Your compiler errors are completely inscrutable [*] Dangerous behavior is only a warning [ ] The compiler crashes if you look at it funny [*] The VM crashes if you look at it funny [*] You don't seem to understand basic optimization techniques [*] You don't seem to understand basic systems programming [*] You don't seem to understand pointers [*] You don't seem to understand functions Additionally, your marketing has the following problems: [*] Unsupported claims of increased productivity [*] Unsupported claims of greater "ease of use" [ ] Obviously rigged benchmarks [ ] Graphics, simulation, or crypto benchmarks where your code just calls handwritten assembly through your FFI [ ] String-processing benchmarks where you just call PCRE [ ] Matrix-math benchmarks where you just call BLAS [*] Noone really believes that your language is faster than: [*] assembly [*] C [*] FORTRAN [*] Java [*] Ruby [*] Prolog [*] Rejection of orthodox programming-language theory without justification [ ] Rejection of orthodox systems programming without justification [ ] Rejection of orthodox algorithmic theory without justification [ ] Rejection of basic computer science without justification Taking the wider ecosystem into account, I would like to note that: [ ] Your complex sample code would be one line in: _______________________ [*] We already have an unsafe imperative language [ ] We already have a safe imperative OO language [ ] We already have a safe statically-typed eager functional language [*] You have reinvented Lisp but worse [ ] You have reinvented Javascript but worse [ ] You have reinvented Java but worse [ ] You have reinvented C++ but worse [ ] You have reinvented PHP but worse [ ] You have reinvented PHP better, but that's still no justification [ ] You have reinvented Brainfuck but non-ironically In conclusion, this is what I think of you: [ ] You have some interesting ideas, but this won't fly. [*] This is a bad language, and you should feel bad for inventing it. [ ] Programming in this language is an adequate punishment for inventing it.
About
A *work-in-progress* non-posix modern unix shell.
Topics
Resources
Stars
Watchers
Forks
Releases
No releases published
Packages 0
No packages published