On 12/18/2012 11:41 AM, H. S. Teoh wrote:
>> What is required for w.o.r.e. is a specification for the source code
>> that precludes undefined and implementation defined behavior.
> [...]
>
> What would you do with system-specific things like filesystem
> manipulation, though? That has to be implementation-defined by
> definition. And IME, any abstraction that's both (1) completely-defined
> without any implementation differences and (2) covers every possible
> platform that ever existed and will exist, is either totally useless
> from being over-complex and over-engineered, or completely fails to
> capture the complexity of real-world systems and the details required to
> work with them efficiently.

Well, I was thinking of the language, not the runtime library, which is a separate issue.

And no, I don't think D can be a systems language *and* eliminate all undefined and implementation defined behavior.

On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
> On 12/18/2012 10:29 AM, Peter Alexander wrote:
>> On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
>>> Javascript proves that bytecode is not required for "write once, run
>>> everywhere", which was one of the pitches for bytecode.
>>>
>>> What is required for w.o.r.e. is a specification for the source code that
>>> precludes undefined and implementation defined behavior.
>>
>> Yes, bytecode isn't strictly required, but it's certainly desirable. Bytecode is
>> much easier to interpret, much easier to compile to, and more compact.
>
> Bytecode would have added nothing to js but complexity.
>
> I think you're seriously overestimating the cost of compilation.

When I say "easier", I'm talking about implementation cost. Consider how easy it is to write a conforming Java byte code interpreter compared to a conforming Java interpreter/compiler. Parsing and semantic analysis are much easier to get wrong than a byte code spec. At the bytecode level, you don't need to worry about function overloading, symbol tables, variable scoping, type inference, forward references etc. etc.  All those things are intentional complexities meant to make life easier for the programmer, not the computer. A bytecode doesn't need them.


>> The downside of bytecode is loss of high-level meaning... but that depends on
>> the bytecode. There's nothing stopping the bytecode from being a serialised AST
>> (actually, that would be ideal).
>
> As I pointed out to Andrei, Java bytecode *is* a serialized AST.

It's not a lossless serialisation -- especially not after optimisation. For example, it's non-trivial to reconstruct the AST of a for loop from optimised bytecode (or even regular bytecode).

On 12/18/2012 12:38 PM, Peter Alexander wrote:
> On Tuesday, 18 December 2012 at 19:25:01 UTC, Walter Bright wrote:
>> On 12/18/2012 10:29 AM, Peter Alexander wrote:
>>> On Tuesday, 18 December 2012 at 18:11:37 UTC, Walter Bright wrote:
>>>> Javascript proves that bytecode is not required for "write once, run
>>>> everywhere", which was one of the pitches for bytecode.
>>>>
>>>> What is required for w.o.r.e. is a specification for the source code that
>>>> precludes undefined and implementation defined behavior.
>>>
>>> Yes, bytecode isn't strictly required, but it's certainly desirable. Bytecode is
>>> much easier to interpret, much easier to compile to, and more compact.
>>
>> Bytecode would have added nothing to js but complexity.
>>
>> I think you're seriously overestimating the cost of compilation.
>
> When I say "easier", I'm talking about implementation cost. Consider how easy it
> is to write a conforming Java byte code interpreter compared to a conforming
> Java interpreter/compiler. Parsing and semantic analysis are much easier to get
> wrong than a byte code spec. At the bytecode level, you don't need to worry
> about function overloading, symbol tables, variable scoping, type inference,
> forward references etc. etc.  All those things are intentional complexities
> meant to make life easier for the programmer, not the computer. A bytecode
> doesn't need them.

D is open source. There is little implementation cost to doing a compiler for it. It's a solved problem.

A bytecode requires another spec to be written, and if you think it's easy to make a conformant Java VM bytecode interpreter, think again :-)


>>> The downside of bytecode is loss of high-level meaning... but that depends on
>>> the bytecode. There's nothing stopping the bytecode from being a serialised AST
>>> (actually, that would be ideal).
>>
>> As I pointed out to Andrei, Java bytecode *is* a serialized AST.
>
> It's not a lossless serialisation -- especially not after optimisation. For
> example, it's non-trivial to reconstruct the AST of a for loop from optimised
> bytecode (or even regular bytecode).

Yes, it is trivial. The only thing that is lost are local variable names and comments.

On Tuesday, 18 December 2012 at 21:30:04 UTC, Walter Bright wrote:
> D is open source. There is little implementation cost to doing a compiler for it. It's a solved problem.
>

Let me emit some doubt about that.

First, D is difficult to compile because of the compile time features. DMD frontend is not the best piece of software I've seen on an extensibility point of view.

Plus, if D is open source in its license, it isn't in its way of doing things. When you drop functionality into master for reason the community isn't even aware of, you don't act like in an open source project. You'll find a huge gap between adopting a license and adopt the cultural switch that is required to benefit from open source.

