Thread overview
Compiler/Phobos/Types problem — panic level due to timing.
May 05, 2019
Russel Winder
May 05, 2019
lithium iodate
May 05, 2019
Nicholas Wilson
May 06, 2019
Russel Winder
May 06, 2019
John Colvin
May 08, 2019
Russel Winder
May 08, 2019
Alex
May 08, 2019
Russel Winder
May 09, 2019
John Colvin
May 09, 2019
Russel Winder
May 05, 2019
Hi,

I had merrily asumed I could implement nth Fibonacci number with:

    takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front

where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying:

/usr/include/dmd/phobos/std/range/package.d(5770): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are:
/usr/include/dmd/phobos/std/bigint.d(178):        std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T)
/usr/include/dmd/phobos/std/bigint.d(194):        std.bigint.BigInt.opAssign(T : BigInt)(T x)
/usr/include/dmd/phobos/std/range/package.d(5770): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are:
/usr/include/dmd/phobos/std/bigint.d(178):        std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T)
/usr/include/dmd/phobos/std/bigint.d(194):        std.bigint.BigInt.opAssign(T : BigInt)(T x)
fibonacci.d(25): Error: template instance `fibonacci.declarative.recurrence!((a, n) => a[n - 1] + a[n - 2], immutable(BigInt), immutable(BigInt))` error instantiating
/usr/include/dmd/phobos/std/range/package.d(5720): Error: template std.bigint.BigInt.opAssign cannot deduce function from argument types !()(immutable(BigInt)) immutable, candidates are:
/usr/include/dmd/phobos/std/bigint.d(178):        std.bigint.BigInt.opAssign(T)(T x) if (isIntegral!T)
/usr/include/dmd/phobos/std/bigint.d(194):        std.bigint.BigInt.opAssign(T : BigInt)(T x)
/usr/include/dmd/phobos/std/range/package.d(3177): Error: template instance `std.range.primitives.isInputRange!(Recurrence!(__lambda2, immutable(BigInt), 2LU))` error instantiating
fibonacci.d(25): Error: template std.range.drop cannot deduce function from argument types !()(Recurrence!(__lambda2, immutable(BigInt), 2LU), immutable(ulong)), candidates are:
/usr/include/dmd/phobos/std/range/package.d(3176):        std.range.drop(R)(R range, size_t n) if (isInputRange!R)

I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation?

I am close to giving up and imbibing of too much Pernod.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



May 05, 2019
On Sunday, 5 May 2019 at 18:53:08 UTC, Russel Winder wrote:
> Hi,
>
> I had merrily asumed I could implement nth Fibonacci number with:
>
>     takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front
>
> where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying:
[…]
> I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation?
>
> I am close to giving up and imbibing of too much Pernod.

`recurrence` takes the `CommonType` of the initial values and declares its internal state as an array of this type, however when at least one of the values is const or immutable, the `CommonType` is const too, or even immutable in the case when all values are immutable.
The state being const/immutable means that the following step, initializing it, can't work, since, well, the array cannot be modified (hence the errors).
I'd say this can be considered to be a bug with `recurrence`.
You can solve this issue by constructing and passing mutable versions of `one` and `zero` to `recurrence`.

May 05, 2019
On Sunday, 5 May 2019 at 19:18:47 UTC, lithium iodate wrote:
> On Sunday, 5 May 2019 at 18:53:08 UTC, Russel Winder wrote:
>> Hi,
>>
>> I had merrily asumed I could implement nth Fibonacci number with:
>>
>>     takeOne(drop(recurrence!((a, n) => a[n-1] + a[n-2])(zero, one), n)).front
>>
>> where zero and one are of type BigInt, and n is of type size_t. However both dmd and ldc2 complain saying:
> […]
>> I am now at the WTF stage – how can I show this example on Thursday in my DevoxxUK presentation?
>>
>> I am close to giving up and imbibing of too much Pernod.
>
> `recurrence` takes the `CommonType` of the initial values and declares its internal state as an array of this type, however when at least one of the values is const or immutable, the `CommonType` is const too, or even immutable in the case when all values are immutable.
> The state being const/immutable means that the following step, initializing it, can't work, since, well, the array cannot be modified (hence the errors).
> I'd say this can be considered to be a bug with `recurrence`.
> You can solve this issue by constructing and passing mutable versions of `one` and `zero` to `recurrence`.

