July 28, 2012
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


July 28, 2012
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?
July 28, 2012
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:
>>>>
>>>> I tend to favour F# instead of OCaml due to three things
>>>
>>> I've never really seen the point of F#. Aside from maths, what is F#
>>> 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
>> - Type providers (comming in F# 3.0) to manipulate remote data 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
>>
>> Microsoft wouldn't have brought F# into Visual Studio if it 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 F# pretty cool (just not all that original as a language).
>
> Andrei

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

July 28, 2012
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


July 28, 2012
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
July 28, 2012
> 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 C# at Lang.NEXT that 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.

> "yield" adds real, nontrivial value, and is not entirely implementable as a library. Walter and I saw some uses of it in C# at Lang.NEXT that were quite impressive.

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 C# 2's "yield return" but as far as I can tell, it can also do everything that C# 5's "async/await" can do and more:

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.
July 28, 2012
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)
July 29, 2012
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


July 29, 2012
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.)

July 29, 2012
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.