On 12/21/2012 12:37 AM, Rainer Schuetze wrote:
>
>
> On 21.12.2012 08:02, Walter Bright wrote:
>> On 12/20/2012 10:05 PM, deadalnix wrote:
>>> No you explained that java's bytecode doesn't solve that problem.
>>> Which is quite
>>> different.
>>
>> I did, but obviously you did not find that satisfactory. Let me put it
>> this way:
>>
>> Design a bytecode format, and present it here, that is CTFEable and is
>> not able to be automatically decompiled.
>
> Sorry, can't resist: How about feeding the x86 machine byte code (including some
> fixup information) into an interpreter? Maybe not realistic, but a data point in
> the field of possible "byte codes". The interpreter might even enjoy hardware
> support ;-)

Not going to work, as CTFE needs type information. CTFE needs to interact with the current symbols and types in the compilation unit.

Just think about what you'd need to do to get CTFE to read the object file for a module and try to execute the code in it, feeding it data and types and symbols from the current compilation unit? Consider:

    add EAX,37
    mov [EAX],EBX

what the heck is EAX pointing at?

On 12/21/2012 2:13 AM, Max Samukha wrote:
> What Walter is wrong about is that bytecode is entirely pointless.

I'll bite. What is its advantage over source code?

On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
> On 12/21/2012 2:13 AM, Max Samukha wrote:
>> What Walter is wrong about is that bytecode is entirely pointless.
>
> I'll bite. What is its advantage over source code?

Interpreting the AST directly: Requires recursion.
Interpreting a (stack based) bytecode: Does not require recursion.

That's what an AST to bytecode tranformation does; it eliminates the recursion. And that is far from being useless.

On 12/21/2012 2:37 AM, Araq wrote:
> On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
>> On 12/21/2012 2:13 AM, Max Samukha wrote:
>>> What Walter is wrong about is that bytecode is entirely pointless.
>>
>> I'll bite. What is its advantage over source code?
>
> Interpreting the AST directly: Requires recursion.
> Interpreting a (stack based) bytecode: Does not require recursion.
>
> That's what an AST to bytecode tranformation does; it eliminates the recursion.
> And that is far from being useless.

Sorry, I don't get this at all. Every bytecode scheme I've seen had a stack and recursion.

Furthermore, that's not an argument that transmission of code (and importation of modules) is better done as bytecode than source code.

On Friday, 21 December 2012 at 10:37:05 UTC, Araq wrote:
> On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
>> On 12/21/2012 2:13 AM, Max Samukha wrote:
>>> What Walter is wrong about is that bytecode is entirely pointless.
>>
>> I'll bite. What is its advantage over source code?
>
> Interpreting the AST directly: Requires recursion.
> Interpreting a (stack based) bytecode: Does not require recursion.
>
> That's what an AST to bytecode tranformation does; it eliminates the recursion. And that is far from being useless.

It don't think that this is such a big deal. Either way you need one stack: either the call stack or the stack machine's stack. It doesn't seem to make a big difference.
Am I wrong?

On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
> On 12/21/2012 2:13 AM, Max Samukha wrote:
>> What Walter is wrong about is that bytecode is entirely pointless.
>
> I'll bite. What is its advantage over source code?

It is not about bytecode vs source code. It is about a common platform-independent  intermediate representation for multiple languages. JS is such a representation in the browsers and it is widely used. It it entirely pointless? I am not convinced it is.

On Friday, 21 December 2012 at 11:00:01 UTC, Max Samukha wrote:
> On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
>> On 12/21/2012 2:13 AM, Max Samukha wrote:
>>> What Walter is wrong about is that bytecode is entirely pointless.
>>
>> I'll bite. What is its advantage over source code?
>
> It is not about bytecode vs source code. It is about a common platform-independent  intermediate representation for multiple languages. JS is such a representation in the browsers and it is widely used. It it entirely pointless? I am not convinced it is.

Another example. Many of us here are talking in an intermediate language, which not English :) The concept of a common representation works pretty well here.

