digitalmars.D.learn - Templates problem

Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```The code fragment:

const results =3D benchmark!(run_mean, run_mode, run_stdDev)(1);
const times =3D map!((TickDuration t) { return (to!Duration(t)).total!"sec=
onds"; })(results);

seems entirely reasonable to me. However rdmd 20160627 begs to differ:

run_checks.d(20): Error: template std.algorithm.iteration.map!(function (Ti=
ckDuration t) =3D> to(t).total()).map cannot deduce function from argument =
types !()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0std.algorithm.iteration.map!(function (TickDu=
ration t) =3D> to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!=
Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]

and I have no idea just now why it is complaining, nor what to do to
fix it.

--=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
```
Sep 06 2016
Lodovico Giaretta <lodovico giaretart.net> writes:
```On Tuesday, 6 September 2016 at 14:38:54 UTC, Russel Winder wrote:
The code fragment:

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

seems entirely reasonable to me. However rdmd 20160627 begs to
differ:

run_checks.d(20): Error: template
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map cannot deduce function from argument types
!()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):        std.algorithm.ite
ation.map!(function (TickDuration t) => to(t).total()).map(Range)(Range r) if
(isInputRange!(Unqual!Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]

and I have no idea just now why it is complaining, nor what to
do to fix it.

From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays aren't ranges. If you explicitly slice them,
they become dynamic arrays, which are ranges.

So the solution is to call `map` with `results[]` instead of
`results`.
```
Sep 06 2016
ketmar <ketmar ketmar.no-ip.org> writes:
```On Tuesday, 6 September 2016 at 14:50:17 UTC, Lodovico Giaretta
wrote:
From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays aren't ranges. If you explicitly slice
them, they become dynamic arrays, which are ranges.

So the solution is to call `map` with `results[]` instead of
`results`.

exactly. static arrays doesn't have `popFront`, hence
`isInputRange` fails. yet there is no way to tell that to user,
so one should just learn what those cryptic error messages really
means.

or just get used to always slice arrays, it's cheap. ;-)
```
Sep 06 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Tue, 2016-09-06 at 14:53 +0000, ketmar via Digitalmars-d-learn
wrote:
=20

[=E2=80=A6]
exactly. static arrays doesn't have `popFront`, hence=C2=A0
`isInputRange` fails. yet there is no way to tell that to user,=C2=A0
so one should just learn what those cryptic error messages really=C2=A0
means.

I shall assume a ;-) at the end of that. In trying to pitch D to
Pythonistas, having to deal with error messages of this sort is the
fastest route to "F    that I'll just use Python", with D consigned to
the dustbin.

Either that or it will make it very easy to pitch Chapel to
Pythonistas. Which I shall also be trying to do as well =E2=80=93 the idea =
is
to wean Pythonistas off hacking Python to achieve computational speed,
get them into a polyglot approach.

The issue here is having to compete against NumPy and Numba for
performance computation, and Matplotlib for data visualisation. C, C++,
Rust, Go will not cut it as competition in performance computation. D
and Chapel (and X10 and Fortran but I am avoiding them) can. Sort of.
The issue is that Python and Matplotlib should be seen as the partners
rather than competition for D and Chapel. Arcane error messages from D
compilers, are the fastest turn offs imaginable for people coming new
to a language.=C2=A0

or just get used to always slice arrays, it's cheap. ;-)

Except that it seems you cannot create a range from a const array by
slicing. If the algorithms cannot operate on const arrays then the
algorithms have a problem. If the algorithms have a problem, the
language has a problem.

--=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
```
Sep 07 2016
ketmar <ketmar ketmar.no-ip.org> writes:
```On Wednesday, 7 September 2016 at 08:30:51 UTC, Russel Winder
wrote:
On Tue, 2016-09-06 at 14:53 +0000, ketmar via
Digitalmars-d-learn wrote:

[…]
exactly. static arrays doesn't have `popFront`, hence
`isInputRange` fails. yet there is no way to tell that to
user, so one should just learn what those cryptic error
messages really means.

I shall assume a ;-) at the end of that.

