www.digitalmars.com         C & C++   DMDScript  

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

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.
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.



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 Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.



 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.
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 Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
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.


 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.


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.
Jul 14 2012
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 reply Kevin Cox <kevincox.ca gmail.com> writes:
On Jul 14, 2012 9:15 AM, "David" <d dav1d.de> wrote:

 Run-time mixins can be used for incredibly powerful stuff, yet the same
 run-time mixins can be used for incredibly dangerous stuff. Just don't
 use them if you don't know exactly what you're doing. :-)



 I don't see any case where a "runtime-mixin" is the only solution (it's


definitly the unsafest)


Yes, eval or exec is pretty much outlawed in other languages, I can only
imagine the same would happen in D.



 Jul 14 2012



  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


 definitly the unsafest)


 Yes, eval or exec is pretty much outlawed in other languages, I can only
 imagine the same would happen in D.


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

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



 Jul 14 2012



prev sibling  parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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


 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.

-- 
Bye,
Gor Gyolchanyan.



 Jul 14 2012



 next 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 reply "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



  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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


 On Saturday, 14 July 2012 at 13:33:16 UTC, Gor Gyolchanyan wrote:


 Yes, eval or exec is pretty much outlawed in other languages, I can only
 imagine the same would happen in D.


 That's a huge mistake a lot of people make. They outlaw things that they
 don't understand or don't know how to use. As I said: having something
 doesn't mean using it. Those who can use it - will use it. Those who can't
 - won't.


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


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

-- 
Bye,
Gor Gyolchanyan.



 Jul 15 2012



prev sibling  parent reply 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



  parent  Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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


 Am 14.07.2012 14:52, schrieb Timon Gehr:

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

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


 It is amazingly unsafe, because at runtime there is no distinction
 between strings generated by the program and strings created from input
 to the program.


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

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

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

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

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


Hear hear!!!

-- 
Bye,
Gor Gyolchanyan.



 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 Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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=


or

 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.



 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 Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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=




g

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




e

         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.


 Big words.


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

 language.


 Insignificant example.

 Every language _needs_ to have a standard source storage format.


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

--=20
Bye,
Gor Gyolchanyan.



 Jul 14 2012



  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 reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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


 On 07/14/2012 05:24 PM, Gor Gyolchanyan wrote:


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

     On 07/14/2012 04:44 PM, Gor Gyolchanyan wrote:

         ...

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


     Insignificant example.

     Every language _needs_ to have a standard source storage format.


 Syntax has nothing to do with standard source stage. Why won't the
 standard source stage be binary,


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

 http://en.wikipedia.org/wiki/**Binary_lambda_calculus<http://en.wikipedia.org/wiki/Binary_lambda_calculus>



  while leaving the human-written part (the syntax)


 That is not the definition of _the_ syntax.

  up to the writer?


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

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


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

-- 
Bye,
Gor Gyolchanyan.



 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 reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com>  writes:


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=




g

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




e

         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.


 Big words.


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

 language.


 Insignificant example.

 Every language _needs_ to have a standard source storage format.


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

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

--=20
Bye,
Gor Gyolchanyan.



 Jul 14 2012



  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  parent reply "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 

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



  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