D 2.069.0 released, compiler automatically ported from C++ to D • Hacker News Board

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#51

Post by WalterBright » Wed, Nov 04, 2015, 4:07 PM UTC

pjmlp wrote: post #38

Zardoz84 wrote: post #24

Earlier quoted context omitted.

Using the previous version write on C++. Like all compilers of other languages did when change to be write on his own language. Or do you think that the first version of C compiler was write on C ?

Funny anecdote for compiler researchers. Niklaus Wirth did write many of his compilers in the original language (kind of). He would write down on paper the code, using the bootstrap version 0 code style, as it was supposed to be. Then he would manually translate that code into Assembly. So when the compiler for the basic language was working, he could use the same code again, without additional efforts and relying on…

Computer languages were a lot simpler in those days.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#52

Post by WalterBright » Wed, Nov 04, 2015, 4:09 PM UTC

yokohummer7 wrote: post #48

ogezi wrote: post #26

D is a really amazing language that manages to correct the mistakes of c++ but still retain its good parts. it's a shame that it's not more popular.

To me, while D fixes many warts of C++, D is still too similar to C++ to justify the change. It still has implicit numeric cast, exception unsafety and strange behaviors.[1] In addition, the D authors are generally opposed to disciplined approaches, e.g. type classes, region-based memory management, which are being added to C++. Especially regarding the former, while "design by introspection" may have its merits (And…

> It still has implicit numeric cast,

Implicit numeric casts that lose bits are not allowed anymore.

> exception unsafety

??

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#53

Post by steveklabnik » Wed, Nov 04, 2015, 4:09 PM UTC

knocte wrote: post #50

pornel wrote: post #19

Earlier quoted context omitted.

C translates almost 1:1 to Rust, but when converting C++ to Rust you'll run into impedance mismatch between OO hierarchies and traits, and generics being narrower in functionality than templates. In Rust you still can do "clever" things with generics to make them feel like C++, but the rest of the language is still closer to C: errors returned rather than thrown, no inheritance (but the "flat" OO and enums map well t…

> errors returned rather than thrown WHATT??? did they do the same mistake as Go?

No. There's a few things that combine to make it different, but what it really boils down to are enums. Rust functions that can fail return a type, Result: http://doc.rust-lang.org/std/result/enum.Result.html

There's a number of things that make using this ergonomic: you can use the try! macro to convert it to a success value, returning an error value up the stack. You can use any of the combination methods on that page to chain various possibly-failing functions together into something that looks nice. Some people even use the word "monadic." We don't have if checks everywhere.

For more than you probably want to know on error handling in Rust, this guide just hit stable: https://doc.rust-lang.org/book/error-handling.html

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#54

Post by WalterBright » Wed, Nov 04, 2015, 4:11 PM UTC

thepumpkin1979 wrote: post #36

Not sure what I do wrong every time I try D again, I wanted to see the new backtraces worked but I still get: /bin/bash: line 1: 82501 Segmentation fault: 11 ./main while I try to call a method on a null variable, which is not that friendly to newcomers. Sample code: import std.stdio; void main() { Greetings g = null; g.hola(); }

That code won't compile because Greetings is undefined. Hence, you may be running some other program which seg faults.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#55

Post by lucozade » Wed, Nov 04, 2015, 4:26 PM UTC

knocte wrote: post #50

pornel wrote: post #19

Earlier quoted context omitted.

C translates almost 1:1 to Rust, but when converting C++ to Rust you'll run into impedance mismatch between OO hierarchies and traits, and generics being narrower in functionality than templates. In Rust you still can do "clever" things with generics to make them feel like C++, but the rest of the language is still closer to C: errors returned rather than thrown, no inheritance (but the "flat" OO and enums map well t…

> errors returned rather than thrown WHATT??? did they do the same mistake as Go?

It depends on what mistake you mean.

Having errors on return has merits. Particularly it make error handling more deterministic. What it tends to do though, in languages like C and Go, is be very verbose.

Rust largely mitigates that through judicious usage of some of its higher levels features. Specifically its try! macro wrap up the common case of passing errors up the call stack quite neatly. With that and the pervasive RAII, Rust does a pretty good job of making error management quite unobtrusive.

It also has quite a nice way of converting errors types using traits that, in my opinion at least, handles typed error propagation better than most exception mechanisms I am familiar with.

From a personal pov, I like the determinism and I like the type conversion. I probably prefer D's scope mechanism to RAII in general as I like thinks to be as explicit as possibly but without being too verbose. But I think Rust seems to have hit quite a nice balance.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#56

Post by yokohummer7 » Wed, Nov 04, 2015, 4:30 PM UTC

WalterBright wrote: post #52

yokohummer7 wrote: post #48

Earlier quoted context omitted.

To me, while D fixes many warts of C++, D is still too similar to C++ to justify the change. It still has implicit numeric cast, exception unsafety and strange behaviors.[1] In addition, the D authors are generally opposed to disciplined approaches, e.g. type classes, region-based memory management, which are being added to C++. Especially regarding the former, while "design by introspection" may have its merits (And…

> It still has implicit numeric cast, Implicit numeric casts that lose bits are not allowed anymore. > exception unsafety ??

> Implicit numeric casts that lose bits are not allowed anymore.

That's good to hear, but I want implicit conversion to be forbidden unconditionally (even int * float -> float). I've been bitten by even widening conversions, so I just want to let them go away. It might be great if such an option could be applied to module level.

> ??

Sorry if my understandings or my words were wrong, but I got the impression that D also suffers from destructors that throw. (double-throw) Is this not the case in D? If so, could you elaborate how it achieves that?

I'm personally rather fond of purging exceptions from the language level completely, like Go did(Of course panics are technically exceptions, but their usage is culturally discouraged). Of course, this is just my personal opinion, but I would be happy if D had a story on this problem.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#57

Post by Zardoz84 » Wed, Nov 04, 2015, 4:33 PM UTC

thepumpkin1979 wrote: post #36

Not sure what I do wrong every time I try D again, I wanted to see the new backtraces worked but I still get: /bin/bash: line 1: 82501 Segmentation fault: 11 ./main while I try to call a method on a null variable, which is not that friendly to newcomers. Sample code: import std.stdio; void main() { Greetings g = null; g.hola(); }

1) Where is Greetings defined ?

2) Spanish ?

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#58