alas, no jokes here. within the current D sytnax there is simply
no way to make that error less cryptic. :-(

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.

does `static assert(0, "please use slice for static arrays");`
may help in this case.
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 09:03 +0000, ketmar via Digitalmars-d-learn
wrote:
[=E2=80=A6]
=20
alas, no jokes here. within the current D sytnax there is simply=C2=A0
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=C2=A0
current DMDFE code (that's why nobody did it yet), and show=C2=A0
custom error for that is nearly impossible. we can't write "catch=C2=A0
all" template with static assert, 'cause it catches everything,=C2=A0
which is not desirable.
=20
i myself didn't found even acceptable solution for this mess.=C2=A0
sure, at least pointing to failed constraint is something we=C2=A0
should have, but in your case it is of little help, actually.
=20
does `static assert(0, "please use slice for static arrays");`=C2=A0
may help in this case.

I think bearophile suggested adding amap many moons ago.

I suspect this will never happen due to array(map(=E2=80=A6)) which is fine=
.

--=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
```
Sep 07 2016
ketmar <ketmar ketmar.no-ip.org> writes:
```On Wednesday, 7 September 2016 at 11:33:08 UTC, Russel Winder
wrote:
C++, error messages

sorry, i loled hard.
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Tue, 2016-09-06 at 14:50 +0000, Lodovico Giaretta via Digitalmars-d-
learn wrote:
=20

[=E2=80=A6]
=C2=A0From a quick look, it looks like `results` is a=C2=A0
`const(TickDuration[3])`, that is a fixed-length array. And=C2=A0
fixed-length arrays aren't ranges. If you explicitly slice them,=C2=A0
they become dynamic arrays, which are ranges.
=20
So the solution is to call `map` with `results[]` instead of=C2=A0
`results`.

So trying with results[] leads to:

run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(=
function (TickDuration t) =3D> to(t).total(), const(TickDuration)[]).MapRes=
ult.opIndex is not callable using a const object
run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(=
function (TickDuration t) =3D> to(t).total(), const(TickDuration)[]).MapRes=
ult.opIndex is not callable using a const object
run_checks.d(21): Error: mutable method std.algorithm.iteration.MapResult!(=
function (TickDuration t) =3D> to(t).total(), const(TickDuration)[]).MapRes=
ult.opIndex is not callable using a const object

yes, the message is repeated three times, for unknown reason. Possibly
because the compiler is fairly certain I am not going to believe it.

So the upshot of this is that I can't work with const data, which is
dreadful in these days of single assignment being the way of doing
things.

So what is the way of constructing a range from a const array? If it
involves copying then D is doomed.

And yes I am under stress as I am trying to pitch D to Python people
next week.

--=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
```
Sep 07 2016
Kagamin <spam here.lot> writes:
```https://dpaste.dzfl.pl/0b436b240e3c
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 08:42 +0000, Kagamin via Digitalmars-d-learn
wrote:
https://dpaste.dzfl.pl/0b436b240e3c

But now try adding the writeln function. Then you get the errors.

--=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
```
Sep 07 2016
Lodovico Giaretta <lodovico giaretart.net> writes:
```On Wednesday, 7 September 2016 at 08:19:39 UTC, Russel Winder
wrote:
On Tue, 2016-09-06 at 14:50 +0000, Lodovico Giaretta via
Digitalmars-d- learn wrote:

[…]
From a quick look, it looks like `results` is a
`const(TickDuration[3])`, that is a fixed-length array. And
fixed-length arrays aren't ranges. If you explicitly slice
them, they become dynamic arrays, which are ranges.

So the solution is to call `map` with `results[]` instead of
`results`.

So trying with results[] leads to:

run_checks.d(21): Error: mutable method
std.algorithm.iteration.MapResult!(function (TickDuration t) =>
to(t).total(), const(TickDuration)[]).MapResult.opIndex is not
callable using a const object
run_checks.d(21): Error: mutable method
std.algorithm.iteration.MapResult!(function (TickDuration t) =>
to(t).total(), const(TickDuration)[]).MapResult.opIndex is not
callable using a const object
run_checks.d(21): Error: mutable method
std.algorithm.iteration.MapResult!(function (TickDuration t) =>
to(t).total(), const(TickDuration)[]).MapResult.opIndex is not
callable using a const object

yes, the message is repeated three times, for unknown reason.
Possibly because the compiler is fairly certain I am not going
to believe it.

So the upshot of this is that I can't work with const data,
which is dreadful in these days of single assignment being the
way of doing things.

So what is the way of constructing a range from a const array?
If it involves copying then D is doomed.

And yes I am under stress as I am trying to pitch D to Python
people next week.

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.

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

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.
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 09:04 +0000, Lodovico Giaretta via Digitalmars-d-
learn wrote:
=20

[=E2=80=A6]
You have your const fixed-length array. You slice it and you=C2=A0
obtain a const range to feed map. Now map will not return you an=C2=A0
array. Because most of the time you don't need it. It will return=C2=A0
you a range that lazily computes its elements on demand. No=C2=A0
memory allocation at all. You can do a foreach on that range. If=C2=A0
you need to access those elements more than once, instead of=C2=A0
recomputing each of them every time it is accessed, you can store=C2=A0
the results of the map. You simply have to use .array on the map=C2=A0
result. This will allocate memory and give you an array with your=C2=A0
results. Otherwise, no allocation at all. That result array can=C2=A0
be const, if you want. If you need to access your elements only=C2=A0
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.=C2=A0

And by the way, there's no need to put const on everything. An=C2=A0
optimizing compiler is often able to infer things, especially for=C2=A0
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.=C2=A0

--=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
```
Sep 07 2016
Lodovico Giaretta <lodovico giaretart.net> writes:
```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
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```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
He liked their use of concepts. I think at a minimum it would
enable better error messages.
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 15:04:38 UTC, jmh530 wrote:
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.
He liked their use of concepts. I think at a minimum it would
enable better error messages.

I too come from the R world and I have been playing the game of
flitting between R and C++; using C++ (through RCpp) to speed up
slow things in R for some time and I have been looking for a
better solution.

For some time I have been considering a problem to do with
creating tables with unbounded types, one of the failed attempts
is here:
I then exchanged emails with Lucian, Sparrows creator and he very
quickly and simply outlined the solution to the problem.
Thereafter I read his PhD thesis - one of the most informative
texts in computer science I have read and very well written.

At the moment, there are lots of languages attempting to solve
the dynamic-static loop, being able to have features inherent in
dynamic programming languages, while keeping the safety and
performance that comes with a static compiled programming
language, and then doing so in a language that doesn't cause your
brain to bleed. The "One language to rule them all" motif of
Julia has hit the rocks; one reason is because they now realize
that their language is being held back because the compiler
cannot infer certain types for example:
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

A language that can create arbitrary complex programs is the kind
of thing that changes the world. I don't think D should be left
out and should take Sparrow very seriously indeed.
```
Sep 07 2016
deXtoRious <dextorious gmail.com> writes:
```On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
The "One language to rule them all" motif of Julia has hit the
rocks; one reason is because they now realize that their
language is being held back because the compiler cannot infer
certain types for example:
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

As an avid user of Julia, I'm going to have to disagree very
strongly with this statement. The language is progressing very
nicely and while it doesn't aim to be the best choice for every
letting a scientific programmer such as myself do most of my
workflow in a single language with remarkable performance.
Furthermore, the article you linked pertains to a simple type
inference issue, exposed by the design constraints of a
particular library. While certain design patterns can and often
do lead to Python-style Julia code with optimal performance, you
can always get there by manually enforcing type stability at the
cost of less pretty code.

More to the general point of the discussion, I find that most
scientifically minded users of Python already appreciate some of
the inherent advantages of lower level statically typed languages
and often rather write C/C++ code than descend into the likes of
Cython. D has considerable advantages over C++ in conciseness and
template facilities for achieving zero cost static polymorphism
without descending into utter unreadability. Personally, I find
myself still forced to write most of my non-Julia high
performance code in C++ due to the available libraries and GPGPU
support (especially CUDA), but in terms of language properties
I'd much rather be writing D.
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:29:51 UTC, deXtoRious wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
The "One language to rule them all" motif of Julia has hit the
rocks; one reason is because they now realize that their
language is being held back because the compiler cannot infer
certain types for example:
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

As an avid user of Julia, I'm going to have to disagree very
strongly with this statement. The language is progressing very
nicely and while it doesn't aim to be the best choice for every

Ahem (http://www.wired.com/2014/02/julia/), I'm not saying that
the Julia founders approved that title, we all know how the press
can inflate things, but there was a certain rhetoric that Julia
was creating something super-special that would change everything.
```
Sep 07 2016
deXtoRious <dextorious gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:57:03 UTC, data pulverizer
wrote:
On Wednesday, 7 September 2016 at 20:29:51 UTC, deXtoRious
wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data
pulverizer wrote:
The "One language to rule them all" motif of Julia has hit
the rocks; one reason is because they now realize that their
language is being held back because the compiler cannot infer
certain types for example:
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

As an avid user of Julia, I'm going to have to disagree very
strongly with this statement. The language is progressing very
nicely and while it doesn't aim to be the best choice for

Ahem (http://www.wired.com/2014/02/julia/), I'm not saying that
the Julia founders approved that title, we all know how the
press can inflate things, but there was a certain rhetoric that
Julia was creating something super-special that would change
everything.

That's just typical press nonsense, and even they quote Bezanson
saying how Julia isn't at all suited to a whole host of
applications. Julia certainly has (justifiable, imho, though only
time will tell) aspirations of being useful in certain areas of
general computing, not just scientific code, but they are far
from universal applicability, let alone optimality. If nothing
else, it's an interesting example of thinking rather far outside
the usual box of language design, one with demonstrable real
world applications.
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 21:01:59 UTC, deXtoRious wrote:
That's just typical press nonsense, and even they quote
Bezanson saying how Julia isn't at all suited to a whole host
of applications. Julia certainly has (justifiable, imho, though
only time will tell) ...

Don't get me wrong, I still think Julia is a very cool language.
My opinion is that we should have more languages.
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 21:07:20 UTC, data pulverizer
wrote:
Don't get me wrong, I still think Julia is a very cool
language. My opinion is that we should have more languages.

Let me correct myself ... I think that hyper-meta-programming as
in Sparrow could certainly revolutionize computing. I think that
a big deal.
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Wednesday, 7 September 2016 at 21:01:59 UTC, deXtoRious wrote:
That's just typical press nonsense, and even they quote
Bezanson saying how Julia isn't at all suited to a whole host
of applications. Julia certainly has (justifiable, imho, though
only time will tell) aspirations of being useful in certain
areas of general computing, not just scientific code, but they
are far from universal applicability, let alone optimality. If
nothing else, it's an interesting example of thinking rather
far outside the usual box of language design, one with
demonstrable real world applications.

It's also from 2014...
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 20:29 +0000, deXtoRious via Digitalmars-d-learn
wrote:
=20

[=E2=80=A6]
More to the general point of the discussion, I find that most=C2=A0
scientifically minded users of Python already appreciate some of=C2=A0
the inherent advantages of lower level statically typed languages=C2=A0
and often rather write C/C++ code than descend into the likes of=C2=A0
Cython. D has considerable advantages over C++ in conciseness and=C2=A0
template facilities for achieving zero cost static polymorphism=C2=A0
without descending into utter unreadability. Personally, I find=C2=A0
myself still forced to write most of my non-Julia high=C2=A0
performance code in C++ due to the available libraries and GPGPU=C2=A0
support (especially CUDA), but in terms of language properties=C2=A0
I'd much rather be writing D.

Or Chapel.

--=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
```
Sep 08 2016
deXtoRious <dextorious gmail.com> writes:
```On Thursday, 8 September 2016 at 10:20:42 UTC, Russel Winder
wrote:
On Wed, 2016-09-07 at 20:29 +0000, deXtoRious via
Digitalmars-d-learn wrote:

[…]
More to the general point of the discussion, I find that most
scientifically minded users of Python already appreciate some
of the inherent advantages of lower level statically typed
languages and often rather write C/C++ code than descend into
the likes of Cython. D has considerable advantages over C++ in
conciseness and template facilities for achieving zero cost
static polymorphism without descending into utter
unreadability. Personally, I find myself still forced to write
most of my non-Julia high performance code in C++ due to the
available libraries and GPGPU support (especially CUDA), but
in terms of language properties I'd much rather be writing D.

Or Chapel.

It's very early days for Chapel at the moment, but I don't really
see it as being remotely comparable to D or even Julia, it's much
closer to a DSL than a general purpose language. That's by no
means a bad thing, it seems like it could be a very useful tool
in a few years, but it's never going to completely substitute for
the likes of Python, C++ or D even for purely scientific
programming. I'm also a bit concerned about how limited the
compile time facilities seem there at the moment, but I guess
we'll just have to wait and see how it develops over the next
couple of years.
```
Sep 08 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Thu, 2016-09-08 at 15:45 +0000, deXtoRious via Digitalmars-d-learn
wrote:
=20

[=E2=80=A6]
It's very early days for Chapel at the moment, but I don't really=C2=A0
see it as being remotely comparable to D or even Julia, it's much=C2=A0
closer to a DSL than a general purpose language. That's by no=C2=A0
means a bad thing, it seems like it could be a very useful tool=C2=A0
in a few years, but it's never going to completely substitute for=C2=A0
the likes of Python, C++ or D even for purely scientific=C2=A0
programming. I'm also a bit concerned about how limited the=C2=A0
compile time facilities seem there at the moment, but I guess=C2=A0
we'll just have to wait and see how it develops over the next=C2=A0
couple of years.

In some sense Chapel is a 12 year old programming language, but clearly
it is still a bit of a youngster in many ways. In that Chapel was
developed to deal with programming supercomputers, it is a niche
language for heavyweight computation. But that is exactly what Python
is missing, and whilst NumPy, Numba, Cython, C, C++, Fortran, and D can
help, none of them can make programming parallel systems quite as nice
as a language specifically designed for the job.

Chapel programming has a not dissimilar "feel" to D programming in many
ways, it's just that Chapel is aimed at big kit, and D isn't. The trick
though is that Chapel can be used on little kit as well and in this
sense competes directly with D. The Chapel team are well funded, but
are still focused on big kit, but are turning their attention to
traction and little kit. In this sense Chapel could be a risk to D
traction.

Chapel focuses on arrays so it is very much a competitor to NumPy.
Except that NumPy has many more years of things built on top of it than
Chapel has.

For programming computations for anything other than a small laptop,
I'd choose Chapel over Python/NumPy any day. For visualising the
results teh Python milieu wins hands down.

--=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
```
Sep 10 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
For some time I have been considering a problem to do with
creating tables with unbounded types, one of the failed
attempts is here:
I then exchanged emails with Lucian, Sparrows creator and he
very quickly and simply outlined the solution to the problem.
Thereafter I read his PhD thesis - one of the most informative
texts in computer science I have read and very well written.

At the moment, there are lots of languages attempting to solve
the dynamic-static loop, being able to have features inherent
in dynamic programming languages, while keeping the safety and
performance that comes with a static compiled programming
language, and then doing so in a language that doesn't cause
your brain to bleed. The "One language to rule them all" motif
of Julia has hit the rocks; one reason is because they now
realize that their language is being held back because the
compiler cannot infer certain types for example:
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

I don't see any reason why D can't implement pandas DataFrames
without needing to change the language at all
http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
It's just a lot of work.

The simplest I can think of is a struct containing a tuple that
contains slices of equal length and an array of strings
containing column names. You could have a specialization with a
two-dimensional array (or ndslice).
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:37:50 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
For some time I have been considering a problem to do with
creating tables with unbounded types, one of the failed
attempts is here:
I then exchanged emails with Lucian, Sparrows creator and he
very quickly and simply outlined the solution to the problem.
Thereafter I read his PhD thesis - one of the most informative
texts in computer science I have read and very well written.

At the moment, there are lots of languages attempting to solve
the dynamic-static loop, being able to have features inherent
in dynamic programming languages, while keeping the safety and
performance that comes with a static compiled programming
language, and then doing so in a language that doesn't cause
your brain to bleed. The "One language to rule them all" motif
of Julia has hit the rocks; one reason is because they now
realize that their language is being held back because the
compiler cannot infer certain types for example:
http://www.johnmyleswhite.com/notebook/2015/11/28/why-julias-dataframes-are-still-slow/

I don't see any reason why D can't implement pandas DataFrames
without needing to change the language at all
http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
It's just a lot of work.

The simplest I can think of is a struct containing a tuple that
contains slices of equal length and an array of strings
containing column names. You could have a specialization with a
two-dimensional array (or ndslice).

You're quite right that D doesn't need to change at all to
implement something like pandas or dataframes in R, but I am
thinking of how to got further. Very often in data science
applications types will turn up that are required but are not
currently configured for your table. The choice you have is to
have to modify the code or as scala does give programmers the
ability to write their own interface to the type so that the it
can be stored in their DataFrame. The best solution is that the
data table is able to cope with arbitrary number of types which
can be done in Sparrow.
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:49:42 UTC, data pulverizer
wrote:
You're quite right that D doesn't need to change at all to
implement something like pandas or dataframes in R, but I am
thinking of how to got further. Very often in data science
applications types will turn up that are required but are not
currently configured for your table. The choice you have is to
have to modify the code or as scala does give programmers the
ability to write their own interface to the type so that the it
can be stored in their DataFrame.

I think part of the difficulty is that you're thinking in terms
of everything being dynamic. If all your data is statically typed
in the first place, then I don't see what the issue is.

Consider a potential use case. You have an existing data frame
and you want to add a column of data to it that has a different
type than the existing frame. I imagine the function call would
look something like:
So you just need to ensure that the data frame struct or class
has an addCol method that returns a new frame with the correct
type when you add a column.

I'm not familiar with Scala's data frames.

The best solution is that the data table is able to cope with
arbitrary number of types which can be done in Sparrow.

D has support for an arbitrary number of types (tuple, variant,
algebraic). It's just a matter of putting it together.

Anyway, given that Sparrow is still in its early stages, if you
actually want to get some work done, D might be a better fit.

On Wednesday, 7 September 2016 at 20:52:26 UTC, data pulverizer
wrote:
p.s. it goes beyond just tables, ... having dynamic capability
in a static compiled language really does take computing to a
different place indeed.

There are some dynamic capabilities in D, such as
variant/algebraic and Adam Ruppe's jsvar. I only wonder if you
would lose performance if wanted something fully dynamic. A
static approach is a good starting place.
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 21:25:30 UTC, jmh530 wrote:
Consider a potential use case. You have an existing data frame
and you want to add a column of data to it that has a different
type than the existing frame. I imagine the function call would
look something like:

Yes, but from a usability point of view this would be very poor -
forcing the user to create a new variable each time they modified
a table. I am aware that databases do this but it is hidden away.

... I only wonder if you would lose performance if wanted
something fully dynamic. A static approach is a good starting
place.

Yes you would, which is why I see the hyper-meta route as being
the potential solution to this issue.
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Wednesday, 7 September 2016 at 21:41:20 UTC, data pulverizer
wrote:
Yes, but from a usability point of view this would be very poor
- forcing the user to create a new variable each time they
modified a table. I am aware that databases do this but it is
hidden away.

To be fair, you can still mutate values within the table. In this
approach, it's only appending new columns (or inserting them or
something) that requires a new variable. It shouldn't be an issue
slices. It might be possible to do this without creating a
variable, but I haven't thought about it that carefully.

Moreover, if you're working with slices, then it's a reference
type. This means that the new variable is not a copy of the old.
It shouldn't take up much space.
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:37:50 UTC, jmh530 wrote:
On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
I don't see any reason why D can't implement pandas DataFrames
without needing to change the language at all
http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.html
It's just a lot of work.

The simplest I can think of is a struct containing a tuple that
contains slices of equal length and an array of strings
containing column names. You could have a specialization with a
two-dimensional array (or ndslice).

p.s. it goes beyond just tables, ... having dynamic capability in
a static compiled language really does take computing to a
different place indeed.
```
Sep 07 2016
bachmeier <no spam.net> writes:
```On Wednesday, 7 September 2016 at 19:19:23 UTC, data pulverizer
wrote:
On Wednesday, 7 September 2016 at 15:04:38 UTC, jmh530 wrote:
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.
He liked their use of concepts. I think at a minimum it would
enable better error messages.

I too come from the R world and I have been playing the game of
flitting between R and C++; using C++ (through RCpp) to speed
up slow things in R for some time and I have been looking for a
better solution.

What are you doing with Rcpp that you can't do with D?
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote:
What are you doing with Rcpp that you can't do with D?

That's a very good point, there's nothing that R + C++ can do
that is out of D's reach. But, I wander if we can go further ....
```
Sep 07 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote:
I too come from the R world and I have been playing the game
of flitting between R and C++; using C++ (through RCpp) to
speed up slow things in R for some time and I have been
looking for a better solution.

What are you doing with Rcpp that you can't do with D?

Sorry I'll correct myself again! Because R is a dynamic
programming language, you could do things that you could not do
in D, however they would be very inefficient.
hyper-meta-programming takes this barrier away.
```
Sep 07 2016
bachmeier <no spam.net> writes:
```On Wednesday, 7 September 2016 at 22:11:05 UTC, data pulverizer
wrote:
On Wednesday, 7 September 2016 at 20:57:15 UTC, bachmeier wrote:
I too come from the R world and I have been playing the game
of flitting between R and C++; using C++ (through RCpp) to
speed up slow things in R for some time and I have been
looking for a better solution.

What are you doing with Rcpp that you can't do with D?

Sorry I'll correct myself again! Because R is a dynamic
programming language, you could do things that you could not do
in D, however they would be very inefficient.
hyper-meta-programming takes this barrier away.

I meant use a combination of R + D rather than R + C++. Any
bottlenecks can be handled in D as easily as C++. However, if you
want to go beyond what you can do with Rcpp, it's a different
story.
```
Sep 07 2016
Kagamin <spam here.lot> writes:
```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?
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 16:21 +0000, Kagamin via Digitalmars-d-learn
wrote:
On Wednesday, 7 September 2016 at 11:37:44 UTC, Russel Winder=C2=A0
wrote:
=20
The real problem though is the terrifying error message. I am=C2=A0
having a hard time finding a way of pitching them to=C2=A0
Pythonistas.

=20
Do they use single assignment a lot?

Python has no notion of single assignment. Exactly the opposite, Python
allows everything to be changed at any time.

I fear there is a confluence of disjoint subthreads happening here.
Probably my fault.

--=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
```
Sep 08 2016
Kagamin <spam here.lot> writes:
```On Thursday, 8 September 2016 at 10:26:04 UTC, Russel Winder
wrote:
Do they use single assignment a lot?

Python has no notion of single assignment. Exactly the
opposite, Python allows everything to be changed at any time.

Then you probably shouldn't pitch them alien concepts?
```
Sep 09 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Fri, 2016-09-09 at 12:22 +0000, Kagamin via Digitalmars-d-learn
wrote:
On Thursday, 8 September 2016 at 10:26:04 UTC, Russel Winder=C2=A0
wrote:
=20
=20
Do they use single assignment a lot?

=20
Python has no notion of single assignment. Exactly the=C2=A0
opposite, Python allows everything to be changed at any time.

=20
Then you probably shouldn't pitch them alien concepts?

Or maybe they need those alien concepts. Consider Python now has type
signatures for functions and methods.

--=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
```
Sep 10 2016
rikki cattermole <rikki cattermole.co.nz> writes:
```On 07/09/2016 2:38 AM, Russel Winder via Digitalmars-d-learn wrote:
The code fragment:

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

seems entirely reasonable to me. However rdmd 20160627 begs to differ:

run_checks.d(20): Error: template std.algorithm.iteration.map!(function
(TickDuration t) => to(t).total()).map cannot deduce function from argument
types !()(const(TickDuration[3])), candidates are:
/usr/include/dmd/phobos/std/algorithm/iteration.d(450):
std.algorithm.iteration.map!(function (TickDuration t) =>
to(t).total()).map(Range)(Range r) if (isInputRange!(Unqual!Range))
Failed: ["dmd", "-v", "-o-", "run_checks.d", "-I."]

and I have no idea just now why it is complaining, nor what to do to
fix it.

Ok, I have it mostly compiling.

void run_mean() {}
void run_mode() {}
void run_stdDev() {}

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

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

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.

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.
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 20:32 +1200, rikki cattermole via Digitalmars-d-
learn wrote:
=20

[=E2=80=A6]
Ok, I have it mostly compiling.
=20
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 =3D benchmark!(run_mean, run_mode, run_stdDev)(1);
const times =3D map!((TickDuration t) { return=C2=A0
(to!Duration(t)).total!"seconds"; })(results[]);

It turns out my problem was here. See below.

import std.stdio;
foreach(v; times) {
writeln(v);=09
}
}
=20
However times really can't be const. Since times is an input range
which=C2=A0
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=C2=

=A0
from std.algorithm it which can be const. Either way there is
something=C2=A0
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.

--=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
```
Sep 07 2016
pineapple <meapineapple gmail.com> writes:
```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.
}
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```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?
```
Sep 07 2016
pineapple <meapineapple gmail.com> writes:
```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.
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Wednesday, 7 September 2016 at 18:55:41 UTC, pineapple wrote:
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.)

Thanks for the reply. It looks like an interesting idea. You
might consider adding this (or a modified version) to a read me
in the range subfolder.

Are you familiar with Chapel at all? The language allows the user
to specify a domain with an array, facilitating sparsity or
arrays distributed across different machines. For some reason I
was reminded of that when you say that asrange returns a range
that enumerates the contents.
```
Sep 07 2016
pineapple <meapineapple gmail.com> writes:
```On Wednesday, 7 September 2016 at 20:29:42 UTC, jmh530 wrote:
Thanks for the reply. It looks like an interesting idea. You
might consider adding this (or a modified version) to a read me
in the range subfolder.

Fuck it, I took an hour to document the most significant modules.

https://github.com/pineapplemachine/mach.d/tree/master/mach/range
```
Sep 07 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Wednesday, 7 September 2016 at 21:33:25 UTC, pineapple wrote:
Fuck it, I took an hour to document the most significant
modules.

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

