www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D front-end in D for D

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0401240babde7804c4c7efe6
Content-Type: text/plain; charset=UTF-8

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.

--f46d0401240babde7804c4c7efe6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I just got an amazing thought. If we end up getting a D front-end in D, I t=
hink it would be possible to make the back-end in the same space as the cod=
e being compiled. This means, having the back-end as a library solution. Th=
is would automatically provide 100% compile-time code introspection. This i=
s just a thought. Not a proposal or anything. What do you guys think?<br cl=
ear=3D"all">
<div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br>

--f46d0401240babde7804c4c7efe6--
Jul 14 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 14.07.2012 12:48, schrieb Gor Gyolchanyan:
 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.

This was the solution adopted by Microsoft and Mono guys for C# for the compiler as library. Oracle is now also rewritting the Hotspot JIT compiler in Java, to be integrated into Java 8 or later version, by building on the results of the Maxime project at Sun and the Jikes RVM projects. I'm usually an advocate of bootstraping languages as it makes a better testbed for the language, since you're experimenting how good the language really is. -- Paulo
Jul 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 14 2012
next sibling parent reply David <d dav1d.de> writes:
 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)
Jul 14 2012
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
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


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
Jul 14 2012
prev sibling parent deadalnix <deadalnix gmail.com> writes:
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.
Jul 14 2012
prev sibling parent dennis luehring <dl.soluz gmx.net> writes:
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)
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0407160bb17e4204c4c8819b
Content-Type: text/plain; charset=UTF-8

On Sat, Jul 14, 2012 at 3:16 PM, Paulo Pinto <pjmlp progtools.org> wrote:

 Am 14.07.2012 12:48, schrieb Gor Gyolchanyan:

  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.

This was the solution adopted by Microsoft and Mono guys for C# for the compiler as library. Oracle is now also rewritting the Hotspot JIT compiler in Java, to be integrated into Java 8 or later version, by building on the results of the Maxime project at Sun and the Jikes RVM projects. I'm usually an advocate of bootstraping languages as it makes a better testbed for the language, since you're experimenting how good the language really is. -- Paulo

It would also make run-time mixins possible, which is absolutely amazing. -- Bye, Gor Gyolchanyan. --f46d0407160bb17e4204c4c8819b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 3:16 PM, Paulo Pinto <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:pjmlp progtools.org" target=3D"_blank"=
pjmlp progtools.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=

"> Am 14.07.2012 12:48, schrieb Gor Gyolchanyan:<div><div class=3D"h5"><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I just got an amazing thought. If we end up getting a D front-end in D,<br> I think it would be possible to make the back-end in the same space as<br> the code being compiled. This means, having the back-end as a library<br> solution. This would automatically provide 100% compile-time code<br> introspection. This is just a thought. Not a proposal or anything. What<br> do you guys think?<br> <br> --<br> Bye,<br> Gor Gyolchanyan.<br> </blockquote> <br></div></div> This was the solution adopted by Microsoft and Mono guys for C# for the<br> compiler as library.<br> <br> Oracle is now also rewritting the Hotspot JIT compiler in Java, to be<br> integrated into Java 8 or later version, by building on the results of<br> the Maxime project at Sun and the Jikes RVM projects.<br> <br> I&#39;m usually an advocate of bootstraping languages as it makes a better<= br> testbed for the language, since you&#39;re experimenting how good the langu= age really is.<br> <br> --<br> Paulo<br> </blockquote></div><br>It would also make run-time mixins possible, which i= s absolutely amazing.<br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor Gy= olchanyan.<br> --f46d0407160bb17e4204c4c8819b--
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--e0cb4efe339057505b04c4c9c5bc
Content-Type: text/plain; charset=UTF-8

On Sat, Jul 14, 2012 at 4:52 PM, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 07/14/2012 01:29 PM, Gor Gyolchanyan wrote:

 It would also make run-time mixins possible, which is absolutely amazing.

between strings generated by the program and strings created from input to the program.

