"Stuart" <stugol gmx.com> writes:

I'm quite new to D, and I've just been reading the guides. I just 
wanted to say I'm very impressed with some of the features I'm 
reading about. Slices, closures, the scope keyword(!!!), class 
variable initialisers, anonymous array literals, array 
concatenation, synchronisation... even decent exception support 
is a breath of fresh air compared to C++.

I'm primarily a .NET coder these days, but sometimes you really 
need more performance. Writing an OpenGL game in VB.NET is just 
pointless - it doesn't execute fast enough to be of any use, even 
using display lists. So, next time I need something a little more 
C-like, I'll be loading up D straight away.

I have a couple of questions though. Why does the VisualD plugin 
crash Visual Studio if I double-click a .sln file in Windows 
Explorer? I mean, every single time? I'm using VS2010 on Windows 
7 64-bit; and the problem only happens with D projects, and only 
when loading an .sln file by association. If I load VS and use 
the menu to open the solution, it works fine.

Why does D have GOTO? I haven't used GOTO in over a decade, 
because it's truly evil.

How good is the Entice Designer? I'd like to write some GUI apps 
in D, but I need to know that the designer won't fall over 
halfway through; and I'll be damned if I'm writing my GUI code by 
hand. Even MFC programmers have a "dialog designer".

One thing I really think D ought to have is iterators, like 

chance of them being implemented? The implementation of .NET 
iterators is well-known and fairly straightforward; all we need 
is compiler support.

"Brad Anderson" <eco gnuk.net> writes:

On Thursday, 26 July 2012 at 23:59:13 UTC, Stuart wrote:
 I'm quite new to D, and I've just been reading the guides. I 
 just wanted to say I'm very impressed with some of the features 
 I'm reading about. Slices, closures, the scope keyword(!!!), 
 class variable initialisers, anonymous array literals, array 
 concatenation, synchronisation... even decent exception support 
 is a breath of fresh air compared to C++.

 I'm primarily a .NET coder these days, but sometimes you really 
 need more performance. Writing an OpenGL game in VB.NET is just 
 pointless - it doesn't execute fast enough to be of any use, 
 even using display lists. So, next time I need something a 
 little more C-like, I'll be loading up D straight away.

 I have a couple of questions though. Why does the VisualD 
 plugin crash Visual Studio if I double-click a .sln file in 
 Windows Explorer? I mean, every single time? I'm using VS2010 
 on Windows 7 64-bit; and the problem only happens with D 
 projects, and only when loading an .sln file by association. If 
 I load VS and use the menu to open the solution, it works fine.

 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

 How good is the Entice Designer? I'd like to write some GUI 
 apps in D, but I need to know that the designer won't fall over 
 halfway through; and I'll be damned if I'm writing my GUI code 
 by hand. Even MFC programmers have a "dialog designer".

 One thing I really think D ought to have is iterators, like 

 chance of them being implemented? The implementation of .NET 
 iterators is well-known and fairly straightforward; all we need 
 is compiler support.

D uses ranges instead of iterators. You can read more about them 
here: http://ddili.org/ders/d.en/ranges.html

I find ranges to be a vast improvement over iterators personally 
(I use iterators extensively in C++ for my job and lament not 
having ranges regularly).

Regards,
Brad Anderson

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
 D uses ranges instead of iterators. You can read more about 
 them here: http://ddili.org/ders/d.en/ranges.html

 I find ranges to be a vast improvement over iterators 
 personally (I use iterators extensively in C++ for my job and 
 lament not having ranges regularly).

On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
 D has something far superior: ranges.

 	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1

 Even better, they are completely implemented in the library. No
 unnecessary language bloat just to support them.

I'm not very well up on ranges. I understand the general [1 ... 
6] type of ranges, but I really don't see how custom range 
functions could be as useful as the Yield support in VB.NET. I 
mean, here's an example of an iterator in VB.NET:

    Public Function InfiniteSequence(StartValue As Int32, Step As 
Int32) As IEnumerable(Of Int32)
       Do
          Yield StartValue
          StartValue += Step
       Loop
    End Function

Usage:

    For Each N in InfiniteSequence(2, 2)
       ... do something with this sequence of even numbers ...
    Next

Notice how this function is written like a synchronous loop, yet 
yields a lazy-initialised infinite sequence of numbers. Granted, 
it's not a particularly useful example, but trust me: Iterators 
and Yield in .NET is *really* damn useful. I would go so far as 
to say it was one of the language's best features.

I may be wrong, but it looks like I'd have to code a new class - 
not to mention several specific functions and some kind of state 
variable - just to simulate this functionality in D. Can anyone 
clarify this for me?

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 03:56:32 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
 D uses ranges instead of iterators. You can read more about 
 them here: http://ddili.org/ders/d.en/ranges.html

 I find ranges to be a vast improvement over iterators 
 personally (I use iterators extensively in C++ for my job and 
 lament not having ranges regularly).

 On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
 D has something far superior: ranges.

 	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1

 Even better, they are completely implemented in the library. No
 unnecessary language bloat just to support them.

 
 I'm not very well up on ranges. I understand the general [1 ... 
 6] type of ranges, but I really don't see how custom range 
 functions could be as useful as the Yield support in VB.NET. I 
 mean, here's an example of an iterator in VB.NET:
 
     Public Function InfiniteSequence(StartValue As Int32, Step As 
 Int32) As IEnumerable(Of Int32)
        Do
           Yield StartValue
           StartValue += Step
        Loop
     End Function
 
 Usage:
 
     For Each N in InfiniteSequence(2, 2)
        ... do something with this sequence of even numbers ...
     Next
 
 Notice how this function is written like a synchronous loop, yet 
 yields a lazy-initialised infinite sequence of numbers. Granted, 
 it's not a particularly useful example, but trust me: Iterators 
 and Yield in .NET is *really* damn useful. I would go so far as 
 to say it was one of the language's best features.
 
 I may be wrong, but it looks like I'd have to code a new class - 
 not to mention several specific functions and some kind of state 
 variable - just to simulate this functionality in D. Can anyone 
 clarify this for me?

D can do that with either fibers or opApply. I've explored all the
different approaches in this admittedly not-so-well-written article:

https://semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

Note, however, that fibers (while far, *far* faster than
threads) are still too heavyweight to be recommended for most
generator functions (as I learned after writing that article). So if you
want a generator, you should use opApply instead of fibers or my
"InputVisitor" trick. I'd recommend using Adam's trick mentioned in the
second "Update" at the bottom of the article.

Brad Anderson <eco gnuk.net> writes:

On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:

 D uses ranges instead of iterators. You can read more about them here:
 http://ddili.org/ders/d.en/**ranges.html<http://ddili.org/ders/d.en/ranges.html>

 I find ranges to be a vast improvement over iterators personally (I use
 iterators extensively in C++ for my job and lament not having ranges
 regularly).


  On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:

 D has something far superior: ranges.

         http://www.informit.com/**articles/printerfriendly.aspx?**
 p=1407357&rll=1<http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1>

 Even better, they are completely implemented in the library. No
 unnecessary language bloat just to support them.

 I'm not very well up on ranges. I understand the general [1 ... 6] type of
 ranges, but I really don't see how custom range functions could be as
 useful as the Yield support in VB.NET. I mean, here's an example of an
 iterator in VB.NET:

    Public Function InfiniteSequence(StartValue As Int32, Step As Int32) As
 IEnumerable(Of Int32)
       Do
          Yield StartValue
          StartValue += Step
       Loop
    End Function

 Usage:

    For Each N in InfiniteSequence(2, 2)
       ... do something with this sequence of even numbers ...
    Next

 Notice how this function is written like a synchronous loop, yet yields a
 lazy-initialised infinite sequence of numbers. Granted, it's not a
 particularly useful example, but trust me: Iterators and Yield in .NET is
 *really* damn useful. I would go so far as to say it was one of the
 language's best features.

 I may be wrong, but it looks like I'd have to code a new class - not to
 mention several specific functions and some kind of state variable - just
 to simulate this functionality in D. Can anyone clarify this for me?

D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
numbers */)();

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Thu, 26 Jul 2012 21:00:12 -0600
Brad Anderson <eco gnuk.net> wrote:

 On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol gmx.com> wrote:
 
 On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:

 D uses ranges instead of iterators. You can read more about them
 here:
 http://ddili.org/ders/d.en/**ranges.html<http://ddili.org/ders/d.en/ranges.html>

 I find ranges to be a vast improvement over iterators personally
 (I use iterators extensively in C++ for my job and lament not
 having ranges regularly).


  On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:

 D has something far superior: ranges.

         http://www.informit.com/**articles/printerfriendly.aspx?**
 p=1407357&rll=1<http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1>

 Even better, they are completely implemented in the library. No
 unnecessary language bloat just to support them.

 I'm not very well up on ranges. I understand the general [1 ... 6]
 type of ranges, but I really don't see how custom range functions
 could be as useful as the Yield support in VB.NET. I mean, here's
 an example of an iterator in VB.NET:

    Public Function InfiniteSequence(StartValue As Int32, Step As
 Int32) As IEnumerable(Of Int32)
       Do
          Yield StartValue
          StartValue += Step
       Loop
    End Function

 Usage:

    For Each N in InfiniteSequence(2, 2)
       ... do something with this sequence of even numbers ...
    Next

 Notice how this function is written like a synchronous loop, yet
 yields a lazy-initialised infinite sequence of numbers. Granted,
 it's not a particularly useful example, but trust me: Iterators and
 Yield in .NET is *really* damn useful. I would go so far as to say
 it was one of the language's best features.

 I may be wrong, but it looks like I'd have to code a new class -
 not to mention several specific functions and some kind of state
 variable - just to simulate this functionality in D. Can anyone
 clarify this for me?

 
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
 numbers */)();
 

Or:

foreach(i; iota(0, int.max, 2))
{
	// stuff
}

Or (not as fast, but more flexible):

foreach(i; iota(0, int.max).filter!(a => a%2==0)())
{
	// stuff
}

Or:

foreach(i; recurrence!(a => a[n-1] + 2)(0))
{
	// stuff
}

Etc...

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Thu, 26 Jul 2012 23:21:54 -0400
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:

 On Thu, 26 Jul 2012 21:00:12 -0600
 Brad Anderson <eco gnuk.net> wrote:
 
 On Thu, Jul 26, 2012 at 7:56 PM, Stuart <stugol gmx.com> wrote:
 
 On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:

 D uses ranges instead of iterators. You can read more about them
 here:
 http://ddili.org/ders/d.en/**ranges.html<http://ddili.org/ders/d.en/ranges.html>

 I find ranges to be a vast improvement over iterators personally
 (I use iterators extensively in C++ for my job and lament not
 having ranges regularly).


  On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:

 D has something far superior: ranges.

         http://www.informit.com/**articles/printerfriendly.aspx?**
 p=1407357&rll=1<http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1>

 Even better, they are completely implemented in the library. No
 unnecessary language bloat just to support them.

 I'm not very well up on ranges. I understand the general [1 ... 6]
 type of ranges, but I really don't see how custom range functions
 could be as useful as the Yield support in VB.NET. I mean, here's
 an example of an iterator in VB.NET:

    Public Function InfiniteSequence(StartValue As Int32, Step As
 Int32) As IEnumerable(Of Int32)
       Do
          Yield StartValue
          StartValue += Step
       Loop
    End Function

 Usage:

    For Each N in InfiniteSequence(2, 2)
       ... do something with this sequence of even numbers ...
    Next

 Notice how this function is written like a synchronous loop, yet
 yields a lazy-initialised infinite sequence of numbers. Granted,
 it's not a particularly useful example, but trust me: Iterators
 and Yield in .NET is *really* damn useful. I would go so far as
 to say it was one of the language's best features.

 I may be wrong, but it looks like I'd have to code a new class -
 not to mention several specific functions and some kind of state
 variable - just to simulate this functionality in D. Can anyone
 clarify this for me?

 
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with
 even numbers */)();
 

 
 Or:
 
 foreach(i; iota(0, int.max, 2))
 {
 	// stuff
 }
 
 Or (not as fast, but more flexible):
 
 foreach(i; iota(0, int.max).filter!(a => a%2==0)())
 {
 	// stuff
 }
 
 Or:
 
 foreach(i; recurrence!(a => a[n-1] + 2)(0))

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

 {
 	// stuff
 }
 
 Etc...
 
 

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

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

Jonathan M Davis <jmdavisProg gmx.com> writes:

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 

other types of iterators).

- Jonathan M Davis

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

I think you're missing the point. The purpose isn't to generate a 
sequence of numbers, but to illustrate how the Yield keyword is 
used in VB.NET. Sure, getting a sequence of numbers may be 
straightforward, but what about a lazy-populated list of all 
files on a computer? That can be done using Yield - and more 
importantly, WRITTEN like a normal synchronous function. Let's 
see you do that with map.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/27/12 9:10 AM, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
 numbers */)();

 I think you're missing the point. The purpose isn't to generate a
 sequence of numbers, but to illustrate how the Yield keyword is used in
 VB.NET. Sure, getting a sequence of numbers may be straightforward, but
 what about a lazy-populated list of all files on a computer? That can be
 done using Yield - and more importantly, WRITTEN like a normal
 synchronous function. Let's see you do that with map.

I think it's fair to say yield makes some things easier to do than 
ranges, and ranges makes some other things easier to do than yield. Of 
course, ideally you'd have both, but for the time being we don't have yield.

Andrei

Sean Kelly <sean invisibleduck.org> writes:

On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu =
<SeeWebsiteForEmail erdani.org> wrote:

 On 7/27/12 9:10 AM, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
=20
 D equivalent: iota(0, int.max, 2).map!(a =3D> /* do something with =



even
 numbers */)();

=20
 I think you're missing the point. The purpose isn't to generate a
 sequence of numbers, but to illustrate how the Yield keyword is used =


in
 VB.NET. Sure, getting a sequence of numbers may be straightforward, =


but
 what about a lazy-populated list of all files on a computer? That can =


be
 done using Yield - and more importantly, WRITTEN like a normal
 synchronous function. Let's see you do that with map.

=20
 I think it's fair to say yield makes some things easier to do than =

ranges, and ranges makes some other things easier to do than yield. Of =
course, ideally you'd have both, but for the time being we don't have =
yield.

core.thread.Fiber has yield and has been used as the basis for this =
style of iterator.  See Mikola Lysenko's talk from the D conference a =
few years ago.=

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 15:42:27 UTC, Sean Kelly wrote:
 On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 core.thread.Fiber has yield and has been used as the basis for 
 this style of iterator.  See Mikola Lysenko's talk from the D 
 conference a few years ago.

I think perhaps you are confusing two different meanings of 
yield. I am not talking about threading. The VB.NET "yield" and 
"iterator" keywords can be used just as well in a single-threaded 
application.

http://mattmc3.blogspot.co.uk/2011/04/vbnet-finally-gets-yield-statement.html

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 20:52:37 Stuart wrote:
 I think perhaps you are confusing two different meanings of
 yield. I am not talking about threading. The VB.NET "yield" and
 "iterator" keywords can be used just as well in a single-threaded
 application.

From what you've been saying, it sounds like yield is probably the equivalent 

of declaring a range type in place and using it, which is quite doable but is 
somewhat more verbose. In most basic cases though, a function probably already 
exists in std.algorithm that will let you do what you want to do by only 
providing a lambda function rather than a new range. And the more complex 
cases have enough implementation that the boilerplate range type declarations 
are small in comparison. Maybe we _should_ look at providing a better 
mechanism for creating range types in-place at some point, but what we have - 
particularly with std.algorithm - is already quite powerful, and I rarely see 
the need (if ever) to declare a range in-place.

Regardless, with where D is right now, there's no way that such a feature 
would be added the language itself any time soon. It's probably possible to 
provide a library solution though, where you just give lambda functions for 
empty, front, and popFront, which would make creating a basic input range in 
place quite easy.

- Jonathan M Davis

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
 Regardless, with where D is right now, there's no way that such 
 a feature would be added the language itself any time soon.

What do you mean? Where *is* D at right now? Has development 
stopped? Is there a massive feature backlog?

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Jul 27, 2012 at 09:09:25PM +0200, Stuart wrote:
 On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
Regardless, with where D is right now, there's no way that such a
feature would be added the language itself any time soon.

 
 What do you mean? Where *is* D at right now? Has development
 stopped? Is there a massive feature backlog?

Development is far from stopped, which is the problem: we're trying to
stabilize the language, and adding more language-level features will
only delay an already overdue stable language version.

Nevertheless, D has gotten to the point where it's powerful enough that
most feature requests can be implemented in a library rather than as a
language extension. There's been a trend of moving away from core
language changes and implementing desired features in libraries (esp.
Phobos) instead.


T

-- 
That's not a bug; that's a feature!

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
 Nevertheless, D has gotten to the point where it's powerful 
 enough that most feature requests can be implemented in a
 library rather than as a language extension.

How could Yield be implemented as a library feature? Something 
like:

    return ITERATOR(
       { ...setup code ... },
       { ...loop body code... })

?