Looks like a step in the right direction!
```
Sep 07 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Wed, 2016-09-07 at 20:29 +0000, jmh530 via Digitalmars-d-learn
wrote:
=20

[=E2=80=A6]
Are you familiar with Chapel at all? The language allows the user=C2=A0
to specify a domain with an array, facilitating sparsity or=C2=A0
arrays distributed across different machines. For some reason I=C2=A0
was reminded of that when you say that asrange returns a range=C2=A0
that enumerates the contents.

I am certainly hoping that Chapel will be the language to displace
NumPy for serious computation in the Python-sphere. Given it's
foundation in the PGAS model, it has all the parallelism needs, both
cluster and local, built in. Given Chapel there is no need to look at
C++, D, Rust, Cython, etc.=C2=A0

--=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
```
Sep 08 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder
wrote:
I am certainly hoping that Chapel will be the language to
displace NumPy for serious computation in the Python-sphere.
Given it's foundation in the PGAS model, it has all the
parallelism needs, both cluster and local, built in. Given
Chapel there is no need to look at C++, D, Rust, Cython, etc.

still has some ways to go on the latter. Also, they are still in
the early stages of GPU support, I think.
```
Sep 08 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Thu, 2016-09-08 at 13:09 +0000, jmh530 via Digitalmars-d-learn
wrote:
On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder=C2=A0
wrote:
=20
=20
I am certainly hoping that Chapel will be the language to=C2=A0
displace NumPy for serious computation in the Python-sphere.=C2=A0
Given it's foundation in the PGAS model, it has all the=C2=A0
parallelism needs, both cluster and local, built in. Given=C2=A0
Chapel there is no need to look at C++, D, Rust, Cython, etc.

=20
still has some ways to go on the latter. Also, they are still in=C2=A0
the early stages of GPU support, I think.

For computational work I'd say Chapel was just as productive as any
other language, probably better. This is though likely an issue on
which there is only opinion and no facts.

GPGPU support is not in Chapel as yet I believe, but then it isn't in
Python either.

--=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
```
Sep 09 2016
jmh530 <john.michael.hall gmail.com> writes:
```On Friday, 9 September 2016 at 13:24:18 UTC, Russel Winder wrote:
For computational work I'd say Chapel was just as productive as
any other language, probably better. This is though likely an
issue on which there is only opinion and no facts.

GPGPU support is not in Chapel as yet I believe, but then it
isn't in Python either.

What I mean is that Chapel doesn't have a lot of libraries (also
true for D, but things are getting better). If I'm going to do
some analysis, it usually takes much less time for me to do it in
R/Python/Matlab because they typically already have the libraries
that can do everything I need.
```
Sep 09 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Fri, 2016-09-09 at 14:20 +0000, jmh530 via Digitalmars-d-learn
wrote:
[=E2=80=A6]
=20
What I mean is that Chapel doesn't have a lot of libraries (also=C2=A0
true for D, but things are getting better). If I'm going to do=C2=A0
some analysis, it usually takes much less time for me to do it in=C2=A0
R/Python/Matlab because they typically already have the libraries=C2=A0
that can do everything I need.