Messing with pointers is also dangerous. One of the points of D is not to ban dangerous stuff, but to warn about then and provide safer alternative. 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. :-) -- Bye, Gor Gyolchanyan. --e0cb4efe339057505b04c4c9c5bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 4:52 PM, Timon Gehr <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 07/14/2012 01:29 PM, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> It would also make run-time mixins possible, which is absolutely amazing.<b= r> <br> </blockquote> <br></div> It is amazingly unsafe, because at runtime there is no distinction<br> between strings generated by the program and strings created from input<br> to the program.<br> </blockquote></div><br>Messing with pointers is also dangerous. One of the = points of D is not to ban dangerous stuff, but to warn about then and provi= de safer alternative.<div><br></div><div>Run-time mixins can be used for in= credibly powerful stuff, yet the same run-time mixins can be used for incre= dibly dangerous stuff. Just don&#39;t use them if you don&#39;t know exactl= y what you&#39;re doing. :-)<br clear=3D"all"> <div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> </div> --e0cb4efe339057505b04c4c9c5bc--
Jul 14 2012
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
--e89a8fb1ed4aadf88004c4ca1a77
Content-Type: text/plain; charset=UTF-8

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


Yes, eval or exec is pretty much outlawed in other languages, I can only imagine the same would happen in D. --e89a8fb1ed4aadf88004c4ca1a77 Content-Type: text/html; charset=UTF-8 <p><br> On Jul 14, 2012 9:15 AM, &quot;David&quot; &lt;<a href="mailto:d dav1d.de">d dav1d.de</a>&gt; wrote:<br> &gt;&gt;<br> &gt;&gt; Run-time mixins can be used for incredibly powerful stuff, yet the same<br> &gt;&gt; run-time mixins can be used for incredibly dangerous stuff. Just don&#39;t<br> &gt;&gt; use them if you don&#39;t know exactly what you&#39;re doing. :-)<br> &gt;<br> &gt;<br> &gt; I don&#39;t see any case where a &quot;runtime-mixin&quot; is the only solution (it&#39;s definitly the unsafest)<br> &gt;</p> <p>Yes, eval or exec is pretty much outlawed in other languages, I can only imagine the same would happen in D.</p> --e89a8fb1ed4aadf88004c4ca1a77--
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d04088ee58839f104c4ca3cb8
Content-Type: text/plain; charset=UTF-8

On Sat, Jul 14, 2012 at 5:23 PM, Kevin Cox <kevincox.ca gmail.com> wrote:

 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


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. -- Bye, Gor Gyolchanyan. --f46d04088ee58839f104c4ca3cb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 5:23 PM, Kevin Cox <span= dir=3D"ltr">&lt;<a href=3D"mailto:kevincox.ca gmail.com" target=3D"_blank"=
kevincox.ca gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=

ex"> <div class=3D"HOEnZb"><div class=3D"h5"><p><br> On Jul 14, 2012 9:15 AM, &quot;David&quot; &lt;<a href=3D"mailto:d dav1d.de= " target=3D"_blank">d dav1d.de</a>&gt; wrote:<br> &gt;&gt;<br> &gt;&gt; Run-time mixins can be used for incredibly powerful stuff, yet the= same<br> &gt;&gt; run-time mixins can be used for incredibly dangerous stuff. Just d= on&#39;t<br> &gt;&gt; use them if you don&#39;t know exactly what you&#39;re doing. :-)<= br> &gt;<br> &gt;<br> &gt; I don&#39;t see any case where a &quot;runtime-mixin&quot; is the only= solution (it&#39;s definitly the unsafest)<br> &gt;</p> </div></div><p>Yes, eval or exec is pretty much outlawed in other languages= , I can only imagine the same would happen in D.</p> </blockquote></div><br>That&#39;s a huge mistake a lot of people make. They= outlaw things that they don&#39;t understand or don&#39;t know how to use.= As I said: having something doesn&#39;t mean using it. Those who can use i= t - will use it. Those who can&#39;t - won&#39;t.<div> <div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d04088ee58839f104c4ca3cb8--
Jul 14 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
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 http://lycus.org
Jul 14 2012
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 14 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 14 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0408da07c4145e04c4cb3c9d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Jul 14, 2012 at 6:35 PM, Alex R=C3=B8nne Petersen <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 f=

 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=C3=B8nne Petersen
 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. For instance, everybody seems to love hard-wiring the syntax into the language. --=20 Bye, Gor Gyolchanyan. --f46d0408da07c4145e04c4cb3c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 6:35 PM, Alex R=C3=B8nne= Petersen <span dir=3D"ltr">&lt;<a href=3D"mailto:alex lycus.org" target=3D= "_blank">alex lycus.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail= _quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:= 1ex"> <div class=3D"im">On 14-07-2012 12:48, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I just got an amazing thought. If we end up getting a D front-end in D,<br> I think it would be possible to make the back-end in the same space as<br> the code being compiled. This means, having the back-end as a library<br> solution. This would automatically provide 100% compile-time code<br> introspection. This is just a thought. Not a proposal or anything. What<br> do you guys think?<br> <br> --<br> Bye,<br> Gor Gyolchanyan.<br> </blockquote> <br></div> I can&#39;t tell if you&#39;re advocating writing a back end in D as well. = If you are, I am strongly against this. There&#39;s a reason it has taken 1= 0 years for LLVM to get where it is, and it&#39;s still far from complete. = We have better things to do with development of D than reinventing the whee= l.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> Alex R=C3=B8nne Petersen<br> <a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.org</a><br> <a href=3D"http://lycus.org" target=3D"_blank">http://lycus.org</a><br> </font></span></blockquote></div><br>I didn&#39;t expect D to have it. D fo= llows tons of anti-patterns, that other languages have followed. It&#39;s y= et another language with yet another set of insignificant changes. It IS th= e best one of all, but it&#39;s not even close to being at least minimally = useful for a really big task.<div> <br></div><div>For instance, everybody seems to love hard-wiring the syntax= into the language.<br clear=3D"all"><div><br></div>-- <br>Bye,<br>Gor Gyol= chanyan.<br> </div> --f46d0408da07c4145e04c4cb3c9d--
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--bcaec554d84233fd6404c4cb5681
Content-Type: text/plain; charset=UTF-8

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.

