> I am really happy with the x..y//z I just played around with this and agree, it is much nicer than x..y..z,!
On Wednesday, March 24, 2021 at 2:55:16 AM UTC-7 José Valim wrote: > I have sent a PR with an implementation of the proposal: > https://github.com/elixir-lang/elixir/pull/10810 > > Some notes so far: > > * I am really happy with the x..y//z (I am aware I am biased :D). Going > for different separators between limits and steps was a great call. > first..last is the mathematical notation and first..last//step feels like a > natural extension > > * This pull request also allows us to add interesting new features to both > Enum.slice/String.slice, such as slicing in steps or even > reversing+slicing. However, I am not exploring those features right now. > > > On Tue, Mar 23, 2021 at 7:26 AM José Valim <jose....@dashbit.co> wrote: > >> > The path to supporting it in range *literals* with special rules for >> guard, match, and normal contexts seems a little rough, but I can't think >> of a better way than what's been proposed so far. >> >> To be clear, that's already how it works today. We have special rules for >> these contexts. The only addition is that we will deprecate x..y in match. >> >> > This feels like we're hacking around the lack of a notion of >> inclusivity/exclusivity; have we considered syntax around that instead >> of/as well as step notation? >> >> I have commented on this earlier. My comment was: "You could frame the >> issue as open/closed ranges but, given our ranges are exclusive to >> integers, the general consensus is to treat integer ranges as closed >> because you can flip between them using +1 and -1 (the a..b notation is >> also used in math). So I would prefer to approach the problem using steps, >> because it is strictly more expressive." I would also add that languages >> like Julia and Matlab also have inclusive ranges with steps. >> >> Inclusivity/exclusivity was actually the first idea I explored, >> especially coming from Ruby, but no dice . :) The other issue with >> inclusivity and exclusivity is that we can't make it work in guards. We >> have two options: >> >> * Store the exclusivity as a field in the range - but how are we going to >> remind users implementing range_to_list to check this field? >> >> * Keep ranges as is and normalize the boundary when creating the range - >> this means you can't use x,.y in match, because we can't have a x-n,.y in >> matches, where the value of n depends on the direction of the range >> >> So inclusivity/exclusivity solves only part of the problems originally >> listed. >> >> >> On Tue, Mar 23, 2021 at 1:31 AM Christopher Keele <christ...@gmail.com> >> wrote: >> >>> I like the idea of supporting steps in ranges in general! The path to >>> supporting it in range *literals* with special rules for guard, match, >>> and normal contexts seems a little rough, but I can't think of a better way >>> than what's been proposed so far. >>> >>> x..y//z seems like a reasonable syntax to me. *"One nice bonus about >>> 1..9//2 is because we can actually think that it is cutting the number of >>> elements in 2, by some approximation"* — agreed, is has a nice >>> divisible/modulo feel to it. >>> >>> ———————— >>> >>> I know that doing this work just to interpret x..y when x > y as an >>> empty range is not the only motivator of this proposal, but a contributing >>> factor. This is specifically for the bounds-checking errors in the common >>> scenario x..y when is_literal(x) and is_variable(y), right? >>> Specifically: >>> >>> for i <- 1..n, do: # zero times when n = 0 >>> >>> This feels like we're hacking around the lack of a notion of >>> inclusivity/exclusivity; have we considered syntax around that instead >>> of/as well as step notation? >>> >>> For example, using a comma "," to indicate an exclusive (rather the >>> inclusive ".") boundary of a range. In the common case above, it seems >>> like we could more accurately model the programmer's real intent: defining >>> a dynamic zero-exclusive range; ex: >>> >>> for i <- 0,.n, do: # zero times when n = 0 >>> >>> I believe we could still make this syntax work with all the >>> compile-time, pattern-matching, and guard-expressivity that ranges have >>> today. >>> >>> 0,.0 -> [] >>> 0,.1 -> [1] >>> 2.,4 -> [2, 3] >>> 2,,4 -> [3] >>> >>> Not to derail the step discussion—but it does seem like on-topic insofar >>> as the motivations of the step feature is concerned? >>> On Monday, March 22, 2021 at 9:46:16 AM UTC-7 José Valim wrote: >>> >>>> The proposal has been updated in the gist >>>> <https://gist.github.com/josevalim/da8f1630e5f515dc2b05aefdc5d01af7> >>>> for: x..y//z. >>>> >>>> >>>>> Since we're bike shedding on the syntax, I would throw my hat into the >>>>> ring for >>>>> 1..10:2 >>>>> >>>> >>>> It was commented before but the syntax above is ambiguous due to the >>>> use of atoms and keywords, for example: x..y:z. >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elixir-lang-core" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to elixir-lang-co...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/elixir-lang-core/f6221657-7bd7-4f77-9917-157da64d7509n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/elixir-lang-core/f6221657-7bd7-4f77-9917-157da64d7509n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/67e6ee92-2751-4910-90eb-104de908698bn%40googlegroups.com.
