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

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

[download]
See, where it goes?

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

1) ...like this...

Replies are listed 'Best First'.
Re^4: [Raku] Ranges in array slices
by holli (Abbot) on Jun 05, 2021 at 19:20 UTC
    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.
[reply]
[d/l]
[select]
      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)

      [download]
      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?
[reply]
[d/l]
        I see no dissonance or absurdity here. The code creates two Sequences in a loop and they end because the end conditions (2 and 10) (the thing to the right of ....) get reached.
        If you create a sequence like 0, * + 2 ... 1 where the values go up and the end value is smaller than even the first calculated value, then that Seq. will can never end.


        holli

        You can lead your users to water, but alas, you cannot drown them.
[reply]
[d/l]
[select]
[reply]
      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

      [download]
      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

      [download]
      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.
[reply]
[d/l]
[select]
        If that is absurd then

        while N <<< L: 
  G = G of S

        [download]

        is absurd too. The right hand side of ... is just a condition, nothing more. If you're saying that things get absurd when the condition is so expensive that it dwarfs the loop body, then yeah. But then your code is bad, not the semantics of the language.

        I might be still be missing the point, though.


        holli

        You can lead your users to water, but alas, you cannot drown them.
[reply]
[d/l]

In Section Seekers of Perl Wisdom