Ignorant thoughts

[tom-huntington]

In a DSL for shell scripting, executables should be first class citizens. I think Haskell's function call syntax could be used and executables could then be treated as variadic functions (or just a monadic function taking a string).

I think the unix philosophy should be more tightly adhered to. I don't want to learn DSL specific function names like Program

if Program('foo') { ... }

when I just could do

if which foo { ... }.

I think result/error types should be used instead of exceptions, but you need to have succinct monadic composition of these https://github.com/TartanLlama/optional

In general, I think you can learn a lot from recent c++ proposals, they're stealing the useful parts from functional programming and trying to make the language "pythonic" https://brevzin.github.io/c++/2019/08/22/ufcs-custom-extension/

The minimalism of Luna and Nix Expression Language is a good thing for a DSL (although I think their type systems need a sum type).

I think bash does a lot right. What bash does wrong is scoping and type safety. Closures/lambdas/destructuring would be needed to tighten up the scoping. And I want to be kept safe from mixing expressions and strings.

Also you may want to improve you SEO by changing the github description. I had trouble finding this project. I was googling shell scripting language, shell DSL, and bash replacement.

[ilyash-b]

Thanks for the feedback! I'll need to get to it (needs some thinking and processing). Currently I'm very limited time-wise.

[ilyash-b]

Executables & DSL

In a DSL for shell scripting, executables should be first class citizens.

I think we should get into details here. What do you think should be supported exactly?

I don't want to learn DSL specific function names like Program

Hmm.. That's somewhat surprising to me. Shell is a DSL. What's more natural than having domain specific types? For example Program. Than you have Program object in boolean context (checks if exists) or for example you can do assert(Program("foo")) which has no clear alternative in bash (in my opinion).

which

... kind of part of "standard library" in bash, except that the library as a whole and in particular is not that standard . Anyhow, there is nothing wrong with if $(which foo) {...} from NGS perspective.

---

Edit: I'll be replying to other parts as time allows

[ilyash-b]

UFCS

UFCS is supported in NGS. Together with multiple-dispatch it is at the core of the language.

From https://brevzin.github.io/c++/2019/08/22/ufcs-custom-extension/

In this post, I wanted to go over how well these proposals solve the problems they set out to solve.

None of which seem to be applicable. That's the advantage of green field language design. Support UFCS from the start and you are an pretty good shape. NGS does not have classes. There are only types and methods. Method calls support UFCS.

[ilyash-b]

Result types

One of the guiding principles in NGS is that "small scripts don't suffer". In case of error handling that manifests as exceptions. In many cases you don't care about errors and you just want the script to stop when one occurs. That's exactly what happens with exceptions.

• NGS has Result type, please take a look at https://ngs-lang.org/doc/latest/generated/Result.html
• NGS has Box type (with EmptyBox and FullBox subtypes which I think are so much easier to remember) aka optional/maybe in other languages. See https://ngs-lang.org/doc/latest/generated/Box.html

In practice though, for me, the use of these is pretty rare compared to exceptions.

I am open to specific proposals about result types for NGS though. I think that CS is not there yet and both exceptions and result types are subpar solutions. From the two bad solutions I picked the one that was less bad in my opinion.

[ilyash-b]

bash

What bash does wrong is scoping and type safety.

I would like to add some points from my perspective (in order of importance):

• Error handling (and https://ilya-sher.org/2018/09/09/bash-pitfall-if-test-if-if/)
• Missing data structures
• Syntax

Edit: also treating your terminal as dumpster that mixes stdout+stderr from multiple processes and doesn't limit the amount of output to human-processable amount.

[tom-huntington]

Sorry, I was kind of having a mental break down and shouldn't have written that. I don't think any of my input will be valuable, but I'll give some follow up thoughts to show my support.

&& and | in bash are effectively monadic binds of a maybe/optional type where the exit code decides if it is empty or not

[[ -n "$BASH_VERSION" ]] \
  && command1 \
  && command2

I think a new style/syntax for command substitutions, piping, and redirection could be invented using ideas from haskell's do notation. The relevant part of the UFCS post was towards the end, which talks gives a starting point for how this could be done.

Where in Elixir, we would write x |> f(y), in Hack we would have to write x |> f($$, y), both of which evaluate directly as f(x, y). But Hack also would allow the writing of x |> f(y, $$), which means f(y, x). More explicit, yet more flexible.

i.e. for command substitution, one could expand upon something like

date
  |> echo "Today is $$"

I believe that invocable |> east is far superior to west(invocable) . It opens up possibilities that only do notation has started to explore. It removes brackets from nested expressions, and allows you to write one operation per line.

Food for thought

command1 \
  | command2 \
  | command3 \
  | command4

[ilyash-b]

mental break down

Sorry to hear that. Hope you are better now.

where the exit code decides if it is empty or not

Not sure how it fits the exceptions model which is already chosen and widely used in the language. I thought it eliminates the need to use &&.

for command substitution

date
  |> echo "Today is $$"

Looks interesting, I need to think about this.

[tom-huntington]

Not sure how it fits the exceptions model which is already chosen and widely used in the language. I thought it eliminates the need to use &&.

Fair enough, although I'm in the exceptions only for process shutdown camp, because it makes the control flow implicit whereas optional is explicit. But I don't really do shell scripting so what would I know it.