On Wednesday, 3 February 2016 at 20:12:38 UTC, Atila Neves wrote:
On Wednesday, 3 February 2016 at 16:40:49 UTC, Andrei
Alexandrescu wrote:
On 02/03/2016 10:18 AM, Atila Neves wrote:
I guess this is to be a brand new PR? I've been reading the
old one and
the discussions. A lot of unanswered
On Saturday, 30 January 2016 at 18:08:00 UTC, David Nadlinger
wrote:
Currying is turning (A, B, C) -> D into A -> (B -> (C -> D)),
i.e. a function with multiple arguments into a sequence of
functions that each take a single argument to apply each.
I think I've implemented something like that
On Thursday, 4 February 2016 at 08:29:46 UTC, Dragos Carp wrote:
I will prepare a PR for the binary function implementation.
The PR is ready for review:
https://github.com/D-Programming-Language/phobos/pull/3972
On Wednesday, 3 February 2016 at 21:45:04 UTC, Timon Gehr wrote:
On 02/03/2016 09:12 PM, Atila Neves wrote:
https://github.com/D-Programming-Language/phobos/pull/3968
I think fold should be nothrow, but maybe that's just me. It's
also a
massive pain to make it that way, so I didn't for now.
On Friday, 29 January 2016 at 20:40:18 UTC, Andrei Alexandrescu
wrote:
On 01/29/2016 08:56 AM, Dragos Carp wrote:
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
[...]
But not in python, where "accumulate"[1] is the generic
equivalent of
C++ "partial_sum"[2]. I like "fold"
On 02/04/2016 10:38 AM, Atila Neves wrote:
On Wednesday, 3 February 2016 at 21:45:04 UTC, Timon Gehr wrote:
On 02/03/2016 09:12 PM, Atila Neves wrote:
https://github.com/D-Programming-Language/phobos/pull/3968
I think fold should be nothrow, but maybe that's just me. It's also a
massive pain
On Wednesday, 3 February 2016 at 16:39:26 UTC, Andrei
Alexandrescu wrote:
On 02/01/2016 03:46 AM, Dragos Carp wrote:
On Friday, 29 January 2016 at 20:40:18 UTC, Andrei
Alexandrescu wrote:
That'd be interesting if (a) lazy and (b) general a la
On 02/03/2016 09:12 PM, Atila Neves wrote:
https://github.com/D-Programming-Language/phobos/pull/3968
I think fold should be nothrow, but maybe that's just me. It's also a
massive pain to make it that way, so I didn't for now.
Returning Unqual!(ElementType!R).init makes no sense though.
The
On Wednesday, 3 February 2016 at 21:45:04 UTC, Timon Gehr wrote:
On 02/03/2016 09:12 PM, Atila Neves wrote:
https://github.com/D-Programming-Language/phobos/pull/3968
I think fold should be nothrow, but maybe that's just me. It's
also a
massive pain to make it that way, so I didn't for now.
On Wednesday, 3 February 2016 at 00:57:18 UTC, Andrei
Alexandrescu wrote:
On 2/2/16 3:50 PM, Atila Neves wrote:
On Tuesday, 2 February 2016 at 20:02:39 UTC, Andrei
Alexandrescu wrote:
On 2/2/16 11:02 AM, Atila Neves wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei
Alexandrescu wrote:
On Wed, Feb 03, 2016 at 10:30:45PM +, John Colvin via Digitalmars-d wrote:
> On Wednesday, 3 February 2016 at 21:45:04 UTC, Timon Gehr wrote:
> >On 02/03/2016 09:12 PM, Atila Neves wrote:
> >>
> >>https://github.com/D-Programming-Language/phobos/pull/3968
> >>
> >>I think fold should be
On 2/3/2016 8:39 AM, Andrei Alexandrescu wrote:
My ambitions were lower :o). I was thinking of supporting any operation, not
only summation.
Erik Meijer lists a lot of interesting things that can be done with fold:
On 02/01/2016 03:46 AM, Dragos Carp wrote:
On Friday, 29 January 2016 at 20:40:18 UTC, Andrei Alexandrescu wrote:
That'd be interesting if (a) lazy and (b) general a la
https://dlang.org/library/std/range/recurrence.html. -- Andrei
To be clear, by general you mean to allow functions with more
On 02/03/2016 10:18 AM, Atila Neves wrote:
I guess this is to be a brand new PR? I've been reading the old one and
the discussions. A lot of unanswered questions there and I have a new
opinion on at least one of them.
If by the old one you mean the valiant effort to overload reduce, forget
On Wednesday, 3 February 2016 at 16:40:49 UTC, Andrei
Alexandrescu wrote:
On 02/03/2016 10:18 AM, Atila Neves wrote:
I guess this is to be a brand new PR? I've been reading the
old one and
the discussions. A lot of unanswered questions there and I
have a new
opinion on at least one of them.
On 2/2/16 11:02 AM, Atila Neves wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
On 1/30/16 1:08 PM, David Nadlinger wrote:
On Saturday, 30 January 2016 at 17:40:38 UTC, Andrei Alexandrescu wrote:
I forgot the distinction between currying and partial application. Can
we also define currying in current D? -- Andrei
Currying is turning (A, B, C) -> D into A -> (B -> (C ->
On Tuesday, 2 February 2016 at 20:02:39 UTC, Andrei Alexandrescu
wrote:
On 2/2/16 11:02 AM, Atila Neves wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei
Alexandrescu wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of
On 2/2/16 3:50 PM, Atila Neves wrote:
On Tuesday, 2 February 2016 at 20:02:39 UTC, Andrei Alexandrescu wrote:
On 2/2/16 11:02 AM, Atila Neves wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
As has been discussed before there's been discussion about
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On Friday, 29 January 2016 at 20:40:18 UTC, Andrei Alexandrescu
wrote:
That'd be interesting if (a) lazy and (b) general a la
https://dlang.org/library/std/range/recurrence.html. -- Andrei
To be clear, by general you mean to allow functions with more
than 2 arguments?
For example if you
On 01/29/2016 02:56 PM, Dragos Carp wrote:
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started using
std.algorithm I was ctrl-F'ing for "accumulate" and not finding it
quite often. D competes with C++ directly, so do
On Saturday, 30 January 2016 at 17:40:38 UTC, Andrei Alexandrescu
wrote:
On 1/30/16 12:25 PM, Xinok wrote:
I forgot the distinction between currying and partial
application. Can we also define currying in current D? -- Andrei
I'm sure others can give an informed answer on the distinction,
On Saturday, 30 January 2016 at 12:11:37 UTC, Ola Fosheim Grøstad
wrote:
Currying is pointless, I believe Swift is removing it. ...
It might be fairly useless in D but it's definitely not useless
in general. It' a different design pattern and functional
languages make great use of it. OTOH,
On 1/30/16 12:25 PM, Xinok wrote:
On Saturday, 30 January 2016 at 12:11:37 UTC, Ola Fosheim Grøstad wrote:
Currying is pointless, I believe Swift is removing it. ...
It might be fairly useless in D but it's definitely not useless in
general. It' a different design pattern and functional
On Saturday, 30 January 2016 at 17:40:38 UTC, Andrei Alexandrescu
wrote:
I forgot the distinction between currying and partial
application. Can we also define currying in current D? -- Andrei
Currying is turning (A, B, C) -> D into A -> (B -> (C -> D)),
i.e. a function with multiple arguments
On Saturday, 30 January 2016 at 01:34:48 UTC, deadalnix wrote:
On Friday, 29 January 2016 at 23:45:04 UTC, Ola Fosheim Grøstad
wrote:
So D is adding currying and builtin tuples? :^)
Yes. Come back in 10 years it'll be ready for you.
Currying is pointless, I believe Swift is removing it. I
On Friday, 29 January 2016 at 13:56:48 UTC, Dragos Carp wrote:
But not in python, where "accumulate"[1] is the generic
equivalent of C++ "partial_sum"[2]. I like "fold" more.
BTW this week, a colleague of mine implemented a python
"accumulate" in D. Is there any interest to contribute it to
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started
using std.algorithm I was ctrl-F'ing for "accumulate" and not
finding it quite often. D competes with C++ directly, so do
consider that name :-)
But not in python,
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
So the next best solution is to introduce a new name such as
the popular "fold", and put them together in the documentation.
Just to bikeshed a little, I remember that when I first started
using std.algorithm I was
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd be subtle
ambiguities if we worked reduce to implement both orders.
So the next best solution is to
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On Friday, 29 January 2016 at 16:38:23 UTC, Brad Anderson wrote:
And just for completeness, here is monarchdodra's valiant but
ultimately unsuccessful pull request which attempted fix
reduce:
https://github.com/D-Programming-Language/phobos/pull/861#issuecomment-20760448
Interestingly, that
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
So the next best solution is to introduce a new name such as
the popular "fold", and put them together in the documentation.
Just to bikeshed a little, I
On Friday, 29 January 2016 at 23:45:04 UTC, Ola Fosheim Grøstad
wrote:
So D is adding currying and builtin tuples? :^)
Yes. Come back in 10 years it'll be ready for you.
On Friday, 29 January 2016 at 23:20:38 UTC, Walter Bright wrote:
On 1/29/2016 5:11 AM, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first
started using
std.algorithm I was ctrl-F'ing for "accumulate" and not
finding it quite often.
D competes with C++ directly, so do
On 1/29/2016 5:11 AM, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started using
std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite often.
D competes with C++ directly, so do consider that name :-)
For algorithms and FP in general, we may be
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu
wrote:
As has been discussed before there's been discussion about
std.algorithm.reduce taking the "wrong" order of arguments (its
definition predates UFCS). I recall the conclusion was there'd
be subtle ambiguities if we worked
On 1/29/2016 4:08 AM, Andrei Alexandrescu wrote:
As has been discussed before there's been discussion about std.algorithm.reduce
taking the "wrong" order of arguments (its definition predates UFCS). I recall
the conclusion was there'd be subtle ambiguities if we worked reduce to
implement both
On Fri, 29 Jan 2016 07:08:01 -0500, Andrei Alexandrescu wrote:
> As has been discussed before there's been discussion about
> std.algorithm.reduce taking the "wrong" order of arguments (its
> definition predates UFCS). I recall the conclusion was there'd be subtle
> ambiguities if we worked
On Fri, Jan 29, 2016 at 07:08:19PM +, deadalnix via Digitalmars-d wrote:
> On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
> >As has been discussed before there's been discussion about
> >std.algorithm.reduce taking the "wrong" order of arguments (its definition
>
On 1/29/2016 10:41 AM, Walter Bright wrote:
Note there is a foldl, foldr, and some more obscure foldt, foldi, and some
others.
foldr could be done with reverse.fold
On 01/29/2016 08:56 AM, Dragos Carp wrote:
On Friday, 29 January 2016 at 13:11:34 UTC, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started using
std.algorithm I was ctrl-F'ing for "accumulate" and not finding it
quite often. D competes with C++ directly, so do
On 1/29/2016 12:36 PM, Andrei Alexandrescu wrote:
On 01/29/2016 08:11 AM, Luís Marques wrote:
Just to bikeshed a little, I remember that when I first started using
std.algorithm I was ctrl-F'ing for "accumulate" and not finding it quite
often. D competes with C++ directly, so do consider that
On Friday, 29 January 2016 at 18:41:46 UTC, Walter Bright wrote:
Haskell can provide us with good inspiration and background for
designing 'fold':
https://wiki.haskell.org/Fold
Note there is a foldl, foldr, and some more obscure foldt,
foldi, and some others.
Once you use names like
On 01/29/2016 08:11 AM, Luís Marques wrote:
On Friday, 29 January 2016 at 12:08:01 UTC, Andrei Alexandrescu wrote:
So the next best solution is to introduce a new name such as the
popular "fold", and put them together in the documentation.
Just to bikeshed a little, I remember that when I
50 matches
Mail list logo