I don't see how that would work. Variables declared in the setup 
would not be accessible from the body. I guess it could be done a 
bit like this:

    Enumerable!int ExampleFunction() {
       ... create some variables ...
       return ITERATOR!int( {
          ...do something with variables...
          ...return something...
       } )
    }

That the kind of thing you mean?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 21:22:47 Stuart wrote:
 On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
 Nevertheless, D has gotten to the point where it's powerful
 enough that most feature requests can be implemented in a
 library rather than as a language extension.

 
 How could Yield be implemented as a library feature? Something
 like:
 
     return ITERATOR(
        { ...setup code ... },
        { ...loop body code... })
 
 ?
 
 I don't see how that would work. Variables declared in the setup
 would not be accessible from the body. I guess it could be done a
 bit like this:
 
     Enumerable!int ExampleFunction() {
        ... create some variables ...
        return ITERATOR!int( {
           ...do something with variables...
           ...return something...
        } )
     }
 
 That the kind of thing you mean?

As they're delegates, you could just put any variables you need in both 
functions in surrounding function. So, something like that could be done, 
though it would probably be built around the idea that you'd be giving lambdas 
for empty, front, and popFront rather than an iterator.

But regardless, I'm sure that a library solution could be found, and at this 
point, unless a library solution really just doesn't work or is really ugly 
and the feature is really needed, it's not going to be added to the language. 
D is incredibly powerful, and there's been a large push (especially from 
Andrei) to use that power to solve problems rather than add more to the 
language to do it.

- Jonathan M Davis

FeepingCreature <default_357-line yahoo.de> writes:

On 07/27/12 21:22, Stuart wrote:
 On Friday, 27 July 2012 at 19:17:10 UTC, H. S. Teoh wrote:
 Nevertheless, D has gotten to the point where it's powerful enough that most
feature requests can be implemented in a
 library rather than as a language extension.

 
 How could Yield be implemented as a library feature? Something like:
 
    return ITERATOR(
       { ...setup code ... },
       { ...loop body code... })
 
 ?
 
 I don't see how that would work.

The threading "yield" and the iterator "yield" are actually strongly related.
By yielding a coroutine, you can effectively suspend a routine
and resume it later. Let me give you an example:

int delegate() genEvenNumbers() {
  // not actual api
  return startCoroutineIterator!int((void delegate(int) yield) {
    for (int i = 0; true; i++) if (i % 2 == 0) yield(i);
  });
}

// long form of the above function, so you can see how you gain iterator-style
behavior via coroutines
int delegate() genEvenNumbers() {
  int* resultp = new int;
  void cofun(void delegate(int) yield) {
    for (int i = 0; true; i++) if (i % 2 == 0) yield(i);
  }
  // still not actual api
  auto coroutine = new Coroutine(1024*1024 /* stack size */);
  // set the 'main function' of the coroutine
  coroutine.fun = {
    // yield, when called, will cause the coroutine to suspend and run() to
return
    cofun((int i) { *resultp = i; coroutine.yield(); });
  };
  // run the coroutine up to the next yield, then return yielded value
  return { coroutine.run(); return *resultp; };
}

You can fully implement Coroutine as a library, provided you're somewhat
confident with x86 assembly and stack frame layouts.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 21:09:25 Stuart wrote:
 On Friday, 27 July 2012 at 19:03:34 UTC, Jonathan M Davis wrote:
 Regardless, with where D is right now, there's no way that such
 a feature would be added the language itself any time soon.

 
 What do you mean? Where *is* D at right now? Has development
 stopped? Is there a massive feature backlog?

We're specifically trying _not_ to add language features right now but rather 
to stabilize the language and its implementation. We've added a few things 
since the release of TDPL - mostly to resolve major issues that came up - but 
with the release of TDPL, the language was supposed to have been effectively 
frozen. We may add more backwards-compatible features once everything in TDPL 
has been fully implemented and is reasonably stable, but at this point, new 
language features need a _really_ good justification in order to be added.

- Jonathan M Davis

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 20:52:37 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 15:42:27 UTC, Sean Kelly wrote:
 On Jul 27, 2012, at 8:05 AM, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:

 core.thread.Fiber has yield and has been used as the basis for 
 this style of iterator.  See Mikola Lysenko's talk from the D 
 conference a few years ago.

 
 I think perhaps you are confusing two different meanings of 
 yield. I am not talking about threading. The VB.NET "yield" and 
 "iterator" keywords can be used just as well in a single-threaded 
 application.
 

Fibers don't use any threads.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 11:05:21 -0400
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 
 I think it's fair to say yield makes some things easier to do than 
 ranges, and ranges makes some other things easier to do than yield.
 Of course, ideally you'd have both, but for the time being we don't
 have yield.
 

We have this, which is essentially the same, just not quite as nice
syntax ("mixin(yield("blah"));" instead of "yield blah;")

http://forum.dlang.org/thread/jno6o5$qtb$1 digitalmars.com#post-ojeetpvwvzltxwlgphpb:40forum.dlang.org

"Graham Fawcett" <fawcett uwindsor.ca> writes:

On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

 I think you're missing the point. The purpose isn't to generate 
 a sequence of numbers, but to illustrate how the Yield keyword 
 is used in VB.NET. Sure, getting a sequence of numbers may be 
 straightforward, but what about a lazy-populated list of all 
 files on a computer? That can be done using Yield - and more 
 importantly, WRITTEN like a normal synchronous function. Let's 
 see you do that with map.

That's easy:

import std.file, std.stdio, std.algorithm;

void main()
{
   static BASE_DIR = "/path/to/base";
   static SIZE_CUTOFF = 100;

   // 'entries' is an InputRange

   auto entries = dirEntries(BASE_DIR, SpanMode.breadth);

   // filter the range; map to a range of filenames

   auto smallFileNames = entries
     .filter!(e => e.size < SIZE_CUTOFF)
     .map!(e => e.name);

   // note, the filesystem hasn't been touched yet;
   // we have full laziness.

   foreach(name; smallFileNames)
     writeln(name);
}


And check out this example, where you can process the entries in 
parallel:

http://dlang.org/phobos/std_file.html#dirEntries

You should spend some time using ranges before drawing 
conclusions about them.

Graham

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
 On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

 I think you're missing the point. The purpose isn't to 
 generate a sequence of numbers, but to illustrate how the 
 Yield keyword is used in VB.NET. Sure, getting a sequence of 
 numbers may be straightforward, but what about a 
 lazy-populated list of all files on a computer? That can be 
 done using Yield - and more importantly, WRITTEN like a normal 
 synchronous function. Let's see you do that with map.

 That's easy:

   [...elided code...]
   auto entries = dirEntries(BASE_DIR, SpanMode.breadth);

Ah, but that depends upon the pre-existence of the dirEntries() 
function. I think perhaps you're missing the point - which is 
that "Yield" allows you to WRITE a function synchronously which 
will then be executed lazily, as an iterator. What you have 
demonstrated there is USING a lazy function. How would I write, 
in D, a function that would lazily assemble some data and return 
it as a lazy collection? I mean, without calling existing lazy 
functions.

Unless ranges (which I admit to knowing very little about) can do 
this, I respectfully request that Yield be supported in D.

 You should spend some time using ranges before drawing 
 conclusions about them.

Is there a good tutorial on them? I didn't see one on the website.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 20:47:32 Stuart wrote:
 On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
 You should spend some time using ranges before drawing
 conclusions about them.

=20
 Is there a good tutorial on them? I didn't see one on the website.

There's not. There should be. But someone needs to write one. They're u=
sed=20
heavily in Phobos and a fair bit is explained in the library docs, but =
we=20
really need a general overview and explanation of the concept and how P=
hobos=20
uses them.

The best thing that we have at the moment is a chapter in a book on D t=
hat Ali=20
=C3=87ehreli wrote in Turkish and has been translating to English. It's=
 freely=20
avaiable online:

http://ddili.org/ders/d.en/ranges.html

- Jonathan M Davis

Artur Skawina <art.08.09 gmail.com> writes:

On 07/27/12 20:47, Stuart wrote:
 On Friday, 27 July 2012 at 15:09:38 UTC, Graham Fawcett wrote:
 On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even numbers
*/)();

 I think you're missing the point. The purpose isn't to generate a sequence of
numbers, but to illustrate how the Yield keyword is used in VB.NET. Sure,
getting a sequence of numbers may be straightforward, but what about a
lazy-populated list of all files on a computer? That can be done using Yield -
and more importantly, WRITTEN like a normal synchronous function. Let's see you
do that with map.

 That's easy:

   [...elided code...]
   auto entries = dirEntries(BASE_DIR, SpanMode.breadth);

 
 Ah, but that depends upon the pre-existence of the dirEntries() function. I
think perhaps you're missing the point - which is that "Yield" allows you to
WRITE a function synchronously which will then be executed lazily, as an
iterator. What you have demonstrated there is USING a lazy function. How would
I write, in D, a function that would lazily assemble some data and return it as
a lazy collection? I mean, without calling existing lazy functions.

A more or less direct translation of your original example would be:

   auto infiniteSequence1(T, S)(T startValue, S step) {
      struct IS {
         auto opApply(scope int delegate(ref T) yield) {
            while (1)
               if (auto r = yield(startValue))
                  return r;
               else
                  startValue += step;
         }
      }
   
      return IS();
   }

   void main() {
      import std.stdio;
      foreach(n; infiniteSequence(2, 2)) {
         writeln(n);
         if (n>13)
            break;
      }
   }

and a D-style range based version could look like this:

   auto infiniteSequence(T, S)(T startValue, S step) {
      static struct IS {
         T startValue;
         S step;

         enum empty = false;
          property ref front() { return startValue; }
         void popFront() { front += step; }
      }

      return IS(startValue, step);
   }

which both are as lazy as it gets. Returning direntries would be
done similarly. Is this just about the syntax (which isn't much
different)?

artur

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 19:18:11 UTC, Artur Skawina wrote:
 A more or less direct translation of your original example 
 would be:

 [...interesting code elided...]

Hmm. I think I need to learn more about ranges. They look quite 
powerful. It could, as you suggest, be nothing more than [a] a 
difference of syntax and [b] my ignorance of ranges. 
Unfortunately, I understand that information is quite scarce on 
the subject.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 20:47:32 +0200
"Stuart" <stugol gmx.com> wrote:
 
 Unless ranges (which I admit to knowing very little about) can do 
 this, I respectfully request that Yield be supported in D.
 

Being able to easily do things lazily is one of the main points of
ranges.

"Graham Fawcett" <fawcett uwindsor.ca> writes:

On Friday, 27 July 2012 at 18:47:34 UTC, Stuart wrote:
[snip]
 Ah, but that depends upon the pre-existence of the dirEntries() 
 function. I think perhaps you're missing the point - which is 
 that "Yield" allows you to WRITE a function synchronously which 
 will then be executed lazily, as an iterator. What you have 
 demonstrated there is USING a lazy function. How would I write, 
 in D, a function that would lazily assemble some data and 
 return it as a lazy collection? I mean, without calling 
 existing lazy functions.

Short answer: you'd implement an InputRange, just as dirEntries is
implemented.

When I started learning D, the lack of first-class coroutines 
("things
that yield") struck me as a real drawback. I had grown very used 
to
them in Python and in Scheme.

So I learned how to write ranges. I did not totally fall in love 
with
them. I agree with you that there is a conceptual elegance in 
writing
a coroutine as if it were a regular function, just one that 
happens to
include a "yield" keyword that seems to "remember its place" 
between
calls. I'd like to see language-level support for them in D some 
day.

Having said that, I'm satisfied with ranges. I've seen the fiber 
and
opApply ways of implementing yield, and they are okay. But the 
fact
is, it's usually not that hard to write an input range. Just make 
a
struct that implements these operations:

http://dlang.org/phobos/std_range.html#isInputRange

Decide what state you need to maintain between calls; determine
meaningful definitions for empty, front, and popFront that read 
and
manipulate that state.

Write a few of those, and the idiom will become natural to you.


not
inherently bad -- certainly not bad enough to dismiss without 
deeper
study, and certainly not bad enough to immediately jump to fibers 
or
an opApply-with-mixin trick before you've at least attempted a
range-based solution.

There is a load of reusable library code in D that can be brought 
to
bear on ranges. It's well worth a bit of mental rewiring to 
benefit
from that.

Best,
Graham

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something 
 with even numbers */)();

 I think you're missing the point. The purpose isn't to generate 
 a sequence of numbers, but to illustrate how the Yield keyword 
 is used in VB.NET. Sure, getting a sequence of numbers may be 
 straightforward, but what about a lazy-populated list of all 
 files on a computer? That can be done using Yield - and more 
 importantly, WRITTEN like a normal synchronous function. Let's 
 see you do that with map.

You wouldn't use map for that, that would be silly.

Taking a look at DirIteratorImpl[1] in std.file suggest there is 
a lot of setup to navigate the filesystem on Windows. How does 
Yield help with that logic?

1. 
https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L2397

Seriously I'll take my composing ranges over iterators any day.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 27-Jul-12 20:15, Jesse Phillips wrote:
 On Friday, 27 July 2012 at 13:10:46 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 03:00:25 UTC, Brad Anderson wrote:
 D equivalent: iota(0, int.max, 2).map!(a => /* do something with even
 numbers */)();

 I think you're missing the point. The purpose isn't to generate a
 sequence of numbers, but to illustrate how the Yield keyword is used
 in VB.NET. Sure, getting a sequence of numbers may be straightforward,
 but what about a lazy-populated list of all files on a computer? That
 can be done using Yield - and more importantly, WRITTEN like a normal
 synchronous function. Let's see you do that with map.

 You wouldn't use map for that, that would be silly.

 Taking a look at DirIteratorImpl[1] in std.file suggest there is a lot
 of setup to navigate the filesystem on Windows. How does Yield help with
 that logic?

It should be more straightforward as DirIteratorImpl does maintain stack 
of directories/searches as it goes.

The yield version could simply use recursion and yield a-la opApply 
version that was there before.

But this advantage is unimportant since arbitrary deep recursion is a 
security risk (especially for servers that typically use threads with 
tiny stacks).

 1.
 https://github.com/D-Programming-Language/phobos/blob/master/std/file.d#L2397


 Seriously I'll take my composing ranges over iterators any day.


-- 
Dmitry Olshansky

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
 But this advantage is unimportant since arbitrary deep 
 recursion is a security risk (especially for servers that 
 typically use threads with tiny stacks).

I would like to point out here that the example VB.NET code I 
just gave for lazy-populating a list of all files on a drive uses 
NO recursion whatsoever.

Recursion isn't just a security risk - it's a performance hit as 
well.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
 But this advantage is unimportant since arbitrary deep 
 recursion is a security risk (especially for servers that 
 typically use threads with tiny stacks).

 I would like to point out here that the example VB.NET code I 
 just gave for lazy-populating a list of all files on a drive 
 uses NO recursion whatsoever.

 Recursion isn't just a security risk - it's a performance hit 
 as well.

Only in languages without tail call optimizations.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance hit 
 as well.

 Only in languages without tail call optimizations.

Which is pretty much all of them.

Scheme does it, and probably HOPE too; but bugger-all you could 
write a real program in, like .NET or C++. I mean, we're in 
bloody FORTRAN territory here. What use is that for writing 
Windows applications?

Does D have tail call optimisation?

"Paulo Pinto" <pjmlp progtools.org> writes:

On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance hit 
 as well.

 Only in languages without tail call optimizations.

 Which is pretty much all of them.

 Scheme does it, and probably HOPE too; but bugger-all you could 
 write a real program in, like .NET or C++. I mean, we're in 
 bloody FORTRAN territory here. What use is that for writing 
 Windows applications?

 Does D have tail call optimisation?


Well, at least all of these:

- Scheme
- Haskell
- OCaml

- Erlang
- Clojure
- Some C and C++ compilers (gcc, Intel, MSVC in release mode)
- Most commercial Lisp compilers

Yes D compilers also do tail call optimizations in certain cases, 
even if not specified in the language spec, picking up an old 
thread

http://www.digitalmars.com/d/archives/digitalmars/D/learn/Tail_call_optimization_33772.html

--
Paulo

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance 
 hit as well.

 Only in languages without tail call optimizations.

 Which is pretty much all of them.

 Scheme does it, and probably HOPE too; but bugger-all you 
 could write a real program in, like .NET or C++. I mean, we're 
 in bloody FORTRAN territory here. What use is that for writing 
 Windows applications?

 Does D have tail call optimisation?


 Well, at least all of these:

 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

So, as I said, nothing you can write a real program in - except 

it doesn't mean you can rely on the feature being present.

 Yes D compilers also do tail call optimizations in certain 
 cases, even if not specified in the language spec

If it's not specified in the language spec - and if it's only "in 
certain cases" - how can you rely on it?

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance hit as well.

 Only in languages without tail call optimizations.

 Which is pretty much all of them.

 Scheme does it, and probably HOPE too; but bugger-all you could write
 a real program in, like .NET or C++. I mean, we're in bloody FORTRAN
 territory here. What use is that for writing Windows applications?

 Does D have tail call optimisation?


 Well, at least all of these:

 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - except possibly

 you can rely on the feature being present.

