Til, a command language written in D

[Cléber Zavadniak]

On Friday, 14 May 2021 at 22:18:50 UTC, Witold Baryluk wrote:

> Nice. Pretty clean syntax, and the implementation.

Thanks! I'm relatively new to D itself, I'll confess. Suggestions 
of improvements to the code are welcomed.


> I am not a fan of Tcl, but the Erlang influences are 
> definitively cool.

I myself find Tcl awesome. But it has a lot of flaws, too. I'm 
kind of trying to fix some of its issues, as well (the first 
versions of Til were labeled "a better Tcl").

(Also: a Tcl-based has the advantage that I can use its syntax 
highlighting satisfactorily on most of the cases.)

> I like sub processes and the piping.
>
> Do you have some example of running external processes / 
> commands.
> with `Til`? Composing pipes between external processes, and
> also between internal ones (maybe by some adapter that splits
> pipe data by lines?).

The module I published on Dub is 
[til_exec](https://code.dlang.org/packages/til_exec) and it runs 
commands and returns status and output, for now.

(I'm trying to avoid the "giant standard library included" path, 
so I prefer to release modules separately.)

There's a lot of things lacking right now, for sure: you can 
`exec` commands but there's no way, yet (future readers: please 
pay attention to the timestamp of this post. Thanks), of breaking 
the command output in multiple lines.

(An example I can think would be the following, but 
`string.split` is the lacking part, currently:)

```tcl
exec ls / | string.split "\n" | foreach line {
  io.out $line
}
```

Interestingly, Til *pipes* were not born actually focused on 
handling external commands I/O, unix-shell-style, despite the 
obvious similarity. The first pipes implementation was an attempt 
to avoid Tcl sometimes-weird nested-commands syntax (used a lot 
for indexing) for instance, like `set parts [file split [file 
rootname $file_path]]`. But it evolved to be a way of handling 
**data** in general, while function parameters were supposed to 
define mostly **behavior**.


> A good alternative to bash is always welcome ;D

Yeah... I don't know... Not following this goal right now. `bash` 
is still out there for some very good reasons, as far as I can 
see. Some things are just expected in a shell, like expanding 
`*`, and usually general-purpose programming languages just feel 
weird handling "shell things".

(But... who knows?...)