Right now, it is painfully hard to implement a D compiler, for various reasons :
 - No language spec exists (and dmd, dlang.org and TDPL often contradict each others).
 - The language spec change constantly.
 - Sometime by surprise !
 - Many behavior now considered as standard are historical dmd quirks, that are hard to reproduce in any implementation not based on dmd.
 - Nothing can be anticipated because goals are not publics.
 - Sometime you'll find 2 specs (-property) for the same thing.
 - Many things are deprecated but it is pretty hard to know which one.
 - It in unknown how to resolve paradoxes created by compile time features.
 - I can go on and on.

Right now only dmd based front end are production quality, and almost no tooling exists around the language. You'll find very good reasons for that in the points listed above.

> A bytecode requires another spec to be written, and if you think it's easy to make a conformant Java VM bytecode interpreter, think again :-)
>

Nobody ever said that.

> Yes, it is trivial. The only thing that is lost are local variable names and comments.

You'll find tools that compact your whole project, loosing in the process all names.

On 12/18/12 3:35 PM, Walter Bright wrote:
> And no, I don't think D can be a systems language *and* eliminate all
> undefined and implementation defined behavior.

The SafeD subset takes care of that.

Andrei

On 12/18/2012 1:57 PM, deadalnix wrote:
>> Yes, it is trivial. The only thing that is lost are local variable names and
>> comments.
>
> You'll find tools that compact your whole project, loosing in the process all
> names.

I believe you're conflating releasing a "whole project" with what I'm talking about, which is releasing modules meant to be incorporated into a user project, which won't work if the names are changed.

And besides, changing the names doesn't change the fact that Java .class files include 100% of the type information.

On Tue, Dec 18, 2012 at 07:08:04PM -0500, Andrei Alexandrescu wrote:
> On 12/18/12 3:35 PM, Walter Bright wrote:
> >And no, I don't think D can be a systems language *and* eliminate all undefined and implementation defined behavior.
> 
> The SafeD subset takes care of that.
[...]

Which right now suffers from some silly things like writefln not being able to be made @safe, just because some obscure formatting parameter is un@safe. Which is exactly how @safe was designed, of course.  Except that it makes SafeD ... a bit of a letdown, shall we say? - when it comes to practical real-world applications.

(And just to be clear, I'm all for SafeD, but it does still have a ways
to go.)


T

-- 
Elegant or ugly code as well as fine or rude sentences have something in common: they don't depend on the language. -- Luca De Vitis

Without bytecode, the entire compiler becomes a dependency of a AOT/JIT compiled program.. not only does bytecode allow for faster on-site compilations, it also means half the compiler can be stripped away (so i'm told, i'm not claiming to be an expert here).

I'm actually kinda surprised there hasn't been more of a AOT/JIT compiling push within the D community.. D's the best there is at code specialization, but half of that battle seems to be hardware specifics only really known on-site... like SIMD for example. I've been told many game companies compile against SIMD 3.1 because that's the base-line x64 instruction set. If you could query the hardware post-distribution (vs pre-distribution) without any performance loss or code complication (to the developer), that would be incredibly idea. (ps. I acknowledge that this would probably _require_ the full compiler, so there's probably not be to much value in a D-bytecode).

The D compiler is small enough for distribution I think (only ~10mb compressed?), but the back-end license restricts it right?

On 12/18/12 7:29 PM, H. S. Teoh wrote:
> On Tue, Dec 18, 2012 at 07:08:04PM -0500, Andrei Alexandrescu wrote:
>> On 12/18/12 3:35 PM, Walter Bright wrote:
>>> And no, I don't think D can be a systems language *and* eliminate all
>>> undefined and implementation defined behavior.
>>
>> The SafeD subset takes care of that.
> [...]
>
> Which right now suffers from some silly things like writefln not being
> able to be made @safe, just because some obscure formatting parameter is
> un@safe. Which is exactly how @safe was designed, of course.  Except
> that it makes SafeD ... a bit of a letdown, shall we say? - when it
> comes to practical real-world applications.
>
> (And just to be clear, I'm all for SafeD, but it does still have a ways
> to go.)

Yes, there are several bugs related to SafeD.

Andrei

On Tue, 18 Dec 2012, Andrei Alexandrescu wrote:

> On 12/18/12 7:29 PM, H. S. Teoh wrote:
> > Which right now suffers from some silly things like writefln not being able to be made @safe, just because some obscure formatting parameter is un@safe. Which is exactly how @safe was designed, of course.  Except that it makes SafeD ... a bit of a letdown, shall we say? - when it comes to practical real-world applications.
> > 
> > (And just to be clear, I'm all for SafeD, but it does still have a ways
> > to go.)
> 
> Yes, there are several bugs related to SafeD.
> 
> Andrei

Are the remaining issues at the compiler, runtime, or phobos levels (or what combination of the three)?  Are the bugs filed?