http://qs321.pair.com?node_id=11133556


in reply to Re: [Raku] Ranges in array slices
in thread [Raku] Ranges in array slices

Thanks tomasz, and a belated welcome to the Monastery!

The sequence operator looks really powerful: my attention was particularly caught by this example from the documentation:

This allows you to write
say 1, 1, * + * ...^ *>= 100;
# OUTPUT: «(1 1 2 3 5 8 13 21 34 55 89)␤»
to generate all Fibonacci numbers up to but excluding 100.

Of course, now that I have an operator that works the way I expected the range operator to work, I’m wondering: why would I ever need the range operator?

Cheers,

Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

Replies are listed 'Best First'.
Re^3: [Raku] Ranges in array slices
by holli (Abbot) on Jun 05, 2021 at 19:14 UTC
    Functionally you can express all Ranges as Sequences, albeit that'd be slower methinks. What you're asking is a bit like asking why we need multiplication if we can just keep adding.

    Check out the documentation. Range, just like List does Positional and Iterable roles. Seq only does Iterable and implements the indexing (AT-POS method et. al) itself, specifically a Seq always has to calculate all n-1 elements before you can access the n-th element.


    holli

    You can lead your users to water, but alas, you cannot drown them.
Re^3: [Raku] Ranges in array slices
by tomasz (Acolyte) on Jun 05, 2021 at 16:11 UTC
    Hi there!

    I'm not so sure, to be honest. I'm still very fresh with Raku.

    From what I've gathered so far, you'll take range when you just need two ends of a stick, and sequence, when you need the stick.

    EDIT:
    Sequence can also be characterised by the accented stickiness of the stick, to continue this sticky metaphor. It's accented even over the idea of its end, to the effect that if an end of the stick doesn't meet the stickiness, then it's ignored. Example:
    0, * + 2 ... 1
    See, where it goes?

    I wonder if it's grammatically possible to jump over both ends this way... (sic!)1

    1) ...like this...
      I'm not sure what you're trying to say. This sequence (of even numbers) however will never end.

      0,  * + 2  ... 1

      If that's what you want to say, then it better be written as

      0, 2 ... * or
      0, 2 ... Inf


      holli

      You can lead your users to water, but alas, you cannot drown them.
        To make sure, we're on the same page, the sequence of even numbers can end:
        > say 0, * + 2 ... $_ for 2, 10 (0 2) (0 2 4 6 8 10)
        And if this was obvious, then - yes, that's the point. Sequences allow this kind of dissonances. No error is reported by the language. There's space for absurd. Or what should this be better called?
        I think we all agree here on what's what and there's no point to argue about. I'll however continue my line of thinking just as a lighthearted musing.

        It's a language feature and so if there is an error, it will be a semantic error. Or possibly not, as this feature can be productively exploited.

        For example, let's take a hard to calculate number N and use it as the last element condition. And for the generator function let's use a G, and some S for the starting point. Here' the formula:
        S, G ... N
        So we're testing N against G for S. As the test duration can explode towards infinity, we need to limit the number of steps or the time of our test. Let's name this limitation "<<< L" in pseudocode:
        S, G ... N <<< L
        If the test doesn't end before L, we could consider this a proof of absurdity (or semantic errorness) of "S, G ... N" relative to L. And isn't this absurdity similar to infinity of N? Couldn't we say N is infinite relative to S, G, L?

        EDIT: This would be valid for easily computable Ns also. We could say: 1 is infinite relative to 0, * + 2, any L.