On 21.12.2012 10:20, Timon Gehr wrote:
> On 12/21/2012 09:37 AM, Rainer Schuetze wrote:
>>
>>
>> On 21.12.2012 08:02, Walter Bright wrote:
>>> On 12/20/2012 10:05 PM, deadalnix wrote:
>>>> No you explained that java's bytecode doesn't solve that problem.
>>>> Which is quite
>>>> different.
>>>
>>> I did, but obviously you did not find that satisfactory. Let me put it
>>> this way:
>>>
>>> Design a bytecode format, and present it here, that is CTFEable and is
>>> not able to be automatically decompiled.
>>
>> Sorry, can't resist: How about feeding the x86 machine byte code
>> (including some fixup information) into an interpreter? Maybe not
>> realistic,
>
> http://bellard.org/jslinux/

Incredible ;-)

>
>> but a data point in the field of possible "byte codes". The
>> interpreter might even enjoy hardware support ;-)
>>
>
> Direct hardware support is not achievable because CTFE needs to be pure
> and safe.
>

True, you would have to trust the library code not to do unpure/unsafe operations. Some of this might be verifiable, e.g. not allowing fixups into mutable global memory.


>> That might not cover all possible architectures, but if the distributed
>> library is compiled for one platform only, CTFEing against another won't
>> make much sense anyway.
>>
>

On 21.12.2012 11:28, Walter Bright wrote:
> On 12/21/2012 12:37 AM, Rainer Schuetze wrote:
>>
>>
>> On 21.12.2012 08:02, Walter Bright wrote:
>>> On 12/20/2012 10:05 PM, deadalnix wrote:
>>>> No you explained that java's bytecode doesn't solve that problem.
>>>> Which is quite
>>>> different.
>>>
>>> I did, but obviously you did not find that satisfactory. Let me put it
>>> this way:
>>>
>>> Design a bytecode format, and present it here, that is CTFEable and is
>>> not able to be automatically decompiled.
>>
>> Sorry, can't resist: How about feeding the x86 machine byte code
>> (including some
>> fixup information) into an interpreter? Maybe not realistic, but a
>> data point in
>> the field of possible "byte codes". The interpreter might even enjoy
>> hardware
>> support ;-)
>
> Not going to work, as CTFE needs type information. CTFE needs to
> interact with the current symbols and types in the compilation unit.
>
> Just think about what you'd need to do to get CTFE to read the object
> file for a module and try to execute the code in it, feeding it data and
> types and symbols from the current compilation unit? Consider:
>
>      add EAX,37
>      mov [EAX],EBX
>
> what the heck is EAX pointing at?
>

I think you don't need to care. The CPU can execute it as well without type information.

If the data layout of the interpreter values is the same as for the interpreted architecture, all you need to know is the calling convention and the types of the arguments to the function to be executed and the return type.
I'd intercept calls to other functions because the interpreter might want to replace them with non-native versions (e.g. new or functions where the source code exists). The types of the data passed when executing these calls are known as well.

On 2012-00-21 12:12, Max Samukha <maxsamukha@gmail.com> wrote:

> On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
>> On 12/21/2012 2:13 AM, Max Samukha wrote:
>>> What Walter is wrong about is that bytecode is entirely pointless.
>>
>> I'll bite. What is its advantage over source code?
>
> It is not about bytecode vs source code. It is about a common platform-independent  intermediate representation for multiple languages. JS is such a representation in the browsers and it is widely used. It it entirely pointless? I am not convinced it is.

But Walter has said that for exactly this purpose, bytecode is useful.
What he's said is that in the case proposed (using bytecode instead of
source code for CTFE), bytecode offers absolutely no advantage over
source.

Now can we move on? It's been said so many times now, and we all know
Walter is not a pushover. If nobody can present irrefutable, solid,
peer-reviewed, and definite proof that bytecode has significant
advantages over source code for the purpose of CTFE, such an
implementation will never be done, and the world will be better off
for it.

-- 
Simen