Are you serious........?

 Yes D compilers also do tail call optimizations in certain cases, even
 if not specified in the language spec

 If it's not specified in the language spec - and if it's only "in
 certain cases" - how can you rely on it?

You can't.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen 
wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - 
 except possibly

 doesn't mean
 you can rely on the feature being present.

 Are you serious........?

Uh, yeah? Aside from C (which doesn't always support tail call 

any purpose on a desktop computer. I don't know of any way, in 
this day and age, to write application software (e.g. Notepad) 
for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may 
be mistaken.

As I understand it, languages like Scheme and Cojure exist solely 
to keep mathematicians happy. If you can't call API functions in 
it, what's the use of it?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday, July 28, 2012 09:58:58 Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex R=C3=B8nne Petersen
=20
 wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

=20
 So, as I said, nothing you can write a real program in -
 except possibly

 doesn't mean
 you can rely on the feature being present.

=20
 Are you serious........?

=20
 Uh, yeah? Aside from C (which doesn't always support tail call

 any purpose on a desktop computer. I don't know of any way, in
 this day and age, to write application software (e.g. Notepad)
 for a 32 or 64-bit Windows 7 machine, in goddamn Haskell. I may
 be mistaken.

Oh, you can do it. There's no question of that. For instance, you can u=
se=20
wxhaskell to do your GUI. However, how _sane_ it is is another matter=20=

entirely. I've done a fair bit of programming in haskell and quite like=
 the=20
language (it has the best parsing library that I've ever used), but deb=
ugging=20
it is a royal pain thanks to the fact that it's a lazy language, and I =
don't=20
know how you could sanely do more than small programs with it. People=20=

definitely do it though.

- Jonathan M Davis

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 28-07-2012 09:58, Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - except possibly

 you can rely on the feature being present.

 Are you serious........?

 Uh, yeah? Aside from C (which doesn't always support tail call

 purpose on a desktop computer. I don't know of any way, in this day and
 age, to write application software (e.g. Notepad) for a 32 or 64-bit
 Windows 7 machine, in goddamn Haskell. I may be mistaken.

Some of the most robust and reliable server systems are written in Erlang.


different from using D in terms of capabilities.

Clojure runs on the JVM. It can do native invokes just like Java.

Scheme has FFI.

 As I understand it, languages like Scheme and Cojure exist solely to
 keep mathematicians happy. If you can't call API functions in it, what's
 the use of it?

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 09:05:13 UTC, Alex Rønne Petersen 
wrote:
 On 28-07-2012 09:58, Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne 
 Petersen wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release 
 mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - 
 except possibly

 doesn't mean
 you can rely on the feature being present.

 Are you serious........?

 Uh, yeah? Aside from C (which doesn't always support tail call

 have any
 purpose on a desktop computer. I don't know of any way, in 
 this day and
 age, to write application software (e.g. Notepad) for a 32 or 
 64-bit
 Windows 7 machine, in goddamn Haskell. I may be mistaken.

 Some of the most robust and reliable server systems are written 
 in Erlang.


 much different from using D in terms of capabilities.



- Visual Studio integration means I can sneak its use in my PC
- As Microsoft language is an easy sell to the boss and clients
- It has better multicore support as OCaml, which still suffers 
from a global lock


--
Paulo

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:




Especially when you consider that all flavours of .NET have 
native support for LINQ.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:




 Especially when you consider that all flavours of .NET have 
 native support for LINQ.

Let me see:

- Symbolic code manipulation;
- Metaprogramming;
- Easy parallelization of code thanks to immutable data 
structures and workflows

language data types
- The right way of doing type inference (shared by all ML 
languages)
- Asynchronous programming builtin without having to wait for 
.NET 4.5
- Algebraic data types


wasn't worth it, Microsoft is a business, not a language charity 
company.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/28/12 10:04 AM, Paulo Pinto wrote:
 On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:



 good for that a standard imperative language is not? Especially when
 you consider that all flavours of .NET have native support for LINQ.

 Let me see:

 - Symbolic code manipulation;
 - Metaprogramming;
 - Easy parallelization of code thanks to immutable data structures and
 workflows

 language data types
 - The right way of doing type inference (shared by all ML languages)
 - Asynchronous programming builtin without having to wait for ..NET 4.5
 - Algebraic data types


 it, Microsoft is a business, not a language charity company.


cool (just not all that original as a language).

Andrei

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 16:07:14 UTC, Andrei Alexandrescu 
wrote:
 On 7/28/12 10:04 AM, Paulo Pinto wrote:
 On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:




 good for that a standard imperative language is not? 
 Especially when
 you consider that all flavours of .NET have native support 
 for LINQ.

 Let me see:

 - Symbolic code manipulation;
 - Metaprogramming;
 - Easy parallelization of code thanks to immutable data 
 structures and
 workflows

 as
 language data types
 - The right way of doing type inference (shared by all ML 
 languages)
 - Asynchronous programming builtin without having to wait for 
 ..NET 4.5
 - Algebraic data types


 wasn't worth
 it, Microsoft is a business, not a language charity company.

 It was for Basic :o). Anyhow, indeed, the tools around it make 


 Andrei

Sure, as I said it is all about having Microsoft's weight on it.

deadalnix <deadalnix gmail.com> writes:

Le 28/07/2012 18:07, Andrei Alexandrescu a écrit :

 it, Microsoft is a business, not a language charity company.


 cool (just not all that original as a language).

 Andrei

Indeed, it is damn close to Caml.

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 28-07-2012 18:07, Andrei Alexandrescu wrote:
 On 7/28/12 10:04 AM, Paulo Pinto wrote:
 On Saturday, 28 July 2012 at 12:42:47 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 09:37:47 UTC, Paulo Pinto wrote:



 good for that a standard imperative language is not? Especially when
 you consider that all flavours of .NET have native support for LINQ.

 Let me see:

 - Symbolic code manipulation;
 - Metaprogramming;
 - Easy parallelization of code thanks to immutable data structures and
 workflows

 language data types
 - The right way of doing type inference (shared by all ML languages)
 - Asynchronous programming builtin without having to wait for ..NET 4.5
 - Algebraic data types


 it, Microsoft is a business, not a language charity company.


 cool (just not all that original as a language).

 Andrei

What makes you say that?


then to be fair, we would have to call D very unoriginal too...)


superior language:

* Reified generics: 
http://msdn.microsoft.com/en-us/library/dd233215(v=vs.110)
* Inline functions (I'm still amazed D doesn't have this yet): 
http://msdn.microsoft.com/en-us/library/dd548047(v=vs.110)
* Type extensions, a (IMO) much cleaner approach to artificially 
extending types: http://msdn.microsoft.com/en-us/library/dd233211(v=vs.110)
* Pattern matching (oh how I miss this in compiler code): 
http://msdn.microsoft.com/en-us/library/dd547125(v=vs.110)
* Annotations: http://msdn.microsoft.com/en-us/library/dd233179(v=vs.110)
* Units of measure: 
http://msdn.microsoft.com/en-us/library/dd233243(v=vs.110)

http://msdn.microsoft.com/en-us/library/dd233182(v=vs.110)
* Code quotations, making for metaprogramming that can do things even 
D's metaprogramming can't: 
http://msdn.microsoft.com/en-us/library/dd233212(v=vs.110)
* Async workflows (actually a library solution built through computation 
expressions): http://msdn.microsoft.com/en-us/library/dd233250(v=vs.110)
* Query expressions (again, based on computation expressions): 
http://msdn.microsoft.com/en-us/library/hh225374(v=vs.110)
* Automatic generalization: 
http://msdn.microsoft.com/en-us/library/dd233183(v=vs.110).aspx
* Type providers (type-safe data access): 
http://msdn.microsoft.com/en-us/library/hh156509(v=vs.110).aspx

There are probably lots of other features that I have forgotten. I don't 


-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/30/12 3:33 PM, Alex Rønne Petersen wrote:
 There are probably lots of other features that I have forgotten. I don't


I stand corrected!

Andrei

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 07:58:59 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 07:45:20 UTC, Alex Rønne Petersen 
 wrote:
 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - 
 except possibly

 doesn't mean
 you can rely on the feature being present.

 Are you serious........?

 Uh, yeah? Aside from C (which doesn't always support tail call 

 have any purpose on a desktop computer. I don't know of any 
 way, in this day and age, to write application software (e.g. 
 Notepad) for a 32 or 64-bit Windows 7 machine, in goddamn 
 Haskell. I may be mistaken.

What about X Window managers (xmonad) ?
Or Operating systems (Home)?

Tim Sweeney from Valve, seems to have a different opinion from you
http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt


 As I understand it, languages like Scheme and Cojure exist 
 solely to keep mathematicians happy. If you can't call API 
 functions in it, what's the use of it?

Soundcloud, LinkedIn, Twitter, Facebook seem to think differently.

In Germany there are quite a few Clojure based projects both 
server
side and desktop based.

Some people are even crazy enough to sell PS games with Lisp
based engines (Crash Bandicoot/GOOL) or  Abuse in MS-DOS days.


--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 28 Jul 2012 09:45:19 +0200
Alex R=F8nne Petersen <alex lycus.org> wrote:

 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - except

 it doesn't mean you can rely on the feature being present.

=20
 Are you serious........?
=20

I would tend to agree with him, unless you're being overly literal.

Obviously you *can* do real programs in C/C++, hell I've done it (and I
am doing it, much to my dismay) - but it's notoriously painful. As for
the rest, yea, sure, stuff *has* been written in them, but regardless,
most of them still just aren't *realistically* suitable for most
software development.

It's just like how somebody once write a high-precision Pi calculator
in MS Batch. They pulled it off, and it works, but that doesn't mean
Batch is realistically suitable as a numeric processing language.

Writing real software in, for example, Haskell is like calculating
high-precision Pi in Batch. It can be done, but it takes a masochist.

=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

On 28-07-2012 10:16, Nick Sabalausky wrote:
 On Sat, 28 Jul 2012 09:45:19 +0200
 Alex Rønne Petersen <alex lycus.org> wrote:

 On 28-07-2012 09:36, Stuart wrote:
 On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 So, as I said, nothing you can write a real program in - except

 it doesn't mean you can rely on the feature being present.

 Are you serious........?

 I would tend to agree with him, unless you're being overly literal.

 Obviously you *can* do real programs in C/C++, hell I've done it (and I
 am doing it, much to my dismay) - but it's notoriously painful. As for
 the rest, yea, sure, stuff *has* been written in them, but regardless,
 most of them still just aren't *realistically* suitable for most
 software development.

 It's just like how somebody once write a high-precision Pi calculator
 in MS Batch. They pulled it off, and it works, but that doesn't mean
 Batch is realistically suitable as a numeric processing language.

 Writing real software in, for example, Haskell is like calculating
 high-precision Pi in Batch. It can be done, but it takes a masochist.

Pointing out the most extreme cases is not really a good way to make a 
point about language usability IMO.

Most of the languages mentioned are very usable for the areas they were 
intended to be used in. Use them in an area they aren't meant for and 
you're pretty much asking for whatever you end up with. Batch sure as 
hell wasn't meant for calculation of *any* kind...

Of course C and C++ are painful. No argument there. But that's due to 
them being designed decades ago. Erlang, OCaml, Clojure, etc are fairly 
sane. Scheme, too, if you (don't (mind (the (parentheses))). :)

(I know, I know, that isn't valid Scheme...)

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"q66" <quaker66 gmail.com> writes:

On Friday, 27 July 2012 at 21:59:33 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:14:29 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 19:09:27 UTC, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 Recursion isn't just a security risk - it's a performance 
 hit as well.

 Only in languages without tail call optimizations.

 Which is pretty much all of them.

 Scheme does it, and probably HOPE too; but bugger-all you 
 could write a real program in, like .NET or C++. I mean, we're 
 in bloody FORTRAN territory here. What use is that for writing 
 Windows applications?

 Does D have tail call optimisation?


 Well, at least all of these:

 - Scheme
 - Haskell
 - OCaml

 - Erlang
 - Clojure
 - Some C and C++ compilers (gcc, Intel, MSVC in release mode)
 - Most commercial Lisp compilers

 Yes D compilers also do tail call optimizations in certain 
 cases, even if not specified in the language spec, picking up 
 an old thread

 http://www.digitalmars.com/d/archives/digitalmars/D/learn/Tail_call_optimization_33772.html

 --
 Paulo

All implementations of Lua also perform TOC and as far as I know 
some of Python implementations as well.

"q66" <quaker66 gmail.com> writes:

 All implementations of Lua also perform TOC and as far as I 
 know some of Python implementations as well.

err TCO :)

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 27-Jul-12 23:09, Paulo Pinto wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
 But this advantage is unimportant since arbitrary deep recursion is a
 security risk (especially for servers that typically use threads with
 tiny stacks).

 I would like to point out here that the example VB.NET code I just
 gave for lazy-populating a list of all files on a drive uses NO
 recursion whatsoever.


It sure thing would. Just list your code to do so. Recursively scan all 
files on drive does involve stack or recursion.

If you mean list all files shallowly then of course no recursion takes 
place (but then ranges will do the same no problem).

 Recursion isn't just a security risk - it's a performance hit as well.

 Only in languages without tail call optimizations.

Tail call won't do. Precisely because call in this function saves state. 
In effect you maintain the same stack of directories but implicitly so 
though hardware call stack with locals.



-- 
Dmitry Olshansky

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 22:34:13 UTC, Dmitry Olshansky wrote:
 On Friday, 27 July 2012 at 19:04:07 UTC, Stuart wrote:
 I would like to point out here that the example VB.NET code I 
 just
 gave for lazy-populating a list of all files on a drive uses 
 NO
 recursion whatsoever.


 It sure thing would. Just list your code to do so. Recursively 
 scan all files on drive does involve stack or recursion.

I already *did* list my code. Check previous posts. And you're 
wrong - there are no recursive calls. I maintain a queue of 
pending directories.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Jul 27, 2012 at 09:04:06PM +0200, Stuart wrote:
 On Friday, 27 July 2012 at 16:28:50 UTC, Dmitry Olshansky wrote:
But this advantage is unimportant since arbitrary deep recursion is a
security risk (especially for servers that typically use threads with
tiny stacks).

 
 I would like to point out here that the example VB.NET code I just
 gave for lazy-populating a list of all files on a drive uses NO
 recursion whatsoever.
 
 Recursion isn't just a security risk - it's a performance hit as well.

I'm pretty sure Yield has a performance hit as well, 'cos it amounts to
an implicit context-switch between two fibers. Once translated to the
machine level, there is no such thing as yielding; you have to save your
current state and return control to the caller, then recover your state
when you get called again.


performance hit is probably hidden in the VM overhead, since the VM is
already keeping track of states anyway, so the cost of tracking multiple
states is absorbed into the VM's overall overhead. So you probably won't
_notice_ the cost, but it's definitely there.


T

-- 
People walk. Computers run.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 I'm pretty sure Yield has a performance hit as well, 'cos it 
 amounts to an implicit context-switch between two fibers.

Unless I'm sorely mistaken, Yield has bugger-all to do with 
fibers. I say again: I'm not talking about threading. There is 
more than one meaning of the word "yield". Go look it up. I 
provided a link in a previous post.


 so, this performance hit is probably hidden in the VM overhead,
 since the VM is already keeping track of states anyway, so the
 cost of tracking multiple states is absorbed into the VM's 
 overall
 overhead. So you probably won't _notice_ the cost, but it's 
 definitely
 there.

I'm fairly sure D could implement the Iterator and Yield keywords 
from VB.NET without all this "overhead" to which you refer. As I 
said, go look it up.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 21:17:10 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 I'm pretty sure Yield has a performance hit as well, 'cos it 
 amounts to an implicit context-switch between two fibers.

 

Someone linked to an article which explained that .NET coroutines work,
not by using fibers, but by translating the coroutine's source code into
an equivalent switch-driven state machine. Pretty cool, actually.

 Unless I'm sorely mistaken, Yield has bugger-all to do with 
 fibers. I say again: I'm not talking about threading.

Fibers aren't threading.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 an implicit context-switch between two fibers

I've just looked up "fiber" and "coroutine". Sounds like a very 
useful concept. As previously stated, VB.NET iterators implement 
coroutines WITHOUT fibers; but I can see where fibers would be 
useful.

What is the recommended way to implement coroutines in D? More 
RANGE stuff?

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 21:31:08 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 19:12:41 UTC, H. S. Teoh wrote:
 an implicit context-switch between two fibers

 
 I've just looked up "fiber" and "coroutine". Sounds like a very 
 useful concept. As previously stated, VB.NET iterators implement 
 coroutines WITHOUT fibers; but I can see where fibers would be 
 useful.
 
 What is the recommended way to implement coroutines in D? More 
 RANGE stuff?

In D, coroutines are implemented by using Fiber:
http://dlang.org/phobos/core_thread.html#Fiber

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 27 Jul 2012 18:15:45 +0200, Jesse Phillips  
<Jessekphillips+D gmail.com> wrote:

 Seriously I'll take my composing ranges over iterators any day.


sometimes forward ranges) than they are C++ iterators.

Given that, they are as composable as D ranges.

-- 
Simen

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 16:15:46 UTC, Jesse Phillips wrote:
 Taking a look at DirIteratorImpl[1] in std.file suggest there 
 is a lot of setup to navigate the filesystem on Windows. How 
 does Yield help with that logic?

Well, off the top of my head, you could use something like:

    Public Iterator Function AllFiles(RootDirectory As String) As 
IEnumerable(Of String)
       Dim Roots As New Queue(Of String) From {RootDirectory}
       While Roots.Any
          Dim Root = Roots.Pop
          Roots.AddRange(IO.Directory.GetDirectories(Root))
          For Each Filename in IO.Directory.GetFiles(Root)
             Yield Filename
          Next
       End While
    End Function

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 27-Jul-12 22:58, Stuart wrote:
 On Friday, 27 July 2012 at 16:15:46 UTC, Jesse Phillips wrote:
 Taking a look at DirIteratorImpl[1] in std.file suggest there is a lot
 of setup to navigate the filesystem on Windows. How does Yield help
 with that logic?

 Well, off the top of my head, you could use something like:

     Public Iterator Function AllFiles(RootDirectory As String) As
 IEnumerable(Of String)
        Dim Roots As New Queue(Of String) From {RootDirectory}
        While Roots.Any
           Dim Root = Roots.Pop
           Roots.AddRange(IO.Directory.GetDirectories(Root))
           For Each Filename in IO.Directory.GetFiles(Root)
              Yield Filename
           Next
        End While
     End Function

Then it's not in anyway better then ranges. You again maintain stack (or 
queue, whatever). The only difference is that for is replaced with a 
function front/popFront that do one iteration of the same state machine.

-- 
Dmitry Olshansky

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 22:38:46 UTC, Dmitry Olshansky wrote:
 On 27-Jul-12 22:58, Stuart wrote:
 Well, off the top of my head, you could use something like:

    Public Iterator Function AllFiles(RootDirectory As String) 
 As
 IEnumerable(Of String)
       Dim Roots As New Queue(Of String) From {RootDirectory}
       While Roots.Any
          Dim Root = Roots.Pop
          Roots.AddRange(IO.Directory.GetDirectories(Root))
          For Each Filename in IO.Directory.GetFiles(Root)
             Yield Filename
          Next
       End While
    End Function

 Then it's not in anyway better then ranges.

I assume you mean "any way" - "anyway" has a different meaning. 
And I don't know much about ranges, because there's very little 
documentation. But as I understand it, for ranges I'd need to 
write a whole new class. Here, I'm writing a SINGLE FUNCTION in 
standard imperative style.

 You again maintain stack (or queue, whatever).

There is a difference between recursion (stack) and state 
variables. To claim that my function is recursive is sheer 
nonsense. Recursion is costlier than a local queue.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 28-Jul-12 11:49, Stuart wrote:
 On Friday, 27 July 2012 at 22:38:46 UTC, Dmitry Olshansky wrote:
 On 27-Jul-12 22:58, Stuart wrote:
 Well, off the top of my head, you could use something like:

    Public Iterator Function AllFiles(RootDirectory As String) As
 IEnumerable(Of String)
       Dim Roots As New Queue(Of String) From {RootDirectory}
       While Roots.Any
          Dim Root = Roots.Pop
          Roots.AddRange(IO.Directory.GetDirectories(Root))
          For Each Filename in IO.Directory.GetFiles(Root)
             Yield Filename
          Next
       End While
    End Function

 Then it's not in anyway better then ranges.

 I assume you mean "any way" - "anyway" has a different meaning. And I
 don't know much about ranges, because there's very little documentation.
 But as I understand it, for ranges I'd need to write a whole new class.

struct. Yeah, you need it.

 Here, I'm writing a SINGLE FUNCTION in standard imperative style.

That implicitly constructs Iterator.
It's just a sugar. In fact you can do template mixin to generate most of 
range boilerplate.

 You again maintain stack (or queue, whatever).

 There is a difference between recursion (stack) and state variables. To
 claim that my function is recursive is sheer nonsense.

I haven't claimed that in this post. Like I said, you indeed create a 
state automation. That is a function + state struct (bunch of state 
vars). It's not a SINGLE FUNCTION in the end. It's a sugar for special 
object with member function  "next" or whatever.
Also this object should implement all members of Iterator, meaning it's 
polymorphic and uses virtual calls.

What I tried to point out is that the end result is the same, with yield 
you just generate state object automatically (and wrap it in polymorphic 
Iterator?).

 Recursion is
 costlier than a local queue.

Not necessarily.  Again, hardware stack is faster, but saves more stuff 
(unlike your queue that saves only filenames).
So recursion is not extremely costly on its own, I'd say even faster. In 
fact, incredibly popular PCRE uses recursion to process regular 
expressions. At least there it was faster then explicit stack, the only 
problematic thing is requirement to have big thread stack.


-- 
Dmitry Olshansky

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 08:53:43 UTC, Dmitry Olshansky wrote:
 On 28-Jul-12 11:49, Stuart wrote:
 But as I understand it, for ranges I'd need to write a whole 
 new class.

 struct. Yeah, you need it.

 Here, I'm writing a SINGLE FUNCTION in standard imperative 
 style.

 That implicitly constructs Iterator.
 It's just a sugar. In fact you can do template mixin to 
 generate most of range boilerplate.

I think the basic thrust of my point is: Sugar is good. The 
compiler converting an imperative function into a state-machine 
class is helpful. Having to write it yourself every damn time is 
a pain in the arse.

I've been reading about ranges at 
[http://ddili.org/ders/d.en/ranges.html], and don't understand 
something. Where it says:

    struct StudentRange {
     Student[] students;

     this(School school) {
         this.students = school.students;
     }

     [...code...]

Surely "students" is copied here? Isn't the whole point NOT to 
copy the array? Perhaps it should say:

    this.students = school.students[];

?

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 28-Jul-12 13:00, Stuart wrote:
 On Saturday, 28 July 2012 at 08:53:43 UTC, Dmitry Olshansky wrote:
 On 28-Jul-12 11:49, Stuart wrote:
 But as I understand it, for ranges I'd need to write a whole new class.

 struct. Yeah, you need it.

 Here, I'm writing a SINGLE FUNCTION in standard imperative style.

 That implicitly constructs Iterator.
 It's just a sugar. In fact you can do template mixin to generate most
 of range boilerplate.

 I think the basic thrust of my point is: Sugar is good. The compiler
 converting an imperative function into a state-machine class is helpful.
 Having to write it yourself every damn time is a pain in the arse.

It would be good to redo opApply so that it does something like this. In 
fact look at opApply it's approach is the other way around - instead of 
generating object it packs function as delegate and passes it to some 
internal iteration mechanism:

for(v; a){
	v++;
}

--->

a.opApply(x => x++);

where a's opApply can do whatever it wants to with this delegate and 
elements.

 I've been reading about ranges at
 [http://ddili.org/ders/d.en/ranges.html], and don't understand
 something. Where it says:

     struct StudentRange {
      Student[] students;

      this(School school) {
          this.students = school.students;
      }

      [...code...]

 Surely "students" is copied here? Isn't the whole point NOT to copy the
 array? Perhaps it should say:

     this.students = school.students[];

 ?

Okay. You also need to learn how D arrays or rather slices work :)
It copies 2 words: pointer and length. Thus students points to the same 
array in both cases.

To make a full copy use .dup. You really need to checkout Steven's D 
slices article can't recall link offhand.

-- 
Dmitry Olshansky

Mike Parker <aldacron gmail.com> writes:

On 7/28/2012 6:07 PM, Dmitry Olshansky wrote:

 To make a full copy use .dup. You really need to checkout Steven's D
 slices article can't recall link offhand.

http://dlang.org/d-array-article.html

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/27/12 6:38 PM, Dmitry Olshansky wrote:
 Then it's not in anyway better then ranges. You again maintain stack (or
 queue, whatever). The only difference is that for is replaced with a
 function front/popFront that do one iteration of the same state machine.

I'd say this argument on which is "better", yield or ranges, is a 
problem ill posed.

"yield" adds real, nontrivial value, and is not entirely implementable 

were quite impressive.

On the other hand yield's charter is limited when compared to that of 
ranges. Yield goes with the very simple "go through everything once" 
functionality, which is essentially input ranges - only a tiny part of 
ranges can do.


Andrei

"David Piepgrass" <qwertie256 gmail.com> writes:

 I'd say this argument on which is "better", yield or ranges, is 
 a problem ill posed.

Yeah, since yielding is just a convenient way to implement an 
input range, asking which is better is like asking "Which is 
better, pick-up trucks or vehicles?"

 "yield" adds real, nontrivial value, and is not entirely 
 implementable as a library. Walter and I saw some uses of it in 


 On the other hand yield's charter is limited when compared to 
 that of ranges. Yield goes with the very simple "go through 
 everything once" functionality, which is essentially input 
 ranges - only a tiny part of ranges can do.

 "yield" adds real, nontrivial value, and is not entirely 
 implementable as a library. Walter and I saw some uses of it in 


Agreed. However, I have been looking at D's Fibers and I wonder 
if an optimized implementation of them could provide the same 
functionality reasonably well:

https://www.semitwist.com/articles/article/view/combine-coroutines-and-input-ranges-for-dead-simple-d-iteration

The only problem is performance (and perhaps memory usage, but 
there are ways to reduce that). Someone reported that a trivial 
fiber-based forward range had 26x the overhead of opApply for 
iteration (70s vs 2.7s for 1 billion iterations). I wonder if the 
fiber-switching could be optimized? But I looked at core/thread.d 
and unless I'm missing something, the fiber switch does not 
appear to do much work: it calls Thread.getThis() twice per 
switch (= 4 times per iteration), getStackTop() (= rt_stackTop) 
once, and a naked asm routine with 21 asm instructions. The 
entire yield() process contains no branches; call() additionally 
calls setThis() twice and checks if the Fiber threw an exception. 
What's the easiest way to time something in D? I'm curious if 
Thread.getThis() (= TlsGetValue()) is the bottleneck.

Anyway, stack-switching lets you do not only the same things as 



http://qscribble.blogspot.ca/2012/07/asyncawait-vs-stack-switching.html

i.e. stack switching can accomplish tasks that async/await 
cannot, while I don't know of any cases of the reverse. async is 
more limited because all functions involved in an async task must 
be explicitly marked and transformed by the compiler, but stack 
switching works no matter what code is involved; even C code can 
be called on an asynchronous fiber task.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 28 Jul 2012 20:32:57 +0200
"David Piepgrass" <qwertie256 gmail.com> wrote:

 What's the easiest way to time something in D?

{
    import std.datetime;
    StopWatch stopWatch;
    stopWatch.start();
    scope(exit)
        writeln(stopWatch.peek.msecs, "ms");
		
    // Do stuff to be timed
}


Or use my verboseSection wrapper:

https://bitbucket.org/Abscissa/semitwistdtools/src/8123e04b593c/src/semitwist/util/mixins.d#cl-644

bool verbose = true;
...
{
    mixin(verboseSection!"Making the fizzbar");
    makeFizzbar();
}
Output:
Making the fizzbar...732ms

"David Piepgrass" <qwertie256 gmail.com> writes:

On Friday, 27 July 2012 at 01:56:33 UTC, Stuart wrote:
 On Friday, 27 July 2012 at 00:10:31 UTC, Brad Anderson wrote:
 D uses ranges instead of iterators. You can read more about 
 them here: http://ddili.org/ders/d.en/ranges.html

 I find ranges to be a vast improvement over iterators 
 personally (I use iterators extensively in C++ for my job and 
 lament not having ranges regularly).

 On Friday, 27 July 2012 at 00:17:21 UTC, H. S. Teoh wrote:
 D has something far superior: ranges.

 	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1

 Even better, they are completely implemented in the library. No
 unnecessary language bloat just to support them.

 I'm not very well up on ranges. I understand the general [1 ... 
 6] type of ranges, but I really don't see how custom range 
 functions could be as useful as the Yield support in VB.NET.

Yes, I think H. S. Teoh wrote what that without knowing what 


.NET has a concept of "enumerators" which are basically 
equivalent to D's "input ranges". Both enumerators and input 
ranges are easier to use and safer than C++ iterators. Neither 
enumerators nor input ranges require any language support to use, 




that transforms a function into a state machine that provides an 
enumerator (or "enumerable"). These are indeed very useful, and 
missing from D. Here is an example of an iterator that I updated 
today:

public IEnumerable<IMapOverlay> Overlays() {
	foreach (var ps in _patterns)
	{
		yield return ps.RouteLine;
		yield return ps.PermShapes;
		if (ps.Selected)
			yield return ps.SelShapes;
	}
}

It does not work like opApply; the compiler creates a heap object 
that implements IEnumerable or IEnumerator (depending on the 
return value that you ask for -- it is actually IEnumerator that 
works like a forward ranges, but foreach only accepts 
IEnumerable, which is a factory for IEnumerators)

In D you could use opApply to do roughly the same thing, but in 
that case the caller cannot treat the opApply provider like an 
ordinary collection (e.g. IIUC, the caller cannot use map or 
filter on the results).

Jacob Carlborg <doob me.com> writes:

On 2012-07-27 02:10, Brad Anderson wrote:

 D uses ranges instead of iterators. You can read more about them here:
 http://ddili.org/ders/d.en/ranges.html

 I find ranges to be a vast improvement over iterators personally (I use
 iterators extensively in C++ for my job and lament not having ranges
 regularly).

Note that iterators in .NET and C++ are a bit different. .NET has 
language support with the "yield" keyword.

-- 
/Jacob Carlborg

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

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

Jacob Carlborg <doob me.com> writes:

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

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

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

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 07:42:51 UTC, Nick Sabalausky 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.

It's well-documented. The compiler creates an anonymous class 
with a state machine. It's really useful.

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Fri, Jul 27, 2012 at 01:59:12AM +0200, Stuart wrote:
 I'm quite new to D, and I've just been reading the guides. I just
 wanted to say I'm very impressed with some of the features I'm reading
 about. Slices, closures, the scope keyword(!!!), class variable
 initialisers, anonymous array literals, array concatenation,
 synchronisation... even decent exception support is a breath of fresh
 air compared to C++.

I think certain usages of the scope keyword is being phased out?
(Somebody else can clarify this.)


[...]
 Why does D have GOTO? I haven't used GOTO in over a decade, because
 it's truly evil.

You don't have to use it. In my experience with C++ and D, I've never
needed to use goto. (I do use it sometimes in C mainly because error
handling is so horrible in C otherwise.)


[...]
 One thing I really think D ought to have is iterators, like VB.NET and


D has something far superior: ranges.

	http://www.informit.com/articles/printerfriendly.aspx?p=1407357&rll=1

Even better, they are completely implemented in the library. No
unnecessary language bloat just to support them.


T

-- 
Ph.D. = Permanent head Damage

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

Welcome! :)

On 07/26/2012 04:59 PM, Stuart wrote:

 Why does D have GOTO? I haven't used GOTO in over a decade, because it's
 truly evil.

GOTO is evil; 'goto' is not! ;) goto makes switch-case statements safer 
in D:

   http://dlang.org/statement.html#GotoStatement

 iterators

