On 07/14/2012 05:42 PM, Gor Gyolchanyan wrote:
> On Sat, Jul 14, 2012 at 7:36 PM, Timon Gehr <timon.gehr@gmx.ch
> <mailto: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>
>         <mailto: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,

They need to agree on a common set of terms and meanings.

> while programming languages are pretty much fixed, while providing a
> handful of pre-defined abstractions.
>

As I already argued, programming languages are just as extensible. Depending on the amount of extensions, you might have to write your own
compiler.

On 14/07/2012 15:33, Gor Gyolchanyan wrote:
> On Sat, Jul 14, 2012 at 5:23 PM, Kevin Cox <kevincox.ca@gmail.com
> <mailto:kevincox.ca@gmail.com>> wrote:
>
>
>     On Jul 14, 2012 9:15 AM, "David" <d@dav1d.de <mailto: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.
>
>
> That's a huge mistake a lot of people make. They outlaw things that they
> don't understand or don't know how to use. As I said: having something
> doesn't mean using it. Those who can use it - will use it. Those who
> can't - won't.
>

One usually don't want to qualify him/herself as incompetent and will use it anyway.

I see some beneficial uses for that, but definitively 99% of the time this is madness.

On Saturday, 14 July 2012 at 13:33:16 UTC, Gor Gyolchanyan wrote:
>>
>> Yes, eval or exec is pretty much outlawed in other languages, I can only
>> imagine the same would happen in D.
>>
>
> That's a huge mistake a lot of people make. They outlaw things that they
> don't understand or don't know how to use. As I said: having something
> doesn't mean using it. Those who can use it - will use it. Those who can't
> - won't.

And those who can use it for wrongdoing will. This alone completely destroys the feature imho.

On Sun, Jul 15, 2012 at 7:21 PM, SomeDude <lovelydear@mailmetrash.com>wrote:

> On Saturday, 14 July 2012 at 13:33:16 UTC, Gor Gyolchanyan wrote:
>
>>
>>> Yes, eval or exec is pretty much outlawed in other languages, I can only imagine the same would happen in D.
>>>
>>>
>> That's a huge mistake a lot of people make. They outlaw things that they don't understand or don't know how to use. As I said: having something doesn't mean using it. Those who can use it - will use it. Those who can't - won't.
>>
>
> And those who can use it for wrongdoing will. This alone completely destroys the feature imho.
>

It doesn't have to be a black/white choice. How about analyzing and caching the code before executing it at run time? If the code is analyzed and proved to be safe - then it's executed without hesitation. Yes, it'll require a lot of work to pull this off.

-- 
Bye,
Gor Gyolchanyan.

On Saturday, 14 July 2012 at 15:18:53 UTC, David Piepgrass wrote:
>
> 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.)

I support this idea. This simpler subset would be targetted at embedded devices.

I would imagine a sub-D without generic programming and CTFE, for instance. The resulting language would retain much enough functionality for rewriting a bootstrapping compiler.