> 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 <christheke...@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-core+unsubscr...@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/CAGnRm4JpAbidM%2BScu8UeDVUpmdwFbaPZuv%2BZz_WZCW4g2SCPow%40mail.gmail.com.
