On Wed, 2016-09-07 at 20:32 +1200, rikki cattermole via Digitalmars-d- learn wrote:
> 
[…]
> Ok, I have it mostly compiling.
> 
> void run_mean() {}
> void run_mode() {}
> void run_stdDev() {}

For my code the functions have to be declared within the main function rather than being at module level. But this turns out to be a non- issue.

> void main() {
> 	import std.datetime;
> 	import std.algorithm : map;
> 	import std.conv;
> 	import std.array;

I am still not a fan of this import all symbols approach, like the map import, I would do the same for the other modules' functions used.

> 	const results = benchmark!(run_mean, run_mode, run_stdDev)(1);
> 	const times = map!((TickDuration t) { return
> (to!Duration(t)).total!"seconds"; })(results[]);

It turns out my problem was here. See below.

> 	import std.stdio;
> 	foreach(v; times) {
> 		writeln(v);
> 	}
> }
> 
> However times really can't be const. Since times is an input range
> which
> gets modified as part of the iterations.

Indeed. I keep forgetting that ranges are use once mutable entities, and there is no option. s/const/auto/ solves the problem, but the more likely general solution is to retain the const and reify the array. But it depends on usage, obviously.

> So what exactly do you want times to be? If you want an array .array
> from std.algorithm it which can be const. Either way there is
> something
> I'm missing as to why const is so important here.

In this case it isn't as you can't use a constant range. The problem I am having is when I cannot use const or better immutable. I'm a single assignment sort of person, but D ranges break all that orthodoxy.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