Here is a paper that compares different approaches:

   http://www.informit.com/articles/printerfriendly.aspx?p=1407357

Ali

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:
 Welcome! :)

 GOTO is evil; 'goto' is not! ;) goto makes switch-case 
 statements safer in D:

Well, kinda. "Goto case" and such are one thing, but allowing the 
arbitrary use of goto for jumping around from label to label.... 
I just don't understand why the language even supports this. 
Anyone using 'goto label' in their code is doing it wrong. Period.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 03:58:52 Stuart wrote:
 On Friday, 27 July 2012 at 00:23:54 UTC, Ali =C3=87ehreli wrote:
 Welcome! :)
=20
 GOTO is evil; 'goto' is not! ;) goto makes switch-case

=20
 statements safer in D:

 Well, kinda. "Goto case" and such are one thing, but allowing the
 arbitrary use of goto for jumping around from label to label....
 I just don't understand why the language even supports this.
 Anyone using 'goto label' in their code is doing it wrong. Period.

You're going to find plenty of people who disagree with you when dealin=
g with a=20
systems language. Particularly when dealing with low level code, gotos =
can be=20
very useful. Granted, if code is littered with them, there's no questio=
n that=20
there's a problem, but there are definitely cases where using goto actu=
ally=20
improves code - especially when efficiency is a major concern. They're =
just=20
relatively rare. Other, good, language constructs make them far less ne=
cessary=20
than they once were.

- Jonathan M Davis

=?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:

On 07/26/2012 06:58 PM, Stuart wrote:
 On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:

 Well, kinda. "Goto case" and such are one thing, but allowing the
 arbitrary use of goto for jumping around from label to label.... I just
 don't understand why the language even supports this.

