January 24, 2013
On Wednesday, 23 January 2013 at 21:13:12 UTC, Russel Winder wrote:
[...]
>
> The core problem is how to make D appealing to C and C++ programmers.

One possibility is that once we have 100% shared library support, C/C++ programmers can start making use out of a growing base of very nice libraries written in D that are also made compatible (to a degree) with C/C++.

That's a potential ice breaker IMO, esp when C/C++ programmers discover that they will get much more functionality if they ditched C/C++ and used these libs with native D applications instead.

This method of conversion to D a relatively safe and simple migration path.

--rt
January 24, 2013
On 2013-01-24 01:30, Araq wrote:

> There is also Nimrod which has 'yield' and AST macros ...

And Nemerle (on .Net), which both has AST macros and allows the programmer to add new syntax for these macros.

-- 
/Jacob Carlborg
January 24, 2013
On 2013-01-23 22:50, Andrei Alexandrescu wrote:

> It's a subset. That's a better thing than _another_ language.

Of course. But then the CTFE and regular code is handled differently by the compiler it will start to become a different language, although very similar. I'm wondering if that is even worse.

> Not an argument.

The argument is that it's not code to have two different parts of the compiler handling this.

>> In Scala it _is_ the regular compiler that handles both the CTFE and the
>> regular code. A bug in the regular compiler will show up during CTFE as
>> well.
>
> Agreed this is a good thing for Scala, it takes advantage of the jit
> infrastructure.

Exactly, that's what I'm trying to say.


> By passing fresh names as arguments into the function creating it. We
> don't have a strong story there.

The function cannot then generate a symbol that is only used internally as a helper without breaking the hygienicy (or what it's called). You don't want the user to pass in names for symbols it doesn't know about, doesn't care about and should not know about.

-- 
/Jacob Carlborg
January 24, 2013
On 2013-01-24 03:35, deadalnix wrote:

> SDC does something similar with LLVM JIT capabilities.

That's the correct approach.

-- 
/Jacob Carlborg
January 24, 2013
On Thursday, 24 January 2013 at 07:55:37 UTC, Jacob Carlborg wrote:
> On 2013-01-24 03:35, deadalnix wrote:
>
>> SDC does something similar with LLVM JIT capabilities.
>
> That's the correct approach.

The question is not so much about correctness, but about performance.

Building an LLVM function and JIT-compiling it every time you need to evaluate a D expression will completely ruin your compile times (and I say that as an LLVM proponent). The idea itself is interesting for computationally heavy CTFE code, but I don't think it is feasible to go without lightweight code at least for simple »constant folding«-type applications.

David
January 24, 2013
On Thursday, 24 January 2013 at 13:59:43 UTC, David Nadlinger wrote:
> On Thursday, 24 January 2013 at 07:55:37 UTC, Jacob Carlborg wrote:
>> On 2013-01-24 03:35, deadalnix wrote:
>>
>>> SDC does something similar with LLVM JIT capabilities.
>>
>> That's the correct approach.
>
> The question is not so much about correctness, but about performance.
>
> Building an LLVM function and JIT-compiling it every time you need to evaluate a D expression will completely ruin your compile times (and I say that as an LLVM proponent). The idea itself is interesting for computationally heavy CTFE code, but I don't think it is feasible to go without lightweight code at least for simple »constant folding«-type applications.
>

This is what SDC does currently, but yes, simple constant folding should avoid doing that.

But 1/ make it work and 2/ make it fast.

Current implementation permit easily to add constant folding later.
1 2 3 4 5 6
Next ›   Last »