On Wed, 2016-09-07 at 09:03 +0000, ketmar via Digitalmars-d-learn wrote:
> […]
> 
> alas, no jokes here. within the current D sytnax there is simply no way to make that error less cryptic. :-(

Well that will be the end of any traction for D then. C++, Java, Groovy, etc. error messages prove that error reporting is something you get right or you have no users that are not working under Stockholm Syndrome.

> even pointing at the failed constraint is fairly hard with current DMDFE code (that's why nobody did it yet), and show custom error for that is nearly impossible. we can't write "catch all" template with static assert, 'cause it catches everything, which is not desirable.
> 
> i myself didn't found even acceptable solution for this mess. sure, at least pointing to failed constraint is something we should have, but in your case it is of little help, actually.
> 
> probably adding `map` overload which accepts static arrays and does `static assert(0, "please use slice for static arrays");` may help in this case.

I think bearophile suggested adding amap many moons ago.

I suspect this will never happen due to array(map(…)) which is fine.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

On Wed, 2016-09-07 at 09:04 +0000, Lodovico Giaretta via Digitalmars-d- learn wrote:
> 
[…]
> You have your const fixed-length array. You slice it and you obtain a const range to feed map. Now map will not return you an array. Because most of the time you don't need it. It will return you a range that lazily computes its elements on demand. No memory allocation at all. You can do a foreach on that range. If you need to access those elements more than once, instead of recomputing each of them every time it is accessed, you can store the results of the map. You simply have to use .array on the map result. This will allocate memory and give you an array with your results. Otherwise, no allocation at all. That result array can be const, if you want. If you need to access your elements only once, there's no need to have an array.

The problem for me had been that ranges are mutable or useless since they are single use destructive things. So yes trying to add immutable or const to it is breaking the range model.

The real problem though is the terrifying error message. I am having a hard time finding a way of pitching them to Pythonistas.


> I really don't see what's not working in this.

Trying to get new D users from Python users is the main problem.

> And by the way, there's no need to put const on everything. An optimizing compiler is often able to infer things, especially for stack allocated local variables.

I'd prefer immutable, but const sometimes has to do. The idea is to find out how to enforce single assignment in D.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 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

On Wednesday, 7 September 2016 at 11:33:08 UTC, Russel Winder wrote:
> C++, error messages

sorry, i loled hard.

On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote:
> I'd prefer immutable, but const sometimes has to do. The idea is to find out how to enforce single assignment in D.

Everything depends on what you mean by "single assignment".

If you mean "I can't use opAssign", then const is definitely too strong. In this case, you can write a simple type wrapper that disables opAssign, while providing all other functionalities.

If you mean "Methods do not mutate objects; instead, they return new objects, mutated", the issue is deeper. In fact, input ranges and output ranges cannot (by definition) fulfill this requirement. Other ranges (forward, bidirectional, random) can fulfill this requirement, but it's very expensive, as it requires a new copy of every range every time you want to popFront or popBack. The same goes for every other type with mutable methods. If you really want this behaviour, you can easily write (again) a type wrapper that forwards every const method call while intercepting every mutable method call and applying it to a new copy that is returned. But I think it will severely hurt performance and readability.

On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote:
>
>> I really don't see what's not working in this.
>
> Trying to get new D users from Python users is the main problem.
>

I came to D from Python/R/Matlab. The biggest issue for me wasn't error messages so much as the lack of good libraries for a lot of things.

Nevertheless, the longer I've been using D, the more I agree that there could be some improvements in D's error messages. Andre had posted about the Sparrow language a while back
https://forum.dlang.org/thread/ne3265$uef$1@digitalmars.com?page=1
He liked their use of concepts. I think at a minimum it would enable better error messages.

On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder wrote:
> The real problem though is the terrifying error message. I am having a hard time finding a way of pitching them to Pythonistas.

Do they use single assignment a lot?

On Tuesday, 6 September 2016 at 14:38:54 UTC, Russel Winder wrote:
> and I have no idea just now why it is complaining, nor what to do to fix it.

You might want to check out the ranges package of the library I'm working on.

https://github.com/pineapplemachine/mach.d/tree/master/mach/range

This topic motivated me to see if my map function worked with static arrays. Turns out that somehow I'd neglected to include a unit test, and it in fact failed.

Once I've had a chance to commit the couple-line fix, probably in a couple hours, this will be a valid program:

    import mach.range : map;
    import std.stdio : writeln;

    void main(){
        const(const(int)[3]) array = [1, 2, 3];
        auto mapped = array.map!(e => e + 1);
        mapped.front.writeln; // 2
        mapped[0].writeln; // 2
        // etc.
    }

On Wednesday, 7 September 2016 at 18:10:45 UTC, pineapple wrote:
>
> You might want to check out the ranges package of the library I'm working on.
>
> https://github.com/pineapplemachine/mach.d/tree/master/mach/range
>

There's a lot of stuff there. Do you mind giving a TL;DR version of what your range library does differently than phobos?

On Wednesday, 7 September 2016 at 18:22:39 UTC, jmh530 wrote:
> On Wednesday, 7 September 2016 at 18:10:45 UTC, pineapple wrote:
>>
>> You might want to check out the ranges package of the library I'm working on.
>>
>> https://github.com/pineapplemachine/mach.d/tree/master/mach/range
>>
>
> There's a lot of stuff there. Do you mind giving a TL;DR version of what your range library does differently than phobos?

So the first difference you're likely to notice is that it's not as well documented. (Sorry. I'm a busy woman. I'll get around to it.) I try to make up for it with copious unit tests, which should provide a good example for how to use any given module.

In terms of functionality, the single-biggest difference is that unlike phobos I don't treat arrays or any other collection directly as ranges; instead types may provide an `asrange` property returning a range that enumerates their contents. This architecture allows you to express HOFs as shown in that prior post, not having to worry about whether it's safe to treat the array itself as a range or whether you have to slice it.

Other significant differences include not requiring bidirectional, slicing, random-access ranges to also be saving ("forward") ranges; (for the most part) supporting immutable elements in ranges; and a more clearly defined interface for what insertion and removal operations you may perform upon a range and how they are expected to behave. There are a few things phobos provides that I don't yet, but there's also a handful of things implemented in mach.range that aren't in phobos. (My personal favorite example of such is its small suite of PRNG implementations.)

Also: I just pushed the fix.