Post by thepumpkin1979 » Wed, Nov 04, 2015, 4:47 PM UTC

lultimouomo wrote: post #49

thepumpkin1979 wrote: post #42

Earlier quoted context omitted.

I think so: $ dmd -g main.d && ./main Segmentation fault: 11 is there anything else I can try? I'm OSX El Capitan 10.11.1

On Unix segfaults by default don't generate stack traces. This makes it work on linux, don't know about OSX (put it in your main module): import etc.linux.memoryerror; shared static this() { static if (is(typeof(registerMemoryErrorHandler))) registerMemoryErrorHandler(); }

The handler works in a real ubuntu VM but not in docker (the image is probably missing glibc https://github.com/D-Programming-Language/druntime/blob/mast... so that explains "static if" in your snippet)

to be honest, it's better than nothing but still kinda difficult to work with:

  etc.linux.memoryerror.NullPointerError@src/etc/linux/memoryerror.d(325)
  ----------------
  ??:? void etc.linux.memoryerror.sigsegvUserspaceProcess(void*) [0x439045]
  ??:? void etc.linux.memoryerror.sigsegvDataHandler() [0x438f92]
  ??:? _Dmain [0x435c17]
  ??:? _D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv [0x4376da]
  ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x437630]
  ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0x437696]
  ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x437630]
  ??:? _d_run_main [0x43758d]
  ??:? main [0x436075]
  ??:? __libc_start_main [0xb0fa1ec4]

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#59

Post by hasenj » Wed, Nov 04, 2015, 4:48 PM UTC

pjmlp wrote: post #38

Zardoz84 wrote: post #24

Earlier quoted context omitted.

Using the previous version write on C++. Like all compilers of other languages did when change to be write on his own language. Or do you think that the first version of C compiler was write on C ?

Funny anecdote for compiler researchers. Niklaus Wirth did write many of his compilers in the original language (kind of). He would write down on paper the code, using the bootstrap version 0 code style, as it was supposed to be. Then he would manually translate that code into Assembly. So when the compiler for the basic language was working, he could use the same code again, without additional efforts and relying on…

That's kinda how lisp came to life, wasn't it? It was supposed to be a theoretical exercise, but someone took the "lisp in lisp" code and manually compiled it to assembly.

Re: D 2.069.0 released, compiler automatically ported from C++ to D

#60

Post by chubot » Wed, Nov 04, 2015, 4:50 PM UTC

WalterBright wrote: post #2

Daniel Murphy is the man behind getting the sources converted from C++ to D. He wrote a program called "magicport" to do the bulk of it, with some manual tweaking. The back end is still in C++, showing that you can mix D and C++ code :-)

Hm this sounds just like the port of the Go compiler from C to Go. In that case it was C and Go, rather than C++ and D.