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
> - F#
> - 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 for F#. The possibility of "some" C compilers supporting 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?

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.

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.

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
>> - F#
>> - 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
> for F#. The possibility of "some" C compilers supporting it doesn't mean
> 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

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.

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

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.

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

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
>>> - F#
>>> - 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
>> for F#. The possibility of "some" C compilers supporting it 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 optimisation), and F#, none of these languages would seem to 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.
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?