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 <[email protected]> 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 <[email protected]> > 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4J3JA74xpZ2DN67991PBC1E4wBpJR-kP3C5N1E8gED8zA%40mail.gmail.com.
