Am 14.07.2012 14:52, schrieb Timon Gehr:
> On 07/14/2012 01:29 PM, Gor Gyolchanyan wrote:
>>
>> It would also make run-time mixins possible, which is absolutely amazing.
>>
>
> It is amazingly unsafe, because at runtime there is no distinction
> between strings generated by the program and strings created from input
> to the program.
>

as everything that works based on input data - its only the context what makes any type of input (and handling) unsafe

think of an system that needs an fast interpreter for a small subset of the D language - why should i use lua, python or something else here? - the runtime-mixing wouldn't be unsage if generated by the interpreting D program...

the other thing is: would you vote against such a feature if it were already there?

the next thing would be the D compiler as a library - then we can use D (better rdmd) as a hyper-powerful make

and yes i know - everything is possible by invoking dmd executable and some lib magic - but integrating it (better - make it part of the language standard) would be far better - then D can compete with java, .net and all the others having this feature-set already (seems to be that someone needs stuff like that)

On Sat, Jul 14, 2012 at 6:47 PM, dennis luehring <dl.soluz@gmx.net> wrote:

> Am 14.07.2012 14:52, schrieb Timon Gehr:
>
>  On 07/14/2012 01:29 PM, Gor Gyolchanyan wrote:
>>
>>>
>>> It would also make run-time mixins possible, which is absolutely amazing.
>>>
>>>
>> It is amazingly unsafe, because at runtime there is no distinction between strings generated by the program and strings created from input to the program.
>>
>>
> as everything that works based on input data - its only the context what makes any type of input (and handling) unsafe
>
> think of an system that needs an fast interpreter for a small subset of the D language - why should i use lua, python or something else here? - the runtime-mixing wouldn't be unsage if generated by the interpreting D program...
>
> the other thing is: would you vote against such a feature if it were already there?
>
> the next thing would be the D compiler as a library - then we can use D (better rdmd) as a hyper-powerful make
>
> and yes i know - everything is possible by invoking dmd executable and some lib magic - but integrating it (better - make it part of the language standard) would be far better - then D can compete with java, .net and all the others having this feature-set already (seems to be that someone needs stuff like that)
>
>
>
Hear hear!!!

-- 
Bye,
Gor Gyolchanyan.

Am 14.07.2012 15:23, schrieb Kevin Cox:
> On Jul 14, 2012 9:15 AM, "David" <d@dav1d.de> wrote:
>>>
>>> Run-time mixins can be used for incredibly powerful stuff, yet the same
>>> run-time mixins can be used for incredibly dangerous stuff. Just don't
>>> use them if you don't know exactly what you're doing. :-)
>>
>>
>> I don't see any case where a "runtime-mixin" is the only solution (it's
> definitly the unsafest)
>>
>
> Yes, eval or exec is pretty much outlawed in other languages, I can only
> imagine the same would happen in D.
>

i wouldn't say unsafe a long as there is no definition for "runtime-mixing", maybe the interface is fixed, maybe you can't introduce variables etc. in the outerscope

the difference between writing a textfile, run the compiler load the code isn't more unsafe then doing it inline - and the feature isn't missing because of safety concers - its just didn't there

On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:
> On Sat, Jul 14, 2012 at 6:35 PM, Alex Rønne Petersen <alex@lycus.org
> <mailto:alex@lycus.org>> wrote:
>
>     On 14-07-2012 12:48, Gor Gyolchanyan wrote:
>
>         I just got an amazing thought. If we end up getting a D
>         front-end in D,
>         I think it would be possible to make the back-end in the same
>         space as
>         the code being compiled. This means, having the back-end as a
>         library
>         solution. This would automatically provide 100% compile-time code
>         introspection. This is just a thought. Not a proposal or
>         anything. What
>         do you guys think?
>
>         --
>         Bye,
>         Gor Gyolchanyan.
>
>
>     I can't tell if you're advocating writing a back end in D as well.
>     If you are, I am strongly against this. There's a reason it has
>     taken 10 years for LLVM to get where it is, and it's still far from
>     complete. We have better things to do with development of D than
>     reinventing the wheel.
>
>     --
>     Alex Rønne Petersen
>     alex@lycus.org <mailto:alex@lycus.org>
>     http://lycus.org
>
>
> I didn't expect D to have it. D follows tons of anti-patterns, that
> other languages have followed. It's yet another language with yet
> another set of insignificant changes. It IS the best one of all, but
> it's not even close to being at least minimally useful for a really big
> task.
>

Big words.

> For instance, everybody seems to love hard-wiring the syntax into the
> language.
>

Insignificant example.

Every language _needs_ to have a standard source storage format.

On Saturday, 14 July 2012 at 10:48:56 UTC, Gor Gyolchanyan wrote:
> I just got an amazing thought. If we end up getting a D front-end in D, I
> think it would be possible to make the back-end in the same space as the
> code being compiled. This means, having the back-end as a library solution.
> This would automatically provide 100% compile-time code introspection. This
> is just a thought. Not a proposal or anything. What do you guys think?