Unlike C++, the language disallows unsafe jumping forward (or is it dmd 
that disallows it?). Hmmm... Maybe I am wrong... (?) I swear, the 
following code used to generate a compilation error:

     if (aCondition) {
         goto label;    // Jumps over s's constructor call
     }

     auto s = S(7);

label:

     s.foo();

The error used to say:

   "Error: cannot goto forward into different try block level."

The code is allowed by dmd 2.059.

The code is allowed for classes as well but of course there is a 
segmentation faault due to foo() on the null object. Strange...

 Anyone using 'goto
 label' in their code is doing it wrong. Period.

I agree.

Ali

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 27-07-2012 05:32, Ali Çehreli wrote:
 On 07/26/2012 06:58 PM, Stuart wrote:
  > On Friday, 27 July 2012 at 00:23:54 UTC, Ali Çehreli wrote:

  > Well, kinda. "Goto case" and such are one thing, but allowing the
  > arbitrary use of goto for jumping around from label to label.... I just
  > don't understand why the language even supports this.

 Unlike C++, the language disallows unsafe jumping forward (or is it dmd
 that disallows it?). Hmmm... Maybe I am wrong... (?) I swear, the
 following code used to generate a compilation error:

      if (aCondition) {
          goto label;    // Jumps over s's constructor call
      }

      auto s = S(7);

 label:

      s.foo();

 The error used to say:

    "Error: cannot goto forward into different try block level."

 The code is allowed by dmd 2.059.

 The code is allowed for classes as well but of course there is a
 segmentation faault due to foo() on the null object. Strange...

  > Anyone using 'goto
  > label' in their code is doing it wrong. Period.

 I agree.

 Ali

Jumping over initialization isn't as problematic in D because variables 
are guaranteed to have a default initialization value (if not 
initialized to void). It's worse in languages like C where the value of 
variables would be undefined.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 27 Jul 2012 06:36:57 +0200, Alex R=C3=B8nne Petersen <alex lycus=
.org>  =

wrote:

 Jumping over initialization isn't as problematic in D because variable=

s  =

 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 co=
de?


 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 sp=
ec:

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


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

-- =

Simen

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

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> writes:

On Friday, 27 July 2012 at 07:41:50 UTC, 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?

A very good question.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Thu, 26 Jul 2012 17:23:53 -0700
Ali =C7ehreli <acehreli yahoo.com> wrote:
  > iterators
=20
 Here is a paper that compares different approaches:
=20
    http://www.informit.com/articles/printerfriendly.aspx?p=3D1407357
=20

As great as Andrei's article is, this makes me think: We need a short
article with a simple little example that demonstrates *how* D's ranges
really do kick iterators' asses. Any good ideas?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Thursday, July 26, 2012 17:18:38 H. S. Teoh wrote:
 On Fri, Jul 27, 2012 at 01:59:12AM +0200, Stuart wrote:
 I'm quite new to D, and I've just been reading the guides. I just
 wanted to say I'm very impressed with some of the features I'm reading
 about. Slices, closures, the scope keyword(!!!), class variable
 initialisers, anonymous array literals, array concatenation,
 synchronisation... even decent exception support is a breath of fresh
 air compared to C++.

 
 I think certain usages of the scope keyword is being phased out?
 (Somebody else can clarify this.)

scope on local variables is going to be deprecated, because it's unsafe. scope 
on function parameters and scope statements are here to stay.

 [...]
 
 Why does D have GOTO? I haven't used GOTO in over a decade, because
 it's truly evil.

 
 You don't have to use it. In my experience with C++ and D, I've never
 needed to use goto. (I do use it sometimes in C mainly because error
 handling is so horrible in C otherwise.)

If you're using goto much in code, then you're doing somethnig wrong, but it 
would be a problem for a systems language _not_ to have a goto statement. On 
rare occasions (especially when writing low level code), they end up being 
very useful.

Now, D has made goto even less necessary than it is in most languages (e.g. it 
has labeled break and labeled continue which go to a label in a loop), but the 
language should still have it.

- Jonathan M Davis

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because 
 it's unsafe. scope
 on function parameters and scope statements are here to stay.

There's also scope(exit), scope(success), and scope(failure),
which aren't going anywhere.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 02:46:20 Adam D. Ruppe wrote:
 On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because
 it's unsafe. scope
 on function parameters and scope statements are here to stay.

 
 There's also scope(exit), scope(success), and scope(failure),
 which aren't going anywhere.

Yeah. Those are scope statements.

It's just scope on local variable declarations which is going away.

- Jonathan M Davis

Chad J <chadjoan __spam.is.bad__gmail.com> writes:

On 07/26/2012 08:54 PM, Jonathan M Davis wrote:
 On Friday, July 27, 2012 02:46:20 Adam D. Ruppe wrote:
 On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because
 it's unsafe. scope
 on function parameters and scope statements are here to stay.

 There's also scope(exit), scope(success), and scope(failure),
 which aren't going anywhere.

 Yeah. Those are scope statements.

 It's just scope on local variable declarations which is going away.

 - Jonathan M Davis

Stuart & other readers:

I just asked about this in the other thread, and Jonathan mentioned that 
std.typecons.scoped can be used to accomplish the same thing.  So the 
functionality isn't being removed; it's just being moved from the 
language and into the library.

I think this is worth mentioning so that it doesn't look like we are 
depriving folks of things that they had come to expect from D.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 01:54:16 UTC, Chad J wrote:
 Stuart & other readers:

 I just asked about this in the other thread, and Jonathan 
 mentioned that std.typecons.scoped can be used to accomplish 
 the same thing.  So the functionality isn't being removed; it's 
 just being moved from the language and into the library.

 I think this is worth mentioning so that it doesn't look like 
 we are depriving folks of things that they had come to expect 
 from D.

Oh, that's alright then. Although, I'd still like to know why 
it's unsafe. Also, is there any documentation on how to *use* the 
scope feature from the library? I mean, do we just "import 
std.typecons.scoped" and suddenly the keyword pops back into 
existence, or do we need to use some kind of new syntax?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 04:13:09 Stuart wrote:
 On Friday, 27 July 2012 at 01:54:16 UTC, Chad J wrote:
 Stuart & other readers:
 
 I just asked about this in the other thread, and Jonathan
 mentioned that std.typecons.scoped can be used to accomplish
 the same thing.  So the functionality isn't being removed; it's
 just being moved from the language and into the library.
 
 I think this is worth mentioning so that it doesn't look like
 we are depriving folks of things that they had come to expect
 from D.

 
 Oh, that's alright then. Although, I'd still like to know why
 it's unsafe. Also, is there any documentation on how to *use* the
 scope feature from the library? I mean, do we just "import
 std.typecons.scoped" and suddenly the keyword pops back into
 existence, or do we need to use some kind of new syntax?

We have library documentation on dlang.org:

http://dlang.org/phobos/std_typecons.html#scoped

- Jonathan M Davis

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 02:17:22 UTC, Jonathan M Davis wrote:
 
 We have library documentation on dlang.org:

 http://dlang.org/phobos/std_typecons.html#scoped

Wow! That's a lot of information.

Better get reading it, then.

Thanks.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because 
 it's unsafe.

Um...could you explain why? I thought scope on locals was a 
really nice feature. I was looking forward to making use of it 
for deterministic resource deallocation.

Besides, if scope(exit) is still allowed, how is that any 
different?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 04:00:56 Stuart wrote:
 On Friday, 27 July 2012 at 00:25:49 UTC, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because
 it's unsafe.

 
 Um...could you explain why? I thought scope on locals was a
 really nice feature. I was looking forward to making use of it
 for deterministic resource deallocation.

It's inherently unsafe. What happens if you returned a reference to foo from 
someFunc? Or if you assigned a reference to foo to anything and then tried to 
use it after someFunc has returned? You get undefined behavior, because foo 
doesn't exist anymore. If you really need foo to be on the stack, then maybe 
you should make it a struct. However, if you really do need scope for some 
reason, then you can use std.typecons.scoped, and it'll do the same thing.

scope on local variables is going away for pretty much the same reason that 
delete is. They're unsafe, and the fact that they're in the core language 
encourages their use. So, they're being removed and put into the standard 
library instead.

 Besides, if scope(exit) is still allowed, how is that any different?

scope(exit) doesn't necessarily have anything to do with deallocating memory. 
It's far more general than that. It just runs an arbitrary statement when 
exiting the scope that it's declared in. There's nothing inherently unsafe 
about that. You _can_ do unsafe operations in it, but you can do that pretty 
much anywhere. So, if you were to free GC-allocated memory in a scope 
statement, then you'd be in exactly the same sinking boat that scope puts you 
in.

Freeing GC-allocated memory is inherently unsafe. It's the GC's job to do 
that. If you really want to be managing memory yourself, then you should be 
using malloc and free. But for those occasions when you really do end up 
needing that sort of control with GC memory, we have stuff like 
std.typecons.scoped and core.memory. They just shouldn't be used under normal 
circumstances, and you have to be careful with them, so you should only used 
them when you know what you're doing - which is in stark contrast to having 
delete and scope in the core language where everyone sees them and thinks that 
they're perfectly safe to use, completely ignoring or being completely unaware 
of the dangers involved. We give you the power to blow your foot off if you 
want to, but we don't want to prime the gun and hand it to you, just make it 
available if you need it.

- Jonathan M Davis

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
 It's inherently unsafe. What happens if you returned a 
 reference to foo from someFunc?

Good answer. I didn't think of that.

 scope on local variables is going away for pretty much the same 
 reason that delete is.

Delete is going away too? Damn. Then again, I guess I'm still 
thinking in C++ terms. I need to stop doing that.

I'm having difficulty thinking in terms of D. It looks like C++, 
it compiles to native code (unlike .NET), therefore I need to 
manage memory myself... ;)

I'll get the hang of it eventually.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 04:27:36 Stuart wrote:
 On Friday, 27 July 2012 at 02:13:19 UTC, Jonathan M Davis wrote:
 It's inherently unsafe. What happens if you returned a
 reference to foo from someFunc?

 
 Good answer. I didn't think of that.
 
 scope on local variables is going away for pretty much the same
 reason that delete is.

 
 Delete is going away too? Damn. Then again, I guess I'm still
 thinking in C++ terms. I need to stop doing that.
 
 I'm having difficulty thinking in terms of D. It looks like C++,
 it compiles to native code (unlike .NET), therefore I need to
 manage memory myself... ;)
 
 I'll get the hang of it eventually.

In general, you should just let the GC do its thing. Then when you have 
portions of your code that need to be optimized, _then_ you worry about 
managing GC memory or using malloc and free instead or whatever it takes to 
make it properly efficient. Coding in a way that reduces unnecessary heap 
allocations is also good, but if you're worrying about when you need to free 
GC-allocated resources, then you're likely going about things wrong, since 
that's what the GC is for.

- Jonathan M Davis

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 02:48:36 UTC, Jonathan M Davis wrote:
 I'm having difficulty thinking in terms of D. It looks like 
 C++,
 it compiles to native code (unlike .NET), therefore I need to
 manage memory myself... ;)
 
 I'll get the hang of it eventually.

 In general, you should just let the GC do its thing.

Yeah, I know. I was just explaining how I find myself thinking in 
terms of C++ because the syntax (and compilation) is very similar.

travert phare.normalesup.org (Christophe Travert) writes:

Jonathan M Davis , dans le message (digitalmars.D:173382), a écrit :
 scope on local variables is going away for pretty much the same reason that 
 delete is. They're unsafe, and the fact that they're in the core language 
 encourages their use. So, they're being removed and put into the standard 
 library instead.
 

I don't mind scope going away, since it can be replaced with a library 
solution. But scope is not more dangerous than a static array, or simple 
function variables. Slice them, or take their reference, and you're up 
for troubles. Do you think they should be removed as core features of 
the langage?

"Jonathan M Davis" <jmdavisProg gmx.com> writes:

On Monday, July 30, 2012 11:23:06 Christophe Travert wrote:
 Jonathan M Davis , dans le message (digitalmars.D:173382), a écrit :
 scope on local variables is going away for pretty much the same reason
 that
 delete is. They're unsafe, and the fact that they're in the core language
 encourages their use. So, they're being removed and put into the standard
 library instead.

 
 I don't mind scope going away, since it can be replaced with a library
 solution. But scope is not more dangerous than a static array, or simple
 function variables. Slice them, or take their reference, and you're up
 for troubles. Do you think they should be removed as core features of
 the langage?

I don't think that you _can_ implement them in a library.

I _do_ think that implicit slicing of static arrays should go away, since it's 
just begging for bugs. But there's pretty much no way that that's going to 
change at this point.

- Jonathan M Davis

Jacob Carlborg <doob me.com> writes:

On 2012-07-27 02:25, Jonathan M Davis wrote:

 scope on local variables is going to be deprecated, because it's unsafe. scope
 on function parameters and scope statements are here to stay.

"scope" on class declarations as well.

-- 
/Jacob Carlborg

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 08:36:17 Jacob Carlborg wrote:
 On 2012-07-27 02:25, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because it's unsafe.
 scope on function parameters and scope statements are here to stay.

 
 "scope" on class declarations as well.

I didn't even know that you could do that, and I have no idea what that would 
do.

- Jonathan M Davis

Jacob Carlborg <doob me.com> writes:

On 2012-07-27 08:41, Jonathan M Davis wrote:
 On Friday, July 27, 2012 08:36:17 Jacob Carlborg wrote:
 On 2012-07-27 02:25, Jonathan M Davis wrote:
 scope on local variables is going to be deprecated, because it's unsafe.
 scope on function parameters and scope statements are here to stay.

 "scope" on class declarations as well.

 I didn't even know that you could do that, and I have no idea what that would
 do.

If I recall correctly it forces you do use "scope" when declaring a 
variable of the class.

http://dlang.org/class.html#auto

-- 
/Jacob Carlborg

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 06:36:17 UTC, Jacob Carlborg wrote:
 On 2012-07-27 02:25, Jonathan M Davis wrote:

 scope on local variables is going to be deprecated, because 
 it's unsafe. scope on function parameters and scope statements

 are here to stay.

 "scope" on class declarations as well.

Huh? If you deprecate scoped locals, you have to deprecate scope 
classes, because the latter means "must be scoped local when 
used". Yes?

"bearophile" <bearophileHUGS lycos.com> writes:

Stuart:

 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

Gotos are not so evil. Just use them when they are useful and 
they can't be replaced by structured programming. In D I create 
finite state machines at compile-time that use gotos, they are 
quick.

Bye,
bearophile

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
 Stuart:
 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

 Gotos are not so evil. Just use them when they are useful and 
 they can't be replaced by structured programming. In D I create 
 finite state machines at compile-time that use gotos, they are 
 quick.

  As mentioned, why would GOTO be evil?

  http://en.wikipedia.org/wiki/BASIC

  I'm remembering back when i used an Atari (For others, 
Commodore64 and Apple IIe), where the BASIC programming language 
supplied (via rom or built in) didn't have function calling and 
instead everything used GOTO statementes (Or GOSUB).

  Obviously spaghetti came about easily, but when the GOTO is 
dropped to only being a logical jump when no other options are 
available. Consider half a dozen GOTO's with labels nearby vs 
thousands.

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 03:23:27 Era Scarecrow wrote:
 On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
 Stuart:
 Why does D have GOTO? I haven't used GOTO in over a decade,
 because it's truly evil.

 
 Gotos are not so evil. Just use them when they are useful and
 they can't be replaced by structured programming. In D I create
 finite state machines at compile-time that use gotos, they are
 quick.

 
   As mentioned, why would GOTO be evil?
 
   http://en.wikipedia.org/wiki/BASIC
 
   I'm remembering back when i used an Atari (For others,
 Commodore64 and Apple IIe), where the BASIC programming language
 supplied (via rom or built in) didn't have function calling and
 instead everything used GOTO statementes (Or GOSUB).

That's precisely the sort of environment where goto was originally vilified. It 
was being used heavily for flow control. if statements, while loops, function 
calls, etc. all effectively use goto. They just do it for you. it was 
originally being argued that safer constructs  should be used instead of 
gotos. Now, we have way more safe constructs for moving around in code then 
was the case when goto was originally vilified, and everyone is using those 
constructs rather than goto. But the stigma remains and everyone is used to 
thinking of goto as evil.

   Obviously spaghetti came about easily, but when the GOTO is
 dropped to only being a logical jump when no other options are
 available. Consider half a dozen GOTO's with labels nearby vs
 thousands.

Exactly. Talking about goto as being evil now is almost silly when you think 
about it. It's been almost universally reduced to being use in the cases where 
it's truly useful. It's just not used anymore in the cases where it _is_ 
arguably evil. So, the problem that existed when goto was originally vilified 
has pretty much gone away, and reflexively declaring goto evil and freaking out 
over any use of it is actually harmul. It's a useful construct when used 
properly. It just shouldn't be used when there are better alternatives.

- Jonathan M Davis

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
 Now, we have way more safe constructs for moving around in code 
 then was the case when goto was originally vilified,
 and everyone is using those constructs rather than goto.
 But the stigma remains and everyone is used to thinking of goto 
 as evil.