Yep https://run.dlang.io/is/XsLrRz works for me, https://run.dlang.io/is/KxY0e9 doesn't.
May 06, 2019
On Sunday, 5 May 2019 at 19:34:05 UTC, Nicholas Wilson wrote:
> On Sunday, 5 May 2019 at 19:18:47 UTC, lithium iodate wrote:
>> [...]
>
> Yep https://run.dlang.io/is/XsLrRz works for me, https://run.dlang.io/is/KxY0e9 doesn't.

Thanks people. I now have a working code. :-)
May 06, 2019
On Monday, 6 May 2019 at 13:05:27 UTC, Russel Winder wrote:
> On Sunday, 5 May 2019 at 19:34:05 UTC, Nicholas Wilson wrote:
>> On Sunday, 5 May 2019 at 19:18:47 UTC, lithium iodate wrote:
>>> [...]
>>
>> Yep https://run.dlang.io/is/XsLrRz works for me, https://run.dlang.io/is/KxY0e9 doesn't.
>
> Thanks people. I now have a working code. :-)

pretty please show people it with UFCS:

recurrence!((a, n) => a[n-1] + a[n-2])(zero, one)
    .dropExactly(n)
    .front
May 08, 2019
On Mon, 2019-05-06 at 15:53 +0000, John Colvin via Digitalmars-d-learn wrote:
> […]
> 
> pretty please show people it with UFCS:
> 
> recurrence!((a, n) => a[n-1] + a[n-2])(zero, one)
>      .dropExactly(n)
>      .front

Any particular reason for preferring this form over the original?

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



May 08, 2019
On Wednesday, 8 May 2019 at 11:53:34 UTC, Russel Winder wrote:
> On Mon, 2019-05-06 at 15:53 +0000, John Colvin via Digitalmars-d-learn wrote:
>> […]
>> 
>> pretty please show people it with UFCS:
>> 
>> recurrence!((a, n) => a[n-1] + a[n-2])(zero, one)
>>      .dropExactly(n)
>>      .front
>
> Any particular reason for preferring this form over the original?

For example, It is more readable, as the order of execution is unwinded.
May 08, 2019
On Wed, 2019-05-08 at 11:56 +0000, Alex via Digitalmars-d-learn wrote:
> On Wednesday, 8 May 2019 at 11:53:34 UTC, Russel Winder wrote:
> > On Mon, 2019-05-06 at 15:53 +0000, John Colvin via Digitalmars-d-learn wrote:
> > > […]
> > > 
> > > pretty please show people it with UFCS:
> > > 
> > > recurrence!((a, n) => a[n-1] + a[n-2])(zero, one)
> > >      .dropExactly(n)
> > >      .front
> > 
> > Any particular reason for preferring this form over the original?
> 
> For example, It is more readable, as the order of execution is unwinded.

I think there is an individual element to this, and what people are used to. However I have taken John's request and changed the line he wanted changed.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk



May 09, 2019
On Wednesday, 8 May 2019 at 11:53:34 UTC, Russel Winder wrote:
> On Mon, 2019-05-06 at 15:53 +0000, John Colvin via Digitalmars-d-learn wrote:
>> […]
>> 
>> pretty please show people it with UFCS:
>> 
>> recurrence!((a, n) => a[n-1] + a[n-2])(zero, one)
>>      .dropExactly(n)
>>      .front
>
> Any particular reason for preferring this form over the original?

Not big benefit in this case, very big benefit with longer chains.

It reads in the order of operations, as opposed to inside out.
May 09, 2019
On Thu, 2019-05-09 at 08:33 +0000, John Colvin via Digitalmars-d-learn wrote:
> […]
> 
> Not big benefit in this case, very big benefit with longer chains.
> 
> It reads in the order of operations, as opposed to inside out.

John,

Coming from a Haskell/Lisp background to declarative expression, I do not have a problem with the function application approach. However if the audience are more likely to understand the method application approach (and this is fundamentally a Java audience) then that is the way of should be shown.

I showed the variant you suggested. :-)

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk