digitalmars.D - D front-end in D for D
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- Paulo Pinto <pjmlp progtools.org> Jul 14 2012
- Timon Gehr <timon.gehr gmx.ch> Jul 14 2012
- David <d dav1d.de> Jul 14 2012
- dennis luehring <dl.soluz gmx.net> Jul 14 2012
- deadalnix <deadalnix gmail.com> Jul 14 2012
- dennis luehring <dl.soluz gmx.net> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- Kevin Cox <kevincox.ca gmail.com> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> Jul 14 2012
- Timon Gehr <timon.gehr gmx.ch> Jul 14 2012
- Timon Gehr <timon.gehr gmx.ch> Jul 14 2012
- Timon Gehr <timon.gehr gmx.ch> Jul 14 2012
- Timon Gehr <timon.gehr gmx.ch> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- "David Piepgrass" <qwertie256 gmail.com> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 14 2012
- "SomeDude" <lovelydear mailmetrash.com> Jul 15 2012
- Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> Jul 15 2012
- "SomeDude" <lovelydear mailmetrash.com> Jul 15 2012
--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
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
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
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
dennis luehring <dl.soluz gmx.net> 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
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
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
--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"><<a href=3D"mailto:pjmlp progtools.org" target=3D"_blank"=pjmlp progtools.org</a>></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'm usually an advocate of bootstraping languages as it makes a better<= br> testbed for the language, since you'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
--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"><<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>></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't use them if you don't know exactl= y what you're doing. :-)<br clear=3D"all"> <div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> </div> --e0cb4efe339057505b04c4c9c5bc--
Jul 14 2012
--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, "David" <<a href="mailto:d dav1d.de">d dav1d.de</a>> wrote:<br> >><br> >> Run-time mixins can be used for incredibly powerful stuff, yet the same<br> >> run-time mixins can be used for incredibly dangerous stuff. Just don't<br> >> use them if you don't know exactly what you're doing. :-)<br> ><br> ><br> > I don't see any case where a "runtime-mixin" is the only solution (it's definitly the unsafest)<br> ></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
--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"><<a href=3D"mailto:kevincox.ca gmail.com" target=3D"_blank"=kevincox.ca gmail.com</a>></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, "David" <<a href=3D"mailto:d dav1d.de= " target=3D"_blank">d dav1d.de</a>> wrote:<br> >><br> >> Run-time mixins can be used for incredibly powerful stuff, yet the= same<br> >> run-time mixins can be used for incredibly dangerous stuff. Just d= on't<br> >> use them if you don't know exactly what you're doing. :-)<= br> ><br> ><br> > I don't see any case where a "runtime-mixin" is the only= solution (it's definitly the unsafest)<br> ></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'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 i= t - will use it. Those who can't - won't.<div> <div><br></div>-- <br>Bye,<br>Gor Gyolchanyan.<br> </div> --f46d04088ee58839f104c4ca3cb8--
Jul 14 2012
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
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
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_calculuswhile 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
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
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
--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"><<a href=3D"mailto:alex lycus.org" target=3D= "_blank">alex lycus.org</a>></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'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 1= 0 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 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't expect D to have it. D fo= llows tons of anti-patterns, that other languages have followed. It's y= et another language with yet another set of insignificant changes. It IS th= e best one of all, but it'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
--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"><<a href=3D"mailto:dl.soluz gmx.net" target=3D"_blank= ">dl.soluz gmx.net</a>></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'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
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
--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 thelanguage.
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"><<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>></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 <<a href=3D"ma= ilto:alex lycus.org" target=3D"_blank">alex lycus.org</a><br></div><div><di= v class=3D"h5"> <mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.o= rg</a>>> 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't tell if you're advocating writing a back end = in D as well.<br> =C2=A0 =C2=A0 If you are, I am strongly against this. There's a reason = it has<br> =C2=A0 =C2=A0 taken 10 years for LLVM to get where it is, and it'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> <mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">al= ex lycus.org</a>><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't expect D to have it. D follows tons of anti-patterns, that<br> other languages have followed. It's yet another language with yet<br> another set of insignificant changes. It IS the best one of all, but<br> it'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'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
--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 thelanguage.
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"><<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>></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 <<a href=3D"ma= ilto:alex lycus.org" target=3D"_blank">alex lycus.org</a><br></div><div><di= v class=3D"h5"> <mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">alex lycus.o= rg</a>>> 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't tell if you're advocating writing a back end = in D as well.<br> =C2=A0 =C2=A0 If you are, I am strongly against this. There's a reason = it has<br> =C2=A0 =C2=A0 taken 10 years for LLVM to get where it is, and it'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> <mailto:<a href=3D"mailto:alex lycus.org" target=3D"_blank">al= ex lycus.org</a>><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't expect D to have it. D follows tons of anti-patterns, that<br> other languages have followed. It's yet another language with yet<br> another set of insignificant changes. It IS the best one of all, but<br> it'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
--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"><<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">ti= mon.gehr gmx.ch</a>></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 <<a href=3D"mailto:timon.geh= r gmx.ch" target=3D"_blank">timon.gehr gmx.ch</a><br></div><div class=3D"im= "> <mailto:<a href=3D"mailto:timon.gehr gmx.ch" target=3D"_blank">timon.geh= r gmx.ch</a>>> 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'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
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
--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"><<a href=3D"mailto:lovelydear mailmetrash.com" target=3D"_bl= ank">lovelydear mailmetrash.com</a>></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's a huge mistake a lot of people make. They outlaw things that the= y<br> don't understand or don't know how to use. As I said: having someth= ing<br> doesn't mean using it. Those who can use it - will use it. Those who ca= n't<br> - won'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'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's executed without h= esitation. Yes, it'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
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