TIL: Tcl-inspired command language on top of D

> The De facto super set of D code will always be D.

Well, I'd like to make it clear that creating a "de facto super set of D" is not my objective, anyway.

But I'd like to say that, although compiled languages are nice and D is really amazing, I don't even dream of using D to create some quick-and-dirty scripts, the same way I don't even dream of using Til to create shell scripts (I never met any general-purpose language that served as a nice shell, Tcl being the closest one, but still - it's not a traditional shell and the experience is only tolerable, IMHO).

Furthermore, it's also not my objective with Til, but I believe, anyway, that a nice scripting language on top of D would prove very beneficial to the language - it's interesting to try it, right? At least to see what happens...

To clarify a bit on the difference between DasBetterC and ImportC:

DasBetterC is what its name suggests, it's for C lovers who enjoy programming in C, but:

1. are sick and tired of buffer overflows

2. want to do metaprogramming but realize that metaprogramming with the C preprocessor is barbaric

3. want modules and struct member functions

4. don't want a runtime other than the C standard library

ImportC is a straight up ISO C11 compiler. It's not for programming in (although you can do it easily enough), it's so D can directly access your existing C code, without having to tediously translate it to D.

To that end, ImportC doesn't warn about execrable coding practice, the error messages are utilitarian, and has no extra features. If ISO C11 says it's ok, ImportC stamps it with approval.

The question is why not? If creating a superset languages based on D will encourage more people to use D either directly or indirectly me think it's really worth it.

Please check Terra language (now in beta), on how they created Lua like language to enable easier optimization in C++ and other languages [1]. They reported Terra-based autotuner for BLAS routines performs within 20% of ATLAS, and DSL for stencil computations that runs 2.3x faster than hand-written C [2].

According to D language origins paper, D is meant to be general-purpose programming language with support for procedural, object-oriented, generic, generative, and functional programming [3]. It'll be a shame not to fully utilize the powerful nature of D. In addition, D also supports D language compiler DMD as a library [4], and there's also libDSL, a library for developing embedded domain specific languages in D via template metaprogramming [5].

[1]https://terralang.org/

[2]https://terralang.org/pldi071-devito.pdf

[3]https://dl.acm.org/doi/pdf/10.1145/3386323

[4]https://dlang.org/blog/2017/08/01/a-dub-case-study-compiling...

[5]https://dl.acm.org/doi/10.1145/2658761.2658770

Thanks for the replies, very informative.

For the background on the prototyping aspect of Lua, you can check this excellent blog post from Steve Yegge [1].

Regarding Python for data scientist, the type A is happy but not type B. The main reason the ill-fated Swift for TensorFlow project was proposed, is to better serve type B data scientists [2].

[1]http://steve-yegge.blogspot.com/2008/10/universal-design-pat...

[2]https://www.tensorflow.org/swift/guide/overview

People expect whitespace to be either 'indifferent' or 'significant'.

Indifferent is the default: it means you only need whitespace when tokens would otherwise parse wrong, like `symbol1234` vs. `symbol 1234`. Also, you can add as much as you want, the parser doesn't care.

Significant means that whitespace is semantic, meaningful. This almost always means depth of indentation, although I've encountered other semantic whitespaces in the wild.

Sometimes lining things up just looks nicer. Here's an example of how I like to construct a literal Lua table:

    local colors = { black  =  0x000000, 
                     white  =  0xffffff,
                     red    =  0xff0000,
                     blue   =  0x0000ff,
                     green  =  0x00ff00, }

Lots of whitespace! Two spaces on either side of the longest equals, for the longest symbol, and left-alignment on the keys.

I don't like this nearly so much:

    local colors = { black = 0x000000, 
                     white = 0xffffff,
                     red = 0xff0000,
                     blue = 0x0000ff,
                     green = 0x00ff00, }

The hex values are all over the place, it makes it harder to read them and see the pattern. Consider a collection of binary flags as another example where you really want the right column to line up.

You could choose to right-align the left column, so that the equals are in the same place and the right column lines up, but why should you? Then you miss the semantic indentation. They're columns, I want to column align them.

I support no tabs, though :D we share religion on that one.

The use case is that vertical alignment of code can often makes it easier to read.

It's the mark of a rigid parser that should not impose such limitations.