Compile-time code introspection is a job for the front-end. It's not very good to have code introspect itself at compile-time using a library... that would mean the library loads, parses and analyzes the very same code that the compiler has already loaded, parsed and analyzed. Sounds quite inefficient, and is it even legal to read files at compile time, and how would you know what paths to read?

Having the front+back-end as a library would, of course, be handy for run-time code generation, which definitely is useful place too. In C# there's a handy library called RunSharp for that, and I miss it in C++. It would, however, mean bundling a complete compiler with your application, so the solution feels very heavy (as compared to the .NET framework, where developers can take for granted that the user's machine already has the libraries.)

I think, for multiple reasons including this use case, D should have a "lightweight subset" with a smaller standard library and a somewhat simpler language definition (that retains most of D's power), which could shrink the size of a program that uses runtime codegen. For simplicity, the D front-end written in D could use the same backend for CTFE as for its output. And one hopes that generated code could be garbage-collected.

However, presumably you'd have to include LLVM which I believe is around 1MB for a bare-minimum build (with no optimization passes included.)

On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:
>
>> On Sat, Jul 14, 2012 at 6:35 PM, Alex Rønne Petersen <alex@lycus.org <mailto:alex@lycus.org>> wrote:
>>
>>     On 14-07-2012 12:48, Gor Gyolchanyan wrote:
>>
>>         I just got an amazing thought. If we end up getting a D
>>         front-end in D,
>>         I think it would be possible to make the back-end in the same
>>         space as
>>         the code being compiled. This means, having the back-end as a
>>         library
>>         solution. This would automatically provide 100% compile-time code
>>         introspection. This is just a thought. Not a proposal or
>>         anything. What
>>         do you guys think?
>>
>>         --
>>         Bye,
>>         Gor Gyolchanyan.
>>
>>
>>     I can't tell if you're advocating writing a back end in D as well.
>>     If you are, I am strongly against this. There's a reason it has
>>     taken 10 years for LLVM to get where it is, and it's still far from
>>     complete. We have better things to do with development of D than
>>     reinventing the wheel.
>>
>>     --
>>     Alex Rønne Petersen
>>     alex@lycus.org <mailto:alex@lycus.org>
>>
>>     http://lycus.org
>>
>>
>> I didn't expect D to have it. D follows tons of anti-patterns, that other languages have followed. It's yet another language with yet another set of insignificant changes. It IS the best one of all, but it's not even close to being at least minimally useful for a really big task.
>>
>>
> Big words.
>
>
>  For instance, everybody seems to love hard-wiring the syntax into the
>> language.
>>
>>
> Insignificant example.
>
> Every language _needs_ to have a standard source storage format.
>

Syntax has nothing to do with standard source stage. Why won't the standard source stage be binary, while leaving the human-written part (the syntax) up to the writer?

-- 
Bye,
Gor Gyolchanyan.

On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:
>
>> On Sat, Jul 14, 2012 at 6:35 PM, Alex Rønne Petersen <alex@lycus.org <mailto:alex@lycus.org>> wrote:
>>
>>     On 14-07-2012 12:48, Gor Gyolchanyan wrote:
>>
>>         I just got an amazing thought. If we end up getting a D
>>         front-end in D,
>>         I think it would be possible to make the back-end in the same
>>         space as
>>         the code being compiled. This means, having the back-end as a
>>         library
>>         solution. This would automatically provide 100% compile-time code
>>         introspection. This is just a thought. Not a proposal or
>>         anything. What
>>         do you guys think?
>>
>>         --
>>         Bye,
>>         Gor Gyolchanyan.
>>
>>
>>     I can't tell if you're advocating writing a back end in D as well.
>>     If you are, I am strongly against this. There's a reason it has
>>     taken 10 years for LLVM to get where it is, and it's still far from
>>     complete. We have better things to do with development of D than
>>     reinventing the wheel.
>>
>>     --
>>     Alex Rønne Petersen
>>     alex@lycus.org <mailto:alex@lycus.org>
>>
>>     http://lycus.org
>>
>>
>> I didn't expect D to have it. D follows tons of anti-patterns, that other languages have followed. It's yet another language with yet another set of insignificant changes. It IS the best one of all, but it's not even close to being at least minimally useful for a really big task.
>>
>>
> Big words.
>
>
>  For instance, everybody seems to love hard-wiring the syntax into the
>> language.
>>
>>
> Insignificant example.
>
> Every language _needs_ to have a standard source storage format.
>

Big words? Some languages are pretty much useless for generic type-agnostic code. They either limit to compile-time templates (eliminating polymorphism) or just refuse to support it. Other languages are obsessed with dynamic typing (like Python), which eliminate modeling power.

And where is the progress here? Same semi-useful type system as C++ with a few sprinkles on it.

-- 
Bye,
Gor Gyolchanyan.

On 07/14/2012 05:24 PM, Gor Gyolchanyan wrote:
> On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <timon.gehr@gmx.ch
> <mailto:timon.gehr@gmx.ch>> wrote:
>
>     On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:
>
>         ...
>         For instance, everybody seems to love hard-wiring the syntax
>         into the
>         language.
>
>
>     Insignificant example.
>
>     Every language _needs_ to have a standard source storage format.
>
>
> Syntax has nothing to do with standard source stage. Why won't the
> standard source stage be binary,

Obviously syntax has to do with standard source storage. The syntax
definition can be binary just fine, eg:

http://en.wikipedia.org/wiki/Binary_lambda_calculus


> while leaving the human-written part (the syntax)

That is not the definition of _the_ syntax.

> up to the writer?
>

This is already the case. Writing a parser that transforms your custom syntax to the standard syntax is trivial.

The reason why almost nobody is doing this is the same as the reason
why almost everyone strives to stick to the same English orthography
rules.

On Sat, Jul 14, 2012 at 7:36 PM, Timon Gehr <timon.gehr@gmx.ch> wrote:

> On 07/14/2012 05:24 PM, Gor Gyolchanyan wrote:
>
>> On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <timon.gehr@gmx.ch <mailto:timon.gehr@gmx.ch>> wrote:
>>
>>     On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:
>>
>>         ...
>>
>>         For instance, everybody seems to love hard-wiring the syntax
>>         into the
>>         language.
>>
>>
>>     Insignificant example.
>>
>>     Every language _needs_ to have a standard source storage format.
>>
>>
>> Syntax has nothing to do with standard source stage. Why won't the standard source stage be binary,
>>
>
> Obviously syntax has to do with standard source storage. The syntax definition can be binary just fine, eg:
>
> http://en.wikipedia.org/wiki/**Binary_lambda_calculus<http://en.wikipedia.org/wiki/Binary_lambda_calculus>
>
>
>
>  while leaving the human-written part (the syntax)
>>
>
> That is not the definition of _the_ syntax.
>
>  up to the writer?
>>
>>
> This is already the case. Writing a parser that transforms your custom syntax to the standard syntax is trivial.
>
> The reason why almost nobody is doing this is the same as the reason why almost everyone strives to stick to the same English orthography rules.
>

Comparison to English is invalid, because English is extensible. The terms and their meanings are completely up to the users of the language, while programming languages are pretty much fixed, while providing a handful of pre-defined abstractions.

-- 
Bye,
Gor Gyolchanyan.

On 07/14/2012 05:28 PM, Gor Gyolchanyan wrote:
> On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <timon.gehr@gmx.ch
> <mailto:timon.gehr@gmx.ch>> wrote:
>
>     On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:
>
>         On Sat, Jul 14, 2012 at 6:35 PM, Alex Rønne Petersen
>         <alex@lycus.org <mailto:alex@lycus.org>
>         <mailto:alex@lycus.org <mailto:alex@lycus.org>>> wrote:
>
>              On 14-07-2012 12:48, Gor Gyolchanyan wrote:
>
>                  I just got an amazing thought. If we end up getting a D
>                  front-end in D,
>                  I think it would be possible to make the back-end in
>         the same
>                  space as
>                  the code being compiled. This means, having the
>         back-end as a
>                  library
>                  solution. This would automatically provide 100%
>         compile-time code
>                  introspection. This is just a thought. Not a proposal or
>                  anything. What
>                  do you guys think?
>
>                  --
>                  Bye,
>                  Gor Gyolchanyan.
>
>
>              I can't tell if you're advocating writing a back end in D
>         as well.
>              If you are, I am strongly against this. There's a reason it has
>              taken 10 years for LLVM to get where it is, and it's still
>         far from
>              complete. We have better things to do with development of D
>         than
>              reinventing the wheel.
>
>              --
>              Alex Rønne Petersen
>         alex@lycus.org <mailto:alex@lycus.org> <mailto:alex@lycus.org
>         <mailto:alex@lycus.org>>
>
>         http://lycus.org
>
>
>         I didn't expect D to have it. D follows tons of anti-patterns, that
>         other languages have followed. It's yet another language with yet
>         another set of insignificant changes. It IS the best one of all, but
>         it's not even close to being at least minimally useful for a
>         really big
>         task.
>
>
>     Big words.
>     [snip.]
>
> Big words? Some languages are pretty much useless for generic
> type-agnostic code. They either limit to compile-time templates
> (eliminating polymorphism)

I take that to mean C++ or D.
I concur that parametric polymorphism is handy to have.

> or just refuse to support it.
> Other languages are obsessed with dynamic typing (like Python), which
> eliminate modeling power.

I don't see how that would eliminate modeling power (on the contrary).
What it constrains is static checking and runtime performance.

>
> And where is the progress here? Same semi-useful type system as C++ with
> a few sprinkles on it.
>

I was not claiming anything else. There were unsupported claims that D
is the best programming language of all and useless for a really big
task.