View mode: basic / threaded / horizontal-split · Log in · Help
January 24, 2013
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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
Re: Internal and external iteration, fibers
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.
Next ›   Last »
2 3 4 5 6
Top | Discussion index | About this forum | D home