between strings generated by the program and strings created from input to the program.

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)

-- Bye, Gor Gyolchanyan. --bcaec554d84233fd6404c4cb5681 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 6:47 PM, dennis luehring= <span dir=3D"ltr">&lt;<a href=3D"mailto:dl.soluz gmx.net" target=3D"_blank= ">dl.soluz gmx.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Am 14.07.2012 14:52, schrieb Timon Gehr:<div><div class=3D"h5"><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 07/14/2012 01:29 PM, Gor Gyolchanyan wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> It would also make run-time mixins possible, which is absolutely amazing.<b= r> <br> </blockquote> <br> It is amazingly unsafe, because at runtime there is no distinction<br> between strings generated by the program and strings created from input<br> to the program.<br> <br> </blockquote> <br></div></div> as everything that works based on input data - its only the context what ma= kes any type of input (and handling) unsafe<br> <br> 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 ru= ntime-mixing wouldn&#39;t be unsage if generated by the interpreting D prog= ram...<br> <br> the other thing is: would you vote against such a feature if it were alread= y there?<br> <br> the next thing would be the D compiler as a library - then we can use D (be= tter rdmd) as a hyper-powerful make<br> <br> 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 stan= dard) 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 stuf= f like that)<br> <br> <br> </blockquote></div><br>Hear hear!!!<br clear=3D"all"><div><br></div>-- <br>= Bye,<br>Gor Gyolchanyan.<br> --bcaec554d84233fd6404c4cb5681--
Jul 14 2012
prev sibling next sibling parent "David Piepgrass" <qwertie256 gmail.com> writes:
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.)
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0401240b3d44b604c4cbcb45
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B8nne Petersen <alex lycus.or=


 <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 cod=


         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=C3=B8nne 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.

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

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? --=20 Bye, Gor Gyolchanyan. --f46d0401240b3d44b604c4cbcb45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Sat, Jul 14, 2012 at 6:35 PM, Alex R=C3=B8nne Petersen &lt;<a href=3D"ma= ilto:alex lycus.org" target=3D"_blank">alex lycus.org</a><br></div><div><di= v class=3D"h5"> &lt;mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.o= rg</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0 On 14-07-2012 12:48, Gor Gyolchanyan wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I just got an amazing thought. If we end up get= ting a D<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 front-end in D,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think it would be possible to make the back-e= nd in the same<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 space as<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the code being compiled. This means, having the= back-end as a<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 library<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 solution. This would automatically provide 100%= compile-time code<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 introspection. This is just a thought. Not a pr= oposal or<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 anything. What<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 do you guys think?<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 --<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bye,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gor Gyolchanyan.<br> <br> <br> =C2=A0 =C2=A0 I can&#39;t tell if you&#39;re advocating writing a back end = in D as well.<br> =C2=A0 =C2=A0 If you are, I am strongly against this. There&#39;s a reason = it has<br> =C2=A0 =C2=A0 taken 10 years for LLVM to get where it is, and it&#39;s stil= l far from<br> =C2=A0 =C2=A0 complete. We have better things to do with development of D t= han<br> =C2=A0 =C2=A0 reinventing the wheel.<br> <br> =C2=A0 =C2=A0 --<br> =C2=A0 =C2=A0 Alex R=C3=B8nne Petersen<br></div></div> =C2=A0 =C2=A0 <a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycu= s.org</a> &lt;mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">al= ex lycus.org</a>&gt;<div class=3D"im"><br> =C2=A0 =C2=A0 <a href=3D"http://lycus.org" target=3D"_blank">http://lycus.o= rg</a><br> <br> <br> I didn&#39;t expect D to have it. D follows tons of anti-patterns, that<br> other languages have followed. It&#39;s yet another language with yet<br> another set of insignificant changes. It IS the best one of all, but<br> it&#39;s not even close to being at least minimally useful for a really big= <br> task.<br> <br> </div></blockquote> <br> Big words.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> For instance, everybody seems to love hard-wiring the syntax into the<br> language.<br> <br> </blockquote> <br></div> Insignificant example.<br> <br> Every language _needs_ to have a standard source storage format.<br> </blockquote></div><br>Syntax has nothing to do with standard source stage.= Why won&#39;t the standard source stage be binary, while leaving the human= -written part (the syntax) up to the writer?=C2=A0<br clear=3D"all"><div><b= r> </div>-- <br>Bye,<br>Gor Gyolchanyan.<br> --f46d0401240b3d44b604c4cbcb45--
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--bcaec554deb2f904dd04c4cbd9c5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B8nne Petersen <alex lycus.or=


 <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 cod=


         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=C3=B8nne 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.

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

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. --=20 Bye, Gor Gyolchanyan. --bcaec554deb2f904dd04c4cbd9c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Sat, Jul 14, 2012 at 6:35 PM, Alex R=C3=B8nne Petersen &lt;<a href=3D"ma= ilto:alex lycus.org" target=3D"_blank">alex lycus.org</a><br></div><div><di= v class=3D"h5"> &lt;mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.o= rg</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0 On 14-07-2012 12:48, Gor Gyolchanyan wrote:<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I just got an amazing thought. If we end up get= ting a D<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 front-end in D,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think it would be possible to make the back-e= nd in the same<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 space as<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the code being compiled. This means, having the= back-end as a<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 library<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 solution. This would automatically provide 100%= compile-time code<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 introspection. This is just a thought. Not a pr= oposal or<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 anything. What<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 do you guys think?<br> <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 --<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bye,<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Gor Gyolchanyan.<br> <br> <br> =C2=A0 =C2=A0 I can&#39;t tell if you&#39;re advocating writing a back end = in D as well.<br> =C2=A0 =C2=A0 If you are, I am strongly against this. There&#39;s a reason = it has<br> =C2=A0 =C2=A0 taken 10 years for LLVM to get where it is, and it&#39;s stil= l far from<br> =C2=A0 =C2=A0 complete. We have better things to do with development of D t= han<br> =C2=A0 =C2=A0 reinventing the wheel.<br> <br> =C2=A0 =C2=A0 --<br> =C2=A0 =C2=A0 Alex R=C3=B8nne Petersen<br></div></div> =C2=A0 =C2=A0 <a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycu= s.org</a> &lt;mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">al= ex lycus.org</a>&gt;<div class=3D"im"><br> =C2=A0 =C2=A0 <a href=3D"http://lycus.org" target=3D"_blank">http://lycus.o= rg</a><br> <br> <br> I didn&#39;t expect D to have it. D follows tons of anti-patterns, that<br> other languages have followed. It&#39;s yet another language with yet<br> another set of insignificant changes. It IS the best one of all, but<br> it&#39;s not even close to being at least minimally useful for a really big= <br> task.<br> <br> </div></blockquote> <br> Big words.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> For instance, everybody seems to love hard-wiring the syntax into the<br> language.<br> <br> </blockquote> <br></div> Insignificant example.<br> <br> Every language _needs_ to have a standard source storage format.<br> </blockquote></div><br>Big words? Some languages are pretty much useless fo= r 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= .<div> <br></div><div>And where is the progress here? Same semi-useful type system= as C++ with a few sprinkles on it.</div><div><div><br></div>-- <br>Bye,<br=
Gor Gyolchanyan.<br>

