View mode: basic / threaded / horizontal-split · Log in · Help
July 27, 2012
Re: Impressed
Stuart <stugol@gmx.com> wrote:
> Why does D have GOTO? I haven't used GOTO in over a decade, 
> because it's truly evil.

Dogmas are evil.
July 27, 2012
Re: Impressed
On Fri, 27 Jul 2012 05:24:08 +0200, Nick Sabalausky  
<SeeWebsiteToContactMe@semitwist.com> wrote:

>> foreach(i; recurrence!(a => a[n-1] + 2)(0))
>
> Erm, should be:
> foreach(i; recurrence!"a[n-1] + 2"(0))

or just
foreach(i; recurrence!((a,n) => a[n-1] + 2)(0))

-- 
Simen
July 27, 2012
Re: Impressed
On Friday, July 27, 2012 09:27:55 Simen Kjaeraas wrote:
> On Fri, 27 Jul 2012 05:24:08 +0200, Nick Sabalausky
> 
> <SeeWebsiteToContactMe@semitwist.com> wrote:
> >> foreach(i; recurrence!(a => a[n-1] + 2)(0))
> > 
> > Erm, should be:
> > foreach(i; recurrence!"a[n-1] + 2"(0))
> 
> or just
> foreach(i; recurrence!((a,n) => a[n-1] + 2)(0))

Yeah. You can do a lot with infinite and generative ranges. That's one of the 
reasons that they're so much better than iterators (though it sounds like you 
can do some interesting things with C# interators that you can't do with most 
other types of iterators).

- Jonathan M Davis
July 27, 2012
Re: Impressed
On Fri, 27 Jul 2012 06:36:57 +0200, Alex Rønne Petersen <alex@lycus.org>  
wrote:

> Jumping over initialization isn't as problematic in D because variables  
> are guaranteed to have a default initialization value (if not  
> initialized to void).

And how is that supposed to work, when you just skipped that piece of code?


> It's worse in languages like C where the value of variables would be
> undefined.

It's *better* in languages like C, where the value of the variable would be
undefined anyway, so you'd have to deal with that anyway.

I would go as far as to say this is part of the reason this is in the spec:

"It is illegal for a GotoStatement to be used to skip initializations."[1]


[1]: http://dlang.org/statement.html#GotoStatement

-- 
Simen
July 27, 2012
Re: Impressed
On Fri, 27 Jul 2012 08:31:36 +0200
Jacob Carlborg <doob@me.com> wrote:
> 
> Note that iterators in .NET and C++ are a bit different. .NET has 
> language support with the "yield" keyword.
> 

I wonder how that works under the hood. Like, if it's somewhat similar
to opApply. Or maybe more like an Asm-style "messin' with the call
stack's return addresses". I would hope it wouldn't involve fiber
context switches, unless they're somehow much faster than D fiber
context switches (which would seem weird, being in a VM).
July 27, 2012
Re: Impressed
On 2012-07-27 09:42, Nick Sabalausky wrote:

> I wonder how that works under the hood. Like, if it's somewhat similar
> to opApply. Or maybe more like an Asm-style "messin' with the call
> stack's return addresses". I would hope it wouldn't involve fiber
> context switches, unless they're somehow much faster than D fiber
> context switches (which would seem weird, being in a VM).

I have no idea. But Ruby uses a similar approach:

def foo
  yield 1
  yield 2
  yield 3
end

foo do |e|
  puts e
end

Results in:

1
2
3

But in Ruby that's basically syntax sugar for:

def foo (&block)
  block.call(1)
  block.call(1)
  block.call(1)
end

Which in D would be the same as:

void foo (void delegate (int) dg)
{
    dg(1);
    dg(2);
    dg(3);
}

foo((e){
    writeln(e);
});

Which is basically how opApply works.

-- 
/Jacob Carlborg
July 27, 2012
Re: Impressed
On Fri, 27 Jul 2012 09:42:37 +0200, Nick Sabalausky  
<SeeWebsiteToContactMe@semitwist.com> wrote:

> On Fri, 27 Jul 2012 08:31:36 +0200
> Jacob Carlborg <doob@me.com> wrote:
>>
>> Note that iterators in .NET and C++ are a bit different. .NET has
>> language support with the "yield" keyword.
>>
>
> I wonder how that works under the hood. Like, if it's somewhat similar
> to opApply. Or maybe more like an Asm-style "messin' with the call
> stack's return addresses". I would hope it wouldn't involve fiber
> context switches, unless they're somehow much faster than D fiber
> context switches (which would seem weird, being in a VM).

The compiler generates a state-machine for you.

http://blogs.msdn.com/b/wesdyer/archive/2007/03/23/all-about-iterators.aspx

-- 
Simen
July 27, 2012
Re: Impressed
On 27-07-2012 09:41, Simen Kjaeraas wrote:
> On Fri, 27 Jul 2012 06:36:57 +0200, Alex Rønne Petersen
> <alex@lycus..org> wrote:
>
>> Jumping over initialization isn't as problematic in D because
>> variables are guaranteed to have a default initialization value (if
>> not initialized to void).
>
> And how is that supposed to work, when you just skipped that piece of code?

The compiler does control flow analysis to ensure that all reads of the 
value will, at the very least, see a default-initialized variable. It's 
really quite trivial to do in the compiler.

>
>
>> It's worse in languages like C where the value of variables would be
>> undefined.
>
> It's *better* in languages like C, where the value of the variable would be
> undefined anyway, so you'd have to deal with that anyway.

Undefined behavior is never useful, better, or desirable in any way, 
shape, or form. With a well-defined default initialization value, it's 
trivial to discover that you skipped initialization. This is why D 
initializes floats to NaN, chars to 0xff, etc.

>
> I would go as far as to say this is part of the reason this is in the spec:
>
> "It is illegal for a GotoStatement to be used to skip initializations."[1]
>
>
> [1]: http://dlang.org/statement.html#GotoStatement
>

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
July 27, 2012
Re: Impressed
"Stuart" <stugol@gmx.com> schrieb im Newsbeitrag 
news:pzhwiumzhktkzdmvlpig@forum.dlang.org...
> Why does D have GOTO? I haven't used GOTO in over a decade, because it's 
> truly evil.

"By the way, if you don't like |goto| statements, don't read this. (And 
don't
read any other programs that simulate multistate systems.)

\smallskip\rightline{--- Don Knuth, September 1998}"

[1] http://sunburn.stanford.edu/~knuth/programs.html#advent
July 27, 2012
Re: Impressed
On 27.07.2012 04:05, Stuart wrote:
> On Friday, 27 July 2012 at 01:25:45 UTC, F i L wrote:
>>
>
> Incidentally, none of that answered my original question, which is "why
> does VisualD crash?"

I tried to reproduce it, but for my solutions it works. I suspect it 
might have to do with your window layout. You might try to remove the 
solution options file (.suo) and see if it still crashes. Please create 
a ticket here: http://www.dsource.org/projects/visuald/newticket


>
> The only other thing I don't like about VisualD is that the intellisense
> kinda blows. It's very hit-and-miss. Why is this?

The intellisense part is rather unfinished. it needs full semantic 
analysis, and that is almost as complex as a D compiler. I'm not really 
sure what you mean by "Blows" or "hit-and-miss", though.

Rainer
1 2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home