Hi,

dmt is an old project of mine from around year 2006. I ported it recently from D1 to D2, and added some extra features and support for extra keywords, and fixed few bugs here and there.

dmt is a converter (offline or auto-invoking compiler after conversion) from Python-like indention style to curly braces for D programming language.

https://github.com/baryluk/dmt

It is fun and easy to use, and maybe it would be of interested to you.

example.dt:

def int f(int b):
    int y = 0
    foreach (i; 0..5):
      y += i * (i+b)
    return y

struct A:
    private:
    int a
    public:
    int b_ = 5
    def auto b() @property:
        return b_

def void main():
    import std
    writefln!"%s %s"(f(5), A())

$ DMD=ldc2 dmt -run example.dt
ldc2 -run example.d
80 A(0, 5)
$

All D programming language features are supported (including exception handling, if/else, switch/case/break, inline asm, attribute sections, goto). Converted code is human readable.

You can check more examples in the README.md and in tests/ directory.

dmt is not yet self hosting, but that is probably the next step. :)

Enjoy.

On Tuesday, 16 November 2021 at 21:58:24 UTC, Witold Baryluk wrote:

Nice, remember to put it on dub

On Tuesday, 16 November 2021 at 21:58:24 UTC, Witold Baryluk wrote:

To be frank, by just Python syntax alone I wasn't sure how many people want to try it.

I'm wondering if it can translate existing Python code (e.g with a bit py3 type annotations) to D code, then it may attract much more users.

What I have also in mind is numpy program to lib Mir.

On Tuesday, 16 November 2021 at 21:58:24 UTC, Witold Baryluk wrote:

I love the idea. Never been a fan of braces to define blocks and I find them to be much more of a pain to match than whitespace. These days however, I just set dfmt to autorun on file save and never worry about formatting again.

On Wednesday, 17 November 2021 at 08:28:07 UTC, mw wrote:

There are good reasons for it.

1. It enforces indentations, so code is harder to screw up. Also because you need to indent, it often is easier to spot too deep nesting, and fix it, instead of hiding it.

2. From my experience with porting few small programs (50-1000 lines) to dmt, the resulting code is shorter than original D code, by about 15% on average. This is mostly due to closing } being removed:

3. It might be of interest to people who know Python, but do not know C, C++ or Java.

No. And not planned. Sparkling some auto here and there manually, makes it quite possible tho. I did port on Python program to dmt rather quickly. But of course if you use standard library, things are harder.

Cheers.

On Tuesday, 16 November 2021 at 21:58:24 UTC, Witold Baryluk wrote:

def int f(int b):
    int y = 0
    foreach (i; 0..5):
      y += i * (i+b)
    return y

struct A:
    private:
    int a
    public:
    int b_ = 5
    def auto b() @property:
        return b_

def void main():
    import std
    writefln!"%s %s"(f(5), A())

$ DMD=ldc2 dmt -run example.dt
ldc2 -run example.d
80 A(0, 5)
$

Isn't def redundant in this since D already declares types then you can assume if it's not enum, template, mixin template, class, struct or union then it must be a function if it also end with (...):

Like:

```d
int foo():
    return 10
```

You'd never be in doubt that foo was a function or that:

```d
template Foo(T):
    alias Foo = T
```

Foo in this case was a template.

Or like make def optional at least, because I see how it can help porting Python code, but it seems unnecessary if you're writing from scratch.

Great project tho!

On Friday, 19 November 2021 at 10:03:00 UTC, bauss wrote:

```d
int foo():
    return 10
```

```d
template Foo(T):
    alias Foo = T
```

Technically yes, but I do not have full proper parser or grammar,
to do the conversion in all possible cases.

The main issue is with the context:

type name ... can be also a start of a variable with a lambda, even if it ends with ::

auto x = delegate(int y):
   return y * y

The return type itself can be a complex template instantiation.

F!(....) foo():

Same with argument types, they might be templates (or maybe even mixins?).

Plus it does not necessarily ends with (...):, for example it can have attributes:

... (...) pure nothrow @bar:

Plus of course all the other things like static, public, extern(...), ... at the front.

So yes, dmt is not perfect, but for now it still allows to use full feature set of D, and use simple rules for achieving these goals.

If the tool gains some popularity, there is certainly a possibly of adding a proper grammar and parser, and making def on functions optional. Proper parser will also help in few other places, like multi line signature definitions, comments in the middle of the multi line definition, enum definitions and array literals.

BTW.

I forgot to add to my initial post, that dmt generates the #line directives, making compile errors and warning from dmd, gdc and ldc point back exactly to the proper input .dt file and original line number in it.

And you can pass multiple file to dmt tool, including mix of .dt and non-.dt files (i.e. .d, .o) to link them all together by the compiler in expected fashion.

Thanks.

On Wednesday, 17 November 2021 at 11:00:46 UTC, JN wrote:

I am programming in Python mostly on my job and sometimes in C++ and JavaScript. Personally I like syntax with braces to define blocks more that Python's syntax without blocks.
One of the reasons - why?1 Is that very often when I copy-paste some fragments of code then some editors sometimes just tries to autoindent programme and does it wrong. Then it breaks entirely and I get some errors from production just because of this.
And just for aestetic reasons I like when blocks are explicitly delimitered by braces.
Syntax with braces also allows write "one-liners" easier when it's needed.
So personall I shall not use this in D

On Wednesday, 17 November 2021 at 17:23:14 UTC, Witold Baryluk wrote:

Just FYI: I found a working Python PEG grammar file here

https://github.com/we-like-parsers/pegen/blob/main/data/python.gram

it will be a great helper to to trans-compile Python to D.

E.g. to try parse Python code and execute the parsed code:

git clone https://github.com/we-like-parsers/pegen
cd pegen
make demo

(I did that PR :-)

On Monday, 28 March 2022 at 22:22:18 UTC, mw wrote:

git clone https://github.com/we-like-parsers/pegen
cd pegen
make demo

Transcompilers are fun, but a heads-up before you get too invested in this, you'll either need to restrict the python code to a particular subset of python, or accept that you'll be writing a python interpreter in D, and not transpiling.