This is very true: Python has the masses of things built on Python and
NumPy today that make things easy to work with. My feeling is though
that NumPy is not going to survive the next revolution in workstation
and performance laptop hardware. Unless it absorbs the Chapel (or X10)
PGAS model. The fastest way of doing this is to ditch the NumPy
implementation and exchange it for either Chapel or something Chapel
inspired.

--=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
```
Sep 10 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Thursday, 8 September 2016 at 10:18:36 UTC, Russel Winder
wrote:
I am certainly hoping that Chapel will be the language to
displace NumPy for serious computation in the Python-sphere.
Given it's foundation in the PGAS model, it has all the
parallelism needs, both cluster and local, built in. Given
Chapel there is no need to look at C++, D, Rust, Cython, etc.

I can see where you are coming from, I have taken a look at
Chapel and high performance computing is their top priority. I
think they hope that it will be the next Fortran, but I think it
is very much a domain specific language. They have clearly given
plenty of thought to distributed computing, parallelization and
concurrency that could yield some very nice performance
language and can act as a front end to algorithms written in
C/C++ for instance as Google has done with TensorFlow. In the
future it could even act as a front end to Chapel since they now
have a C API.

However, I feel as if computer programming languages are still in
this static-dynamic partnership, e.g. Python with C/C++, R and
Fortran/C/C++. It means language overhead always maintaining code
in more than one language and always having to amend your
interface every time you change something in one or the other. In
essence, nothing fundamentally different is happening with
current new languages. I hate to sound like a broken record, but
what Sparrow proposes is a unification in such a way that all
kinds of overheads go away. Making something like that work with
the principles of Sparrow would be a revolution in computing.
```
Sep 08 2016
Russel Winder via Digitalmars-d-learn <digitalmars-d-learn puremagic.com> writes:
```On Thu, 2016-09-08 at 14:39 +0000, data pulverizer via Digitalmars-d-
learn wrote:
[=E2=80=A6]
=20
I can see where you are coming from, I have taken a look at=C2=A0
Chapel and high performance computing is their top priority. I=C2=A0
think they hope that it will be the next Fortran, but I think it=C2=A0
is very much a domain specific language. They have clearly given=C2=A0
plenty of thought to distributed computing, parallelization and=C2=A0
concurrency that could yield some very nice performance=C2=A0
language and can act as a front end to algorithms written in=C2=A0
C/C++ for instance as Google has done with TensorFlow. In the=C2=A0
future it could even act as a front end to Chapel since they now=C2=A0
have a C API.

Why write algorithms in C or C++ when you can do it in Chapel? The
point here is that Python folk should look to languages like Chapel and
not C, C++, or even D when they reach the limits of Python performance.

And yes I am trying to get PyChapel to run on Python 3 as well as
Python 2.

However, I feel as if computer programming languages are still in=C2=A0
this static-dynamic partnership, e.g. Python with C/C++, R and=C2=A0
Fortran/C/C++. It means language overhead always maintaining code=C2=A0
in more than one language and always having to amend your=C2=A0
interface every time you change something in one or the other. In=C2=A0
essence, nothing fundamentally different is happening with=C2=A0
current new languages. I hate to sound like a broken record, but=C2=A0
what Sparrow proposes is a unification in such a way that all=C2=A0
kinds of overheads go away. Making something like that work with=C2=A0
the principles of Sparrow would be a revolution in computing.

But how are they going to get traction?

Should we be giving up on D and switching to Sparrow?

Polyglots programmers tend to be better programmers. This is not
opinion, there is experimental evidence for this in the psychology of
programming literature.

--=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
```
Sep 09 2016
data pulverizer <data.pulverizer gmail.com> writes:
```On Friday, 9 September 2016 at 13:32:16 UTC, Russel Winder wrote:
Should we be giving up on D and switching to Sparrow?

Most certainly not! I don't think it has to be either D or
Sparrow. There is a quote liked from one of Walter's

"What happens when the next great modelling idea comes along?"

Walter:

"D will absorb it"

Polyglots programmers tend to be better programmers. This is
not opinion, there is experimental evidence for this in the
psychology of programming literature.

I certainly think that training programmers on lots of different
programming languages and paradigms will produce better
programmers on average. I guess the analogy is in multi-lingual
language training for children. However this does not affect my
original point on the overhead caused by constantly switching
languages in development and the host of benefits that would come
from making Sparrow's programming model work.
```
Sep 09 2016
deXtoRious <dextorious gmail.com> writes:
```On Friday, 9 September 2016 at 13:32:16 UTC, Russel Winder wrote:
Why write algorithms in C or C++ when you can do it in Chapel?

For the moment, the objective answers to that question seem: you
need GPGPU (especially CUDA, which is vastly more convenient to
use from C++ than from anything else), you're attached to a C++
codebase/libraries (calling C code is trivial, C++ far from it
generally) or you need the low level flexibility afforded by
C/C++. Personally, I probably won't consider Chapel for serious
projects until at least the first point is solved.

Of course, there's also a host of subjective reasons --
attachment to more familiar languages, difficulty of selling new
languages to coworkers, preference for larger communities, etc.
All of those take time to overcome.
```
Sep 09 2016