Jump to page: 1 2 3
Thread overview
D front-end in D for D
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Paulo Pinto
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Timon Gehr
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
David
Jul 14, 2012
Kevin Cox
Jul 14, 2012
dennis luehring
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
deadalnix
Jul 15, 2012
SomeDude
Jul 15, 2012
Gor Gyolchanyan
Jul 14, 2012
dennis luehring
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Timon Gehr
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Timon Gehr
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Timon Gehr
Jul 14, 2012
Gor Gyolchanyan
Jul 14, 2012
Timon Gehr
Jul 14, 2012
David Piepgrass
Jul 15, 2012
SomeDude
July 14, 2012
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.


July 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
July 14, 2012
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.


July 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.
July 14, 2012
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.


July 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)

July 14, 2012
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.


July 14, 2012
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.


July 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
July 14, 2012
On Sat, Jul 14, 2012 at 6:35 PM, Alex Rønne 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 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
>

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.

-- 
Bye,
Gor Gyolchanyan.


« First   ‹ Prev
1 2 3