So if everyone uses these other constructs, why even provide a 
goto? I seriously have not needed a goto in over ten years; and 
the way I see it, if your program uses one, it needs to be 
refactored. Just my opinion.

 It's a useful construct when used properly. It just shouldn't 
 be used when
 there are better alternatives.

I can't think of ANY situation where goto would be the only 
viable option. Loops, ifs, switches - these cover 100% of 
requirements, surely? If it really is necessary in some cases, 
how have I managed to avoid goto for so long? And what are these 
cases?

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 04:09:36 +0200
"Stuart" <stugol gmx.com> wrote:

 On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
 Now, we have way more safe constructs for moving around in code 
 then was the case when goto was originally vilified,
 and everyone is using those constructs rather than goto.
 But the stigma remains and everyone is used to thinking of goto 
 as evil.

 
 So if everyone uses these other constructs, why even provide a 
 goto? I seriously have not needed a goto in over ten years; and 
 the way I see it, if your program uses one, it needs to be 
 refactored. Just my opinion.
 
 It's a useful construct when used properly. It just shouldn't 
 be used when
 there are better alternatives.

 
 I can't think of ANY situation where goto would be the only 
 viable option. Loops, ifs, switches - these cover 100% of 
 requirements, surely? If it really is necessary in some cases, 
 how have I managed to avoid goto for so long? And what are these 
 cases?


Duff's device.

Goto certainly should not be used (except for "goto case") in the vast
majority of cases. And it is indeed extremely rare to find goto used in
D code. Plus having it in existence doesn't really cause problems - only
abusing it causes problems and but nobody really abuses goto anymore
anyway. But there are some rare controlled cases (like duff's device,
or porting old C code that might use it) where some low-level
programmers do consider it to be useful (whether right or wrong). So
it's there if for whatever reason you happen to need it, otherwise it
just stays out of the way and doesn't bother anybody.

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
 Plus having it in existence doesn't really cause problems - 
 only abusing it causes problems and but nobody
 really abuses goto anymore anyway.

goto in C and descendants is an entirely different animal
than the goto that people would abuse anyway.

The fact that it is scoped to functions and must go to
explicit labels limits the potential for abuse that made it
notorious.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 04:55:30 +0200
"Adam D. Ruppe" <destructionator gmail.com> wrote:
 
 The fact that [goto] is scoped to functions

I didn't think that was true in C? It's certainly true in D, anyway.

"Adam D. Ruppe" <destructionator gmail.com> writes:

On Friday, 27 July 2012 at 03:26:22 UTC, Nick Sabalausky wrote:
 I didn't think that was true in C? It's certainly true in D, 
 anyway.

It is, C and D have more or less the same goto rules.

goto.c:
===
void a() {
         goto cool;
}

void main() {
         a();
         cool: ;
}
===
$ gcc goto.c
goto.c: In function a:
goto.c:2: error: label cool used but not defined



While you can still kinda sorta spaghetti in C, the fact
that it is limited to a function makes it much easier to
follow. There's only one function to look at, not the
whole program.

The requirement of a label is important too, since any
particular line of code can't be a comes-from point;
unless there is a label there, you can be pretty confident
that the line before is actually run before.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 04:09:36 +0200
 "Stuart" <stugol gmx.com> wrote:

 I can't think of ANY situation where goto would be the only 
 viable option.

 Duff's device.

According to Wikipedia, Duff's device (about which, until just 
now, I knew nothing) can be implemented without goto. Then again, 
this might be due to "features" of C++ that are not present in D.

In any case, isn't it the job of the compiler to unroll loops? 
Why should the coder have to do this himself? Unless of course 
he's using a thin shitty wrapper over assembly language that 
claims falsely to be a high-level language - i.e. C.

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 27-07-2012 14:56, Stuart wrote:
 On Friday, 27 July 2012 at 02:41:21 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 04:09:36 +0200
 "Stuart" <stugol gmx.com> wrote:

 I can't think of ANY situation where goto would be the only viable
 option.

 Duff's device.

 According to Wikipedia, Duff's device (about which, until just now, I
 knew nothing) can be implemented without goto. Then again, this might be
 due to "features" of C++ that are not present in D.

 In any case, isn't it the job of the compiler to unroll loops? Why
 should the coder have to do this himself? Unless of course he's using a
 thin shitty wrapper over assembly language that claims falsely to be a
 high-level language - i.e. C.

It was a high-level language at the time it was created.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen 
wrote:
 On 27-07-2012 14:56, Stuart wrote:

 In any case, isn't it the job of the compiler to unroll loops? 
 Why
 should the coder have to do this himself? Unless of course 
 he's using a
 thin shitty wrapper over assembly language that claims falsely 
 to be a
 high-level language - i.e. C.

 It was a high-level language at the time it was created.

Quite possibly. But the definition of "high level" has since 
changed, and C no longer qualifies. Yet proponents of C/C++ 
continue to froth at the mouth and claim it's a decent language.

Why is D so awesome? Because it's not C.

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 27-07-2012 20:50, Stuart wrote:
 On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen wrote:
 On 27-07-2012 14:56, Stuart wrote:

 In any case, isn't it the job of the compiler to unroll loops? Why
 should the coder have to do this himself? Unless of course he's using a
 thin shitty wrapper over assembly language that claims falsely to be a
 high-level language - i.e. C.

 It was a high-level language at the time it was created.

 Quite possibly. But the definition of "high level" has since changed,
 and C no longer qualifies. Yet proponents of C/C++ continue to froth at
 the mouth and claim it's a decent language.

 Why is D so awesome? Because it's not C.

In all fairness, I think C still has its place. The advantage of writing 
software in C is that when you want to port it to a new 
platform/architecture, there will almost always be a C compiler 
available. This isn't the case for D yet - but hopefully will be in the 
future. But note, even then, that D only targets 32-bit architectures 
and up, while C can handle 16-bit architectures.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Saturday, July 28, 2012 04:31:40 Alex R=C3=B8nne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

True, but I'm kind of shocked that anything 16-bit even still exists. _=
32-bit_=20
is on its way out. I thought that 16-bit was dead _years_ ago. I guess =
that=20
some embedded stuff must use it. But really, I wouldn't expect the lack=
 of 16-
bit support to be much of an impediment - if any at all - and in the lo=
ng run,=20
it'll mean absolutely nothing.

- Jonathan M Davis

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures 
 and up, while C can handle 16-bit architectures.

 True, but I'm kind of shocked that anything 16-bit even still 
 exists. _32-bit_ is on its way out. I thought that 16-bit was 
 dead _years_ ago. I guess that some embedded stuff must use it. 
 But really, I wouldn't expect the lack of 16- bit support to be 
 much of an impediment - if any at all - and in the long run, 
 it'll mean absolutely nothing.

  The largest majority of computers and programs aren't what you 
and me use on a computer, it's things that are everywhere and 
they remain hidden. Your watch, your calculator, smart cards, CD 
players, devices (Like CD-ROM drives). There are still 8bit chips 
you can buy, program and use. For the main common computers, yes 
32bit is going out of style.

http://www.mouser.com/Semiconductors/MCU-MPU-DSP-DSC-SoC-Processors/Microprocessors-MPU/_/N-6hpeh?Keyword=microprocessors&FS=True

  It's been a while since I looked over this list or catalog.

"Jakob Ovrum" <jakobovrum gmail.com> writes:

On Saturday, 28 July 2012 at 03:06:53 UTC, Era Scarecrow wrote:
 The largest majority of computers and programs aren't what you 
 and me use on a computer, it's things that are everywhere and 
 they remain hidden. Your watch, your calculator, smart cards, 
 CD players, devices (Like CD-ROM drives). There are still 8bit 
 chips you can buy, program and use. For the main common 
 computers, yes 32bit is going out of style.

 http://www.mouser.com/Semiconductors/MCU-MPU-DSP-DSC-SoC-Processors/Microprocessors-MPU/_/N-6hpeh?Keyword=microprocessors&FS=True

  It's been a while since I looked over this list or catalog.

ARM is staying 32-bit for the foreseeable future, and ARM is just 
as important as x86 these days. The first ARM64 chips won't even 
appear for a few years still, and who knows how long it will take 
for them to take over.

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

 True, but I'm kind of shocked that anything 16-bit even still 
 exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago. 
 I guess that
 some embedded stuff must use it. But really, I wouldn't expect 
 the lack of 16-
 bit support to be much of an impediment - if any at all - and 
 in the long run,
 it'll mean absolutely nothing.

Embedded systems mostly use Java now in any case, as I understand
it.

"Daniel Murphy" <yebblies nospamgmail.com> writes:

"Stuart" <stugol gmx.com> wrote in message 
news:vjaspnvbihpgvxgqmccr forum.dlang.org...
 On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

 True, but I'm kind of shocked that anything 16-bit even still exists. 
 _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago. I guess 
 that
 some embedded stuff must use it. But really, I wouldn't expect the lack 
 of 16-
 bit support to be much of an impediment - if any at all - and in the long 
 run,
 it'll mean absolutely nothing.

 Embedded systems mostly use Java now in any case, as I understand
 it.

Your understanding is obviously quite limited. 

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 08:05:09 UTC, Daniel Murphy wrote:
 "Stuart" <stugol gmx.com> wrote in message
 Embedded systems mostly use Java now in any case, as I 
 understand
 it.

 Your understanding is obviously quite limited.

Quite possibly. I'm not an expert on embedded systems.

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Saturday, 28 July 2012 at 08:05:09 UTC, Daniel Murphy wrote:
 "Stuart" <stugol gmx.com> wrote in message
 news:vjaspnvbihpgvxgqmccr forum.dlang.org...
 Embedded systems mostly use Java now in any case, as I 
 understand it.

 Your understanding is obviously quite limited.

  I've used the java compiler for GNU's compilers; Doesn't it 
compile to native code? In which case java in the right 
compiler/setup is the same as C/C++ (To a degree... with the 
appropriate runtime)

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 28 Jul 2012 09:53:27 +0200
"Stuart" <stugol gmx.com> wrote:

 On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis wrote:
 On Saturday, July 28, 2012 04:31:40 Alex R=F8nne Petersen wrote:
 But note, even then, that D only targets 32-bit architectures
 and up, while C can handle 16-bit architectures.

 True, but I'm kind of shocked that anything 16-bit even still=20
 exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago.=20
 I guess that
 some embedded stuff must use it. But really, I wouldn't expect=20
 the lack of 16-
 bit support to be much of an impediment - if any at all - and=20
 in the long run,
 it'll mean absolutely nothing.

=20
 Embedded systems mostly use Java now in any case, as I understand
 it.

God I hope that's not true. Using a VM on a low-power system is just so
rediculously *wrong* it should be a crime.

The only embedded systems I know of that use Java are Android and
Symbian (both phones, of course). On Symbian it's optional (or at least
it was last I checked, many years ago), and at this point I think it's
questional whether Android counts as "embedded system" (more like
"handheld supercomputer").

But of course, there's no doubt *MANY* embedded systems I'm completely
unaware of...

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/28/12 4:26 AM, Nick Sabalausky wrote:
 God I hope that's not true. Using a VM on a low-power system is just so
 rediculously *wrong* it should be a crime.

Isn't Android standardizing on Java?

Andrei

=?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <alex lycus.org> writes:

On 28-07-2012 15:42, Andrei Alexandrescu wrote:
 On 7/28/12 4:26 AM, Nick Sabalausky wrote:
 God I hope that's not true. Using a VM on a low-power system is just so
 rediculously *wrong* it should be a crime.

 Isn't Android standardizing on Java?

 Andrei

Yes (see second paragraph of Nick's post).

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
 On Sat, 28 Jul 2012 09:53:27 +0200
 "Stuart" <stugol gmx.com> wrote:

 On Saturday, 28 July 2012 at 02:38:47 UTC, Jonathan M Davis 
 wrote:
 On Saturday, July 28, 2012 04:31:40 Alex Rønne Petersen 
 wrote:
 But note, even then, that D only targets 32-bit 
 architectures
 and up, while C can handle 16-bit architectures.

 True, but I'm kind of shocked that anything 16-bit even 
 still exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ 
 ago. I guess that
 some embedded stuff must use it. But really, I wouldn't 
 expect the lack of 16-
 bit support to be much of an impediment - if any at all - 
 and in the long run,
 it'll mean absolutely nothing.

 
 Embedded systems mostly use Java now in any case, as I 
 understand
 it.

 God I hope that's not true. Using a VM on a low-power system is 
 just so
 rediculously *wrong* it should be a crime.

Java != VM

There are quite a few companies selling Java native code compilers
for embedded systems.

For example, the Perc systems from Aonix,
http://www.atego.com/products/aonix-perc/

What I can say it that in telecommunications, many SIM cards are
actually running Java Card inside.

http://java.sun.com/javacard/overview.jsp

I know at least of one mobile operator that uses this in all its
SIM cards, and it is a pretty big operator available across 
Europe.
Due to NDA issues I cannot state the name, but should not be hard 
to guess.

Not really commercial product, but you can also get a Java Spot, 
with the VM almost fully implemented in Java, except for the low 
level hardware access done via native methods.

http://www.sunspotworld.com/

The embedded space is very broad, from the tiny processors which 
you still have to code in pure Assembly while counting valuable 
byte space, to some which are big enough to run Java in all 
flavours, high speed interpreter, JIT or natively.

It all a matter of cost vs type of product you want to sell.

--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 28 Jul 2012 16:33:02 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

 On Saturday, 28 July 2012 at 08:26:45 UTC, Nick Sabalausky wrote:
 God I hope that's not true. Using a VM on a low-power system is 
 just so
 rediculously *wrong* it should be a crime.

 
 Java != VM
 

Yea, people keep telling me that and I still keep forgetting :P
"Java==VM" has been ingrained pretty deeply into my brain for about 10
years. Hard to change that :)

Still, unless there's something different about these offerings, Java
(the langauge) has no low-level ability whatsoever, no manual
memory management and strongly encourages over-use of objects and heap
allocation. Even natively-compiled, that doesn't sound like my idea of a
good embedded language. But I dunno, I guess maybe if they're
using it in the sort of way that game devs use Lua...(Not that I'm a fan
of Lua - far too dynamic for my tastes.)

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Sunday, 29 July 2012 at 02:40:44 UTC, Nick Sabalausky wrote:

 Still, unless there's something different about these 
 offerings, Java (the langauge) has no low-level ability 
 whatsoever, no manual memory management and strongly encourages 
 over-use of objects and heap allocation. Even 
 natively-compiled, that doesn't sound like my idea of a good 
 embedded language. But I dunno, I guess maybe if they're using 
 it in the sort of way that game devs use Lua...(Not that I'm a 
 fan of Lua - far too dynamic for my tastes.)

  It does do low-level bit manipulation for built-in types, 
however I think that's it's limit.

Russel Winder <russel winder.org.uk> writes:

On Sun, 2012-07-29 at 04:59 +0200, Era Scarecrow wrote:
[=E2=80=A6]
   It does do low-level bit manipulation for built-in types,=20
 however I think that's it's limit.

There are no unsigned types which leads to extremely ugly bit
manipulation codes.

Primitive types are now effectively deprecated in Java, and this is
likely a deprecation which will actually lead to a removal =E2=80=93 unlike
everything else in Java that has been deprecated which is still there.

Sun did one time actually remove something from a Java release but there
was such an outcry that it got put back in. Sadly it should never have
been taken out in the first place. Unlike all the stuff that has been
deprecated for >10 years which should have gone long ago.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Paulo Pinto" <pjmlp progtools.org> writes:

On Sunday, 29 July 2012 at 08:34:33 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 04:59 +0200, Era Scarecrow wrote:
 […]
   It does do low-level bit manipulation for built-in types, 
 however I think that's it's limit.

 There are no unsigned types which leads to extremely ugly bit
 manipulation codes.

 Primitive types are now effectively deprecated in Java, and 
 this is
 likely a deprecation which will actually lead to a removal – 
 unlike
 everything else in Java that has been deprecated which is still 
 there.

 Sun did one time actually remove something from a Java release 
 but there
 was such an outcry that it got put back in. Sadly it should 
 never have
 been taken out in the first place. Unlike all the stuff that 
 has been
 deprecated for >10 years which should have gone long ago.

I like Java, but currently have a few issues with the some of the 
design decisions after Java 5, namely the overuse of annotations 
instead of adding new keywords. Examples are  Overload,  Checked, 
 NotNull,  Null, or worse the possible  Value annotation.

I mean, use  Value to specify a class with value semantics, 
really?! Is it that complicated to add struct as keyword?


to criticise as being a cheap Java clone back in 2001. How things 
change.

--
Paulo

"Minas Mina" <minas_mina1990 hotmail.co.uk> writes:

The only thing Java is good for is portability. And its standard 
library is very good too.

However the language as it is, really sucks in my opinion. I 
mean, there's no way to change the value of a primitive type 
passed to a method? Come on.

Jacob Carlborg <doob me.com> writes:

On 2012-07-29 15:10, Minas Mina wrote:
 The only thing Java is good for is portability. And its standard library
 is very good too.

 However the language as it is, really sucks in my opinion. I mean,
 there's no way to change the value of a primitive type passed to a
 method? Come on.

There are many other languages available on the JVM platform. Scala for 
example.

-- 
/Jacob Carlborg

"Paulo Pinto" <pjmlp progtools.org> writes:

On Sunday, 29 July 2012 at 19:23:38 UTC, Jacob Carlborg wrote:
 On 2012-07-29 15:10, Minas Mina wrote:
 The only thing Java is good for is portability. And its 
 standard library
 is very good too.

 However the language as it is, really sucks in my opinion. I 
 mean,
 there's no way to change the value of a primitive type passed 
 to a
 method? Come on.

 There are many other languages available on the JVM platform. 
 Scala for example.

The problem is that in the enterprise world with expendable 
programmers, is very hard to do JVM based projects with anything 
other than Java.

I was very happy when on a project for a new internal proprietary 
JSF based framework, we were allowed to have Groovy as part of 
the framework's supported languages.

That only happened because the said company was replacing the 
Perl scripts by Groovy scripts in their deployment infrastructure.

--
Paulo

Russel Winder <russel winder.org.uk> writes:

On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
[=E2=80=A6]
 The problem is that in the enterprise world with expendable=20
 programmers, is very hard to do JVM based projects with anything=20
 other than Java.

My experience from various training courses I have given is that in the
large corporate Web applications world, the average programmer knows
Java, just enough Java, and isn't that interested in anything else.
Gross oversimplification but a good indicator.  However within the
financial sector, some of the large players are ditching Java and
unitary systems in favour of a small Scala core and Python using what is
effectively an SOA architecture. In all these organizations there are

In other organizations Java remains the core but Groovy, JRuby and
Clojure are admitted, which sounds like your experience=E2=80=A6

 I was very happy when on a project for a new internal proprietary=20
 JSF based framework, we were allowed to have Groovy as part of=20
 the framework's supported languages.
=20
 That only happened because the said company was replacing the=20
 Perl scripts by Groovy scripts in their deployment infrastructure.

Perl is a fine language in many ways and not so fine in others. It seems
though that it is increasingly seen as legacy in the way COBOL is.=20

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

"Paulo Pinto" <pjmlp progtools.org> writes:

On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
 […]
 The problem is that in the enterprise world with expendable 
 programmers, is very hard to do JVM based projects with 
 anything other than Java.

 My experience from various training courses I have given is 
 that in the
 large corporate Web applications world, the average programmer 
 knows
 Java, just enough Java, and isn't that interested in anything 
 else.
 Gross oversimplification but a good indicator.

That is actually the case.

"Era Scarecrow" <rtcvb32 yahoo.com> writes:

On Monday, 30 July 2012 at 07:26:51 UTC, Paulo Pinto wrote:
 On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
 The problem is that in the enterprise world with expendable 
 programmers, is very hard to do JVM based projects with 
 anything other than Java.

 My experience from various training courses I have given is 
 that in the large corporate Web applications world, the 
 average programmer knows Java, just enough Java, and isn't 
 that interested in anything else. Gross oversimplification but 
 a good indicator.

 That is actually the case.

  The only thing I walked away with after I learned java as part 
of a programming course, was how polymorphism and interfaces 
worked in OO programming.

  I just really wish they would change their courses for 'this is 
inheritance with animals!' which although logically makes sense 
(in a dictionary wikipedia way) but structurally and 
programming-wise doesn't. Describing it as a building block for a 
game (like item) would have made much more sense.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Monday, 30 July 2012 at 07:57:47 UTC, Era Scarecrow wrote:
 On Monday, 30 July 2012 at 07:26:51 UTC, Paulo Pinto wrote:
 On Monday, 30 July 2012 at 06:04:31 UTC, Russel Winder wrote:
 On Sun, 2012-07-29 at 21:35 +0200, Paulo Pinto wrote:
 The problem is that in the enterprise world with expendable 
 programmers, is very hard to do JVM based projects with 
 anything other than Java.

 My experience from various training courses I have given is 
 that in the large corporate Web applications world, the 
 average programmer knows Java, just enough Java, and isn't 
 that interested in anything else. Gross oversimplification 
 but a good indicator.

 That is actually the case.

  The only thing I walked away with after I learned java as part 
 of a programming course, was how polymorphism and interfaces 
 worked in OO programming.

  I just really wish they would change their courses for 'this 
 is inheritance with animals!' which although logically makes 
 sense (in a dictionary wikipedia way) but structurally and 
 programming-wise doesn't. Describing it as a building block for 
 a game (like item) would have made much more sense.

It always depends how lucky you get with who teaches you. I 
learned OO with
Turbo Pascal 6.0, as I prepared a class about OO in high school.

Afterwards it was time to learn with OO the C++ way.

Before Java I was exposed to OO in Smalltalk, CLOS, Eiffel, 
Modula-3, Oberon,
Python.

Not only the languages, but OO abstract design in the form of 
Boochs and UML methods.

So when I came to lean Java, many things felt natural, and I was 
not contaminated like many, with the idea that OOP == Java.

--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 30 Jul 2012 07:04:21 +0100
Russel Winder <russel winder.org.uk> wrote:
 My experience from various training courses I have given is that in
 the large corporate Web applications world, the average programmer
 knows Java, just enough Java, and isn't that interested in anything
 else. Gross oversimplification but a good indicator.

Ugh, such "programmers" don't deserve a paycheck. It's like hiring
someone who never learned arithmetic as an accountant. Makes no
fucking sense at all - they just simply *can't* do their fucking trade,
period. The "programmer" and the hiring manager should both be fired
and pointed to nearest (possibly hiring) fast food joint.

(Incarceration for "impersonating a programmer" would perhaps be more
appropriate ;) )

"Paulo Pinto" <pjmlp progtools.org> writes:

On Monday, 30 July 2012 at 19:31:51 UTC, Nick Sabalausky wrote:
 On Mon, 30 Jul 2012 07:04:21 +0100
 Russel Winder <russel winder.org.uk> wrote:
 My experience from various training courses I have given is 
 that in
 the large corporate Web applications world, the average 
 programmer
 knows Java, just enough Java, and isn't that interested in 
 anything
 else. Gross oversimplification but a good indicator.

 Ugh, such "programmers" don't deserve a paycheck. It's like 
 hiring
 someone who never learned arithmetic as an accountant. Makes no
 fucking sense at all - they just simply *can't* do their 
 fucking trade,
 period. The "programmer" and the hiring manager should both be 
 fired
 and pointed to nearest (possibly hiring) fast food joint.

 (Incarceration for "impersonating a programmer" would perhaps 
 be more
 appropriate ;) )

Sadly this is how many well known consulting companies with a big 
client portfolio of Fortune 500 companies work. I happen to work 
in one of them, you would be amazed what managers and clients 
look for as developers.

As a guy I know says, pay for a FIAT while expecting to get a 
Ferrari in the end.

--
Paulo

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Mon, 30 Jul 2012 22:22:22 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:

 On Monday, 30 July 2012 at 19:31:51 UTC, Nick Sabalausky wrote:
 On Mon, 30 Jul 2012 07:04:21 +0100
 Russel Winder <russel winder.org.uk> wrote:
 My experience from various training courses I have given is 
 that in
 the large corporate Web applications world, the average 
 programmer
 knows Java, just enough Java, and isn't that interested in 
 anything
 else. Gross oversimplification but a good indicator.

 Ugh, such "programmers" don't deserve a paycheck. It's like 
 hiring
 someone who never learned arithmetic as an accountant. Makes no
 fucking sense at all - they just simply *can't* do their 
 fucking trade,
 period. The "programmer" and the hiring manager should both be 
 fired
 and pointed to nearest (possibly hiring) fast food joint.

 (Incarceration for "impersonating a programmer" would perhaps 
 be more
 appropriate ;) )

 
 Sadly this is how many well known consulting companies with a big 
 client portfolio of Fortune 500 companies work.
 

It's no surprise then as to why, outside of management circles,
consulting companies have gained a reputation for not knowing what
they're doing.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sun, 29 Jul 2012 13:14:06 +0200
"Paulo Pinto" <pjmlp progtools.org> wrote:
 

 to criticise as being a cheap Java clone back in 2001. How things 
 change.
 

Ever since I first tried it out, many years ago, I've been convinced

Still think so.

It used to actually be tied with D as my favorite language, but

have, while I grew to like D more and more.

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/29/12 4:34 AM, Russel Winder wrote:
 Primitive types are now effectively deprecated in Java, and this is
 likely a deprecation which will actually lead to a removal – unlike
 everything else in Java that has been deprecated which is still there.

That's interesting. Do you have references to some related resources?

Thanks,

Andrei

Russel Winder <russel winder.org.uk> writes:

On Sun, 2012-07-29 at 09:31 -0400, Andrei Alexandrescu wrote:
 On 7/29/12 4:34 AM, Russel Winder wrote:
 Primitive types are now effectively deprecated in Java, and this is
 likely a deprecation which will actually lead to a removal =E2=80=93 un=


like
 everything else in Java that has been deprecated which is still there.

=20
 That's interesting. Do you have references to some related resources?
=20
 Thanks,

It's on the Java road map for Java 10. I can't immediately find the
actual road map, but you will find lots of people blogging about the
fact which has been "announced" at most of the main Java conferences.
e.g. http://java.dzone.com/articles/oracle-discusses-features-java

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Russel Winder <russel winder.org.uk> writes:

On Sat, 2012-07-28 at 22:40 -0400, Nick Sabalausky wrote:
[=E2=80=A6]
 allocation. Even natively-compiled, that doesn't sound like my idea of a
 good embedded language. But I dunno, I guess maybe if they're
 using it in the sort of way that game devs use Lua...(Not that I'm a fan
 of Lua - far too dynamic for my tastes.)

The benefit of using Java in an embedded context is exactly to avoid
native code. The use of a language that has no access to physical memory
makes operating system level security management significantly easier.

For example on smart cards =E2=80=93 which has to be one of the most constr=
ained
multi-application platforms out there =E2=80=93 the lengths processor
manufacturers have to go to support management of native code
applications is awful compared to those who support only Java Card. Yes
I know Java Card is not Java in any meaningful way, shape or form, but
it is an bytecode virtual machine based system.

The use of dynamic languages in systems such as games, post-production,
image manipulation has many similarities in terms of security
management, but is there for a wholly different purpose: the C and/or C
++ code does all the real computational work.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Walter Bright <newshound2 digitalmars.com> writes:

On 7/27/2012 7:38 PM, Jonathan M Davis wrote:
 True, but I'm kind of shocked that anything 16-bit even still exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago. I guess that
 some embedded stuff must use it. But really, I wouldn't expect the lack of 16-
 bit support to be much of an impediment - if any at all - and in the long run,
 it'll mean absolutely nothing.

For those who may not realize it, C++ is simply not suitable for 16 bit systems 
either. It theoretically supports 16 bit code, but in practice, full C++ will 
never work on them.

So, you might ask, why was 16 bit C++ popular on 16 bit MSDOS in the 80's? That 
was C++ before exception handling and RTTI, both of which were unimplementable 
on 16 bit machines. (Yes, you could do it, but the result was practically
unusable.)

C and 16 bits go reasonably well together, but even so, the best programs were 
written all in asm.

"Paulo Pinto" <pjmlp progtools.org> writes:

On Sunday, 29 July 2012 at 22:22:33 UTC, Walter Bright wrote:
 On 7/27/2012 7:38 PM, Jonathan M Davis wrote:
 True, but I'm kind of shocked that anything 16-bit even still 
 exists. _32-bit_
 is on its way out. I thought that 16-bit was dead _years_ ago. 
 I guess that
 some embedded stuff must use it. But really, I wouldn't expect 
 the lack of 16-
 bit support to be much of an impediment - if any at all - and 
 in the long run,
 it'll mean absolutely nothing.

 For those who may not realize it, C++ is simply not suitable 
 for 16 bit systems either. It theoretically supports 16 bit 
 code, but in practice, full C++ will never work on them.

 So, you might ask, why was 16 bit C++ popular on 16 bit MSDOS 
 in the 80's? That was C++ before exception handling and RTTI, 
 both of which were unimplementable on 16 bit machines. (Yes, 
 you could do it, but the result was practically unusable.)

I remember using both features with Borland compilers.

But then I was around 16 years old and was not doing anything 
serious
with C++, besides getting to know the language.

On those days, Turbo Pascal was my number one choice for serious 
software.

 C and 16 bits go reasonably well together, but even so, the 
 best programs were written all in asm.

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen 
wrote:
 In all fairness, I think C still has its place. The advantage 
 of writing software in C is that when you want to port it to a 
 new platform/architecture, there will almost always be a C 
 compiler available. This isn't the case for D yet - but 
 hopefully will be in the future. But note, even then, that D 
 only targets 32-bit architectures and up, while C can handle 
 16-bit architectures.

Ah. So, in essence, C has a purpose because [a] it supports 
incredibly obsolete hardware that nobody in their right mind 
would be using; and [b] nobody's ported D to MacOS (or whatever) 
yet.

Not a particularly good argument, to my mind ;)

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 28 Jul 2012 09:52:36 +0200
"Stuart" <stugol gmx.com> wrote:

 On Saturday, 28 July 2012 at 02:31:42 UTC, Alex R=F8nne Petersen=20
 wrote:
 In all fairness, I think C still has its place. The advantage=20
 of writing software in C is that when you want to port it to a=20
 new platform/architecture, there will almost always be a C=20
 compiler available. This isn't the case for D yet - but=20
 hopefully will be in the future. But note, even then, that D=20
 only targets 32-bit architectures and up, while C can handle=20
 16-bit architectures.

=20
 Ah. So, in essence, C has a purpose because [a] it supports=20
 incredibly obsolete hardware that nobody in their right mind=20
 would be using;

That's just plain hyperbole.

Jacob Carlborg <doob me.com> writes:

On 2012-07-28 09:52, Stuart wrote:

 Ah. So, in essence, C has a purpose because [a] it supports incredibly
 obsolete hardware that nobody in their right mind would be using; and
 [b] nobody's ported D to MacOS (or whatever) yet.

If you refer to Mac OS X, I use D on it every day. If you're actually 
referring to MacOS then who cares, it's a dead operating system and has 
been for at least ten years.

-- 
/Jacob Carlborg

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 11:43:14 UTC, Jacob Carlborg wrote:
 On 2012-07-28 09:52, Stuart wrote:

 Ah. So, in essence, C has a purpose because [a] it supports 
 incredibly
 obsolete hardware that nobody in their right mind would be 
 using; and
 [b] nobody's ported D to MacOS (or whatever) yet.

 If you refer to Mac OS X, I use D on it every day. If you're 
 actually referring to MacOS then who cares, it's a dead 
 operating system and has been for at least ten years.

Which only reinforces my point that C is redundant.

=?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:

On 28-07-2012 14:41, Stuart wrote:
 On Saturday, 28 July 2012 at 11:43:14 UTC, Jacob Carlborg wrote:
 On 2012-07-28 09:52, Stuart wrote:

 Ah. So, in essence, C has a purpose because [a] it supports incredibly
 obsolete hardware that nobody in their right mind would be using; and
 [b] nobody's ported D to MacOS (or whatever) yet.

 If you refer to Mac OS X, I use D on it every day. If you're actually
 referring to MacOS then who cares, it's a dead operating system and
 has been for at least ten years.

 Which only reinforces my point that C is redundant.

See Paulo's post.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 07:52:37 UTC, Stuart wrote:
 On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen 
 wrote:
 In all fairness, I think C still has its place. The advantage 
 of writing software in C is that when you want to port it to a 
 new platform/architecture, there will almost always be a C 
 compiler available. This isn't the case for D yet - but 
 hopefully will be in the future. But note, even then, that D 
 only targets 32-bit architectures and up, while C can handle 
 16-bit architectures.

 Ah. So, in essence, C has a purpose because [a] it supports 
 incredibly obsolete hardware that nobody in their right mind 
 would be using;

Yep, who would want to use one of the many 8 and 16 bit processors
used to make work all the embedded systems in microwaves, fridges,
on bord car computers, cameras, watches, calculators, elevators,
vcr/dvd systems ...


--
Paulo

"Paulo Pinto" <pjmlp progtools.org> writes:

On Saturday, 28 July 2012 at 02:31:42 UTC, Alex Rønne Petersen 
wrote:
 On 27-07-2012 20:50, Stuart wrote:
 On Friday, 27 July 2012 at 15:27:58 UTC, Alex Rønne Petersen 
 wrote:
 On 27-07-2012 14:56, Stuart wrote:

 In any case, isn't it the job of the compiler to unroll 
 loops? Why
 should the coder have to do this himself? Unless of course 
 he's using a
 thin shitty wrapper over assembly language that claims 
 falsely to be a
 high-level language - i.e. C.

 It was a high-level language at the time it was created.

 Quite possibly. But the definition of "high level" has since 
 changed,
 and C no longer qualifies. Yet proponents of C/C++ continue to 
 froth at
 the mouth and claim it's a decent language.

 Why is D so awesome? Because it's not C.

 In all fairness, I think C still has its place. The advantage 
 of writing software in C is that when you want to port it to a 
 new platform/architecture, there will almost always be a C 
 compiler available.

