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.

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

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

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

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

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

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

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

"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

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