--bcaec554deb2f904dd04c4cbd9c5--
Jul 14 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--f46d0401730baea0fc04c4cc09e1
Content-Type: text/plain; charset=UTF-8

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?

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. --f46d0401730baea0fc04c4cc09e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Jul 14, 2012 at 7:36 PM, Timon Gehr <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On 07/14/2012 05:24 PM, Gor Gyolchanyan wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"> On Sat, Jul 14, 2012 at 7:15 PM, Timon Gehr &lt;<a href=3D"mailto:timon.geh= r gmx.ch" target=3D"_blank">timon.gehr gmx.ch</a><br></div><div class=3D"im= "> &lt;mailto:<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.geh= r gmx.ch</a>&gt;&gt; wrote:<br> <br> =C2=A0 =C2=A0 On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:<br> <br></div> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<div class=3D"im"><br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 For instance, everybody seems to love hard-wiri= ng the syntax<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 into the<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 language.<br> <br> <br> =C2=A0 =C2=A0 Insignificant example.<br> <br> =C2=A0 =C2=A0 Every language _needs_ to have a standard source storage form= at.<br> <br> <br></div><div class=3D"im"> Syntax has nothing to do with standard source stage. Why won&#39;t the<br> standard source stage be binary,<br> </div></blockquote> <br> Obviously syntax has to do with standard source storage. The syntax<br> definition can be binary just fine, eg:<br> <br> <a href=3D"http://en.wikipedia.org/wiki/Binary_lambda_calculus" target=3D"_= blank">http://en.wikipedia.org/wiki/<u></u>Binary_lambda_calculus</a><div c= lass=3D"im"><br> <br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> while leaving the human-written part (the syntax)<br> </blockquote> <br></div> That is not the definition of _the_ syntax.<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> up to the writer?<br> <br> </blockquote> <br> This is already the case. Writing a parser that transforms your custom synt= ax to the standard syntax is trivial.<br> <br> The reason why almost nobody is doing this is the same as the reason<br> why almost everyone strives to stick to the same English orthography<br> rules.<br> </blockquote></div><br>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 pro= viding a handful of pre-defined abstractions.<br clear=3D"all"> <div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> --f46d0401730baea0fc04c4cc09e1--
Jul 14 2012
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
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.
Jul 15 2012
prev sibling next sibling parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
--e89a8f234687f6af3904c4dfffd5
Content-Type: text/plain; charset=UTF-8

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.

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. --e89a8f234687f6af3904c4dfffd5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sun, Jul 15, 2012 at 7:21 PM, SomeDude <span = dir=3D"ltr">&lt;<a href=3D"mailto:lovelydear mailmetrash.com" target=3D"_bl= ank">lovelydear mailmetrash.com</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> <div class=3D"im">On Saturday, 14 July 2012 at 13:33:16 UTC, Gor Gyolchanya= n wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex"> <br> Yes, eval or exec is pretty much outlawed in other languages, I can only<br=

<br> </blockquote> <br></div><div class=3D"im"> That&#39;s a huge mistake a lot of people make. They outlaw things that the= y<br> don&#39;t understand or don&#39;t know how to use. As I said: having someth= ing<br> doesn&#39;t mean using it. Those who can use it - will use it. Those who ca= n&#39;t<br> - won&#39;t.<br> </div></blockquote> <br> And those who can use it for wrongdoing will. This alone completely destroy= s the feature imho.<br> </blockquote></div><br>It doesn&#39;t have to be a black/white choice. How = about analyzing and caching the code before executing it at run time? If th= e code is analyzed and proved to be safe - then it&#39;s executed without h= esitation. Yes, it&#39;ll require a lot of work to pull this off.<br clear= =3D"all"> <div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> --e89a8f234687f6af3904c4dfffd5--
Jul 15 2012
prev sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
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.
Jul 15 2012