Actually there is always the option of cross-compiling, but it is
usually more work than just use the platform tools directly.

"Kagamin" <spam here.lot> writes:

On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
 It's a useful construct when used
 properly. It just shouldn't be used when there are better 
 alternatives.

Hmm... do you have a use case besides Duff's device and porting 
legacy code?

Jonathan M Davis <jmdavisProg gmx.com> writes:

On Friday, July 27, 2012 16:05:07 Kagamin wrote:
 On Friday, 27 July 2012 at 01:45:35 UTC, Jonathan M Davis wrote:
 It's a useful construct when used
 properly. It just shouldn't be used when there are better
 alternatives.

 
 Hmm... do you have a use case besides Duff's device and porting
 legacy code?

There's quite a bit of code out there which uses it to jump to a common set of 
error handling code, which can actually make functions cleaner in some cases. 
Phobos even does this a few places (though not many).

Also, as I understand it, there are cases in low level code (where you need 
every cycle that you can get) that using a goto to get out of a section of 
code can be more efficient than getting out of it in the ways that you would 
more typically do. I haven't personally run into that sort of thing though, 
since I don't generally write code that low level.

And just because you or I don't use it much, doesn't mean that people 
programming in other domains don't need it for use cases that we never run 
into. goto is just one of those things that a systems language is bound to 
have.

- Jonathan M Davis

"bearophile" <bearophileHUGS lycos.com> writes:

Kagamin:

 Hmm... do you have a use case besides Duff's device and porting 
 legacy code?

To implement certain quick finite state machines, it's a quite 
important use case for me. At the moment I am even using computed 
gotos in GCC-C, for similar purposes.

Bye,
bearophile

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Fri, 27 Jul 2012 16:05:07 +0200, Kagamin <spam here.lot> wrote:

 Hmm... do you have a use case besides Duff's device and porting legacy  
 code?

I've used it once, when the other option was a pyramid of 15 if statements.
Not saying it couldn't be done without, obviously, but it was clearly the
better option.

-- 
Simen

Philippe Sigaud <philippe.sigaud gmail.com> writes:

"bearophile" <bearophileHUGS lycos.com>
 Gotos are not so evil. Just use them when they are useful and they can't

be replaced by structured programming. In D I create finite state machines
at compile-time that use gotos, they are quick.

Do you happen to still have the code, by any chance? I think Phobos could
use a std.fsm, to automatically generate FSM at compile-time  (using lots
of gotos :) ).

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 7/28/12 10:13 AM, Philippe Sigaud wrote:
 "bearophile" <bearophileHUGS lycos.com <mailto:bearophileHUGS lycos.com>>
  > Gotos are not so evil. Just use them when they are useful and they
 can't be replaced by structured programming. In D I create finite state
 machines at compile-time that use gotos, they are quick.

 Do you happen to still have the code, by any chance? I think Phobos
 could use a std.fsm, to automatically generate FSM at compile-time
 (using lots of gotos :) ).

I've always found it difficult to generate FSMs from textual specs (as 
opposed to regexen or pretty images). Problem is you need to name your 
states, and in many FSMs intermediate states are not meaningful.

Andrei

"Kagamin" <spam here.lot> writes:

On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
 Stuart:

 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

 Gotos are not so evil. Just use them when they are useful and 
 they can't be replaced by structured programming. In D I create 
 finite state machines at compile-time that use gotos, they are 
 quick.

Do FSMs really need to be spaghetti monsters? I heard, gcc 
optimizer can tear functions into common pieces and them 
reassemble the functions back from these pieces, or simply inline 
them, won't you get the same result?

"Tobias Pankrath" <tobias pankrath.net> writes:

On Saturday, 28 July 2012 at 16:55:32 UTC, Kagamin wrote:
 On Friday, 27 July 2012 at 00:57:15 UTC, bearophile wrote:
 Stuart:

 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

 Gotos are not so evil. Just use them when they are useful and 
 they can't be replaced by structured programming. In D I 
 create finite state machines at compile-time that use gotos, 
 they are quick.

 Do FSMs really need to be spaghetti monsters? I heard, gcc 
 optimizer can tear functions into common pieces and them 
 reassemble the functions back from these pieces, or simply 
 inline them, won't you get the same result?

State machines encoded with goto tend not to be more spaghetti 
than their
specifications (say in regex or graph picture

"bearophile" <bearophileHUGS lycos.com> writes:

Philippe Sigaud:

 Do you happen to still have the code, by any chance? I think 
 Phobos
 could use a std.fsm

The code is not general enough for Phobos.


Kagamin:

 I heard, gcc optimizer can tear functions into common pieces 
 and them reassemble the functions back from these pieces, or 
 simply inline them, won't you get the same result?

Sometimes those FSM are the only part of those small C or D 
programs where I don't trust the optimizers. But thankfully in 
C-GCC using a little of __builtin_expect() it's not necessary to 
generate the assembly directly from the FSM description.

Bye,
beaophile

"F i L" <witte2008 gmail.com> writes:

Stuart wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade, 
 because it's truly evil.

There are some who use it, and I imagine it's in there for their 
benefit. Thought I agree, I've rarely ever used goto.


 I have a couple of questions though. Why does the VisualD 
 plugin crash Visual Studio if I double-click a .sln file in 
 Windows Explorer? I mean, every single time? I'm using VS2010 
 on Windows 7 64-bit; and the problem only happens with D 
 projects, and only when loading an .sln file by association. If 
 I load VS and use the menu to open the solution, it works fine.

I know many are attached at the hip to Visual Studios, but I 
recommend MonoDevelop + Mono-D plugin for D programming. It's 
very nice, with the exception of a few bug, it offers is 

platform, if/when you take your projects to other platforms it 
helps a lot to use a consistent tool.


 One thing I really think D ought to have is iterators, like 

 chance of them being implemented? The implementation of .NET 
 iterators is well-known and fairly straightforward; all we need 
 is compiler support.

Ranges are a very good alternative. However there's also 
D-Collections (http://www.dsource.org/projects/dcollections/) 
which supports a "Cursor" type, similar to iterators (to my 
knowledge).

The biggest issue with D's collections IMO, are std.container's 
lack of useful structures. For instance there's no standard 
Doubly-Linked-List type. However, I understand that Andrei is 
currently working on a new allocation system, which should pave 
the way to a new standard collection lib.

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 01:25:45 UTC, F i L wrote:
 I know many are attached at the hip to Visual Studios, but I 
 recommend MonoDevelop + Mono-D plugin for D programming. It's 
 very nice, with the exception of a few bug, it offers is 

 platform, if/when you take your projects to other platforms it 
 helps a lot to use a consistent tool.

I've had a lot of bad experience with other IDEs. Eclipse, for 
example, and D-IDE. I don't know about you guys, but I couldn't 
get either of those environments to even compile my code, let 
alone provide any kind of intellisense or debugging facilities. 
Maybe I'm doing it wrong, I dunno. Is MonoDevelop good? Does it 
do intellisense? Does it have a decent debugger?

Incidentally, none of that answered my original question, which 
is "why does VisualD crash?"

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?

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 04:05:48 +0200
"Stuart" <stugol gmx.com> wrote:
 
 Incidentally, none of that answered my original question, which 
 is "why does VisualD crash?"
 

You should probably ask over at wherever VisualD's site is. I don't
personally use big IDEs much (I use Programmer's Notepad 2 for my D
work) and in fact many of us here (though certainly not all) actually
just use relatively plain highlighting text editors and the command
line. So it'll probably be better to just ask the VisualD people
directly.

Rainer Schuetze <r.sagitario gmx.de> writes:

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

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 12:56:12 UTC, Rainer Schuetze 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

Yes, removing the .suo file fixed the problem. I don't know why. 
I will create a ticket. Would submitting my .suo file help?

 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.

Well, it doesn't work in a lot of cases. A lot of times I'll 
press . or ( and get nothing at all.

Rainer Schuetze <r.sagitario gmx.de> writes:

On 27.07.2012 15:20, Stuart wrote:
 On Friday, 27 July 2012 at 12:56:12 UTC, Rainer Schuetze 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

 Yes, removing the .suo file fixed the problem. I don't know why. I will
 create a ticket. Would submitting my .suo file help?

Yes, please do. Even though it is system specific, maybe I can find some 
information.

 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.

 Well, it doesn't work in a lot of cases. A lot of times I'll press . or
 ( and get nothing at all.

Do you have semantic analysis enabled in the intellisense options? That 
is needed for '.' producing sensible results. In contrast '(' uses the 
compiler generated browse information. I guess that should be 
consolidated...

"Stuart" <stugol gmx.com> writes:

On Saturday, 28 July 2012 at 07:58:23 UTC, Rainer Schuetze wrote:
 On 27.07.2012 15:20, Stuart wrote:
 Yes, removing the .suo file fixed the problem. I don't know 
 why. I will create a ticket. Would submitting my .suo file 
 help?

 Yes, please do. Even though it is system specific, maybe I can 
 find some information.

Done.

 Well, it doesn't work in a lot of cases. A lot of times I'll 
 press . or ( and get nothing at all.

 Do you have semantic analysis enabled in the intellisense 
 options? That is needed for '.' producing sensible results. In 
 contrast '(' uses the compiler generated browse information. I 
 guess that should be consolidated...

I didn't, but I do now. The status bar now says "blah blah 
blah\gl.d: parsing" and has done for several minutes. Pressing . 
after a variable of type WNDCLASS has no effect. Pressing ( has 
no effect either.

Pressing . elsewhere sometimes shows intellisense. It all depends 
on what is before the .

Pressing ( does nothing unless the function I am calling is 
located within the same source file.

This is what I meant by "hit and miss". Also "blows" ;)

Walter Bright <newshound2 digitalmars.com> writes:

On 7/26/2012 4:59 PM, Stuart wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade, because it's truly
 evil.

The road to hell is paved with good intentions, so we felt it necessary to add
a 
touch of eeeevil.


 One thing I really think D ought to have is iterators,

We call them "ranges" in D. :-) I think you'll like them.

Stefan Scholl <stesch no-spoon.de> writes:

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.

Marco Leise <Marco.Leise gmx.de> writes:

Am Fri, 27 Jul 2012 07:22:49 +0000 (UTC)
schrieb Stefan Scholl <stesch no-spoon.de>:

 Stuart <stugol gmx.com> wrote:
 Why does D have GOTO? I haven't used GOTO in over a decade,=20
 because it's truly evil.

=20
 Dogmas are evil.

+1
I clicked through a few responses, and this one I liked most.
It feels like GOTO was stigmatized during the days when if/for/while appear=
ed to replace its omni presence. Back than it was ok to shout and scream ab=
out every use, but today it is more likely that people who use goto, know w=
hat they are doing.

I use it in switch-case for "preprocessing", where there may be 3 cases tha=
t all end at case 3:, but case 1 and 2 need something done first. Now you c=
an just goto case 3 at the end of 1 & 2.
Also when I have a sequence of steps to be done and some steps may jump bac=
k a few steps, I prefer labels with good names + goto, over blocks of for/w=
hile/if, which distract from the sequential nature of the code.

It's funny how I felt a bit offended by "Why does D have GOTO? [=E2=80=A6] =
it's truly evil." :D

--=20
Marco

"Kagamin" <spam here.lot> writes:

On Friday, 27 July 2012 at 14:03:05 UTC, Marco Leise wrote:
 Also when I have a sequence of steps to be done and some steps 
 may jump back a few steps, I prefer labels with good names + 
 goto, over blocks of for/while/if, which distract from the 
 sequential nature of the code.

Huh, but such code is not sequential, it's spaghetti.

"Regan Heath" <regan netmail.co.nz> writes:

On Fri, 27 Jul 2012 15:09:14 +0100, Kagamin <spam here.lot> wrote:

 On Friday, 27 July 2012 at 14:03:05 UTC, Marco Leise wrote:
 Also when I have a sequence of steps to be done and some steps may jump  
 back a few steps, I prefer labels with good names + goto, over blocks  
 of for/while/if, which distract from the sequential nature of the code.

 Huh, but such code is not sequential, it's spaghetti.

Spaghetti goes in many directions, the code above always flows downhill  
but sometimes jumps/loops back up.  As long as the jumps are in one  
direction and not both, it's typically easy enough to follow.

IMO, goto is a tool like any other, in the wrong hands it can make bad  
code, in the right hands, used sparingly and only when it makes code  
easier to follow it's the right tool and avoiding it due to dogma is just  
plain silly.

My main use in the past has been to jump to clean up code, which is not  
always necessary with D as we have finally and scope(exit).

If I have the choice between a loop construct which only ever executes  
once with 'break' to simulate goto vs using goto, I will chose the latter  
because it's clearer what the intent of the code is, it actually makes the  
code cleaner and easier to follow.

I tend to code in the style of check for error and fail/return/exit vs  
layered scopes (if inside if inside if ..) because the flatter the code  
the easier I find it to reason about code paths and logic, goto can help  
to keep a piece of code flat and make it easier to reason about.

I almost always use goto to jump down a function, and almost never up.   
Loop constructs are with 'continue' are a better match for the latter.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

"Christof Schardt" <christof schardt.info> writes:

"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

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Thursday, 26 July 2012 at 23:59:13 UTC, Stuart wrote:

 How good is the Entice Designer? I'd like to write some GUI 
 apps in D, but I need to know that the designer won't fall over 
 halfway through; and I'll be damned if I'm writing my GUI code 
 by hand. Even MFC programmers have a "dialog designer".

Entice is pretty good, but I can't comment much on its capability 
as I've only used it to get me some code started for writing a 
gui. And while it is no where near VS, I don't really like the VS 
designer so I guess you can take my opinion of GUI designers with 
an atom of salt.

Entice also hasn't gotten a much/any updates for D2 code 
generation, so it is likely to fall down at some point.

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Fri, 27 Jul 2012 17:52:27 +0200
"Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with 
 an atom of salt.

<annoyingly pedantic>It would have to be a molecule. Try to take an
atom of salt and you'll either get a poisonous gas, or
something that goes boom in contact with water.</annoyingly
pedantic>

Chemistry is really weird...

"bearophile" <bearophileHUGS lycos.com> writes:

Nick Sabalausky:

 Chemistry is really weird...

Yep, and that's one of the things it makes is fascinating:
http://en.wikipedia.org/wiki/Ionic_bond

And of course chemistry runs animal bodies like ours :-)

Bye,
bearophile

"Stuart" <stugol gmx.com> writes:

On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with an 
 atom of salt.

 <annoyingly pedantic>It would have to be a molecule. Try to 
 take an
 atom of salt and you'll either get a poisonous gas, or
 something that goes boom in contact with water.</annoyingly
 pedantic>

You know, I do believe he's right.

"Jesse Phillips" <Jessekphillips+D gmail.com> writes:

On Friday, 27 July 2012 at 20:42:40 UTC, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with an 
 atom of salt.

 <annoyingly pedantic>It would have to be a molecule. Try to 
 take an
 atom of salt and you'll either get a poisonous gas, or
 something that goes boom in contact with water.</annoyingly
 pedantic>

 Chemistry is really weird...

I realized the whole molecule thing but through laziness it was 
on purpose. Besides, as you have described here it fits nicely, 
my opinion could potentially explode with contact to water.

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 28-Jul-12 00:42, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with
 an atom of salt.

 <annoyingly pedantic>It would have to be a molecule. Try to take an
 atom of salt and you'll either get a poisonous gas, or
 something that goes boom in contact with water.</annoyingly
 pedantic>

Well Na isn't much of boom. K will do much better :)

 Chemistry is really weird...

...though Physics is no less so once you are past the Newton mechanics.

-- 
Dmitry Olshansky

Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:

On Sat, 28 Jul 2012 02:42:36 +0400
Dmitry Olshansky <dmitry.olsh gmail.com> wrote:

 On 28-Jul-12 00:42, Nick Sabalausky wrote:
 On Fri, 27 Jul 2012 17:52:27 +0200
 "Jesse Phillips" <Jessekphillips+D gmail.com> wrote:

 so I guess you can take my opinion of GUI designers with
 an atom of salt.

 <annoyingly pedantic>It would have to be a molecule. Try to take an
 atom of salt and you'll either get a poisonous gas, or
 something that goes boom in contact with water.</annoyingly
 pedantic>

 
 Well Na isn't much of boom. K will do much better :)
 
 Chemistry is really weird...

 
 ...though Physics is no less so once you are past the Newton
 mechanics.
 

That's kind of another weird thing, but just with the terminology:

Really, really big: Astro*physics*
Medium: Newtonian *physics*
Small: *Chemistry*
Really, really small: Quantum...*physics*?!?

:)

(Yea, a gross oversimplification, I'm sure, but still ;) )