Python-like slicing

[StanAngeloff]

I have just pushed a commit that implements Python-like slice literals. The syntax is similar to Python but rather than using colons (which is an assignment in CoffeeScript) it uses commas:

list: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
last: list[-1, ]    # last is now [9]

The comma at the end is mandatory to indicate a slice, rather than perform an index lookup. Slicing works on both strings and arrays and it should also work on numbers and objects implementing toString as well:

string: 'Here comes the man!'
every_other_letter: string[,,2]
puts every_other_letter    # prints 'Hr oe h a!'

I am interested to see how many of you find this useful?

There is a downside, however. The current implementation requires about 13 lines of additional JavaScript. I have tried to keep it short and this seems to be the shortest it can get. I have looked at other places in the core where we are using pre-defined functions and there are a few (__hasProp and __extends, 7 lines). In my view, it is a good trade-off between gained functionality and generated JavaScript.

[weepy]

It's certainly an often used thing. Maybe there's another syntax to avoid colloision with index lookup? E.g I don't think </code> is used much

last: list \-1\
every_other_letter: string \,,2\

[matehat]

I find this incredibly useful. I've always found list[1..list.length] to be awkward, where list[1,] is a lot more natural. If the additional function only occurs when the index brackets contains a slicing construct, then I think this is a great trade-off.

One thing: this, if accepted, should replace the other slicing construct to avoid confusion. Then, maybe, the added utility function could be just as large as it needs to be, somehow.

I think we should stick to the traditional [] operator. It's used in every language I can think of.

[weepy]

I agree it's very useful. Perhaps a better syntax would be :

string[1..2]
string[..-1]
string[-1..]

Also: is it worth the extra complexity to allow a stepwise parameter ? - it's strikes me that it's not often used.

[StanAngeloff]

weepy, I was going for this syntax when I started the patch, but since it's a complete rewrite on Array#slice, I am kind of worried about performance. I haven't tested it myself, but I imagine the native slicing would work faster. The step argument wouldn't be something you would use everyday, I agree, but it's very useful for reversing arrays:

list: ['apples', 'bananas', 'pears']
reversed: list[,,-1]

At one point I had some very basic optimisations, when step === 1 and when step === -1. In these cases it's safe to call Array#slice and Array#reverse. I may look into bringing those back and adopting the dotted syntax.

[weepy]

how about list.reverse() :D:D

[matehat]

I was just keen to know how that issue was progressing. I'd really like to see it into trunk one day.

Also, I'm wondering if the negative step could be replaced by just comparing the first and second slice argument (if the first is greater, then assumed negative walk through the list).

[StanAngeloff]

I have been using this feature on my slice2 brach for about a week. It's pretty darn nice, but I am still not sure it's core material. It would require three additional functions __slice, __splice and __range:

a: b[1..10]
  .. produces ..
a: __slice(b, 1, 10);

a[1..10]: b[1..10]
  .. produces ..
__splice(a, 1, 10, __slice(b, 1, 10));

Where __range would be called within __slice and __splice to determine the correct offsets.

So to recap, I am not sure whether it is worth patching up the slice2 branch since it may never land in the core. I am pretty happy with what I've got there at the moment.

[weepy]

good for an extension ?

[matehat]

If we get the wrapping of utility functions accepted, adding those 3 would not be a problem, I think, as simple clean functions, such as slice, splice and range. They would never appear more that once and would not be repulsive in the output.

weepy: An extension could never distinguish between its use as a variable to which something is assigned (when splicing) and when it needs its values (slicing).

[jashkenas]

Stan and I talked about this a week or so ago. It would be great to get into core, but we need a slightly different implementation that helps clean up our internals.

The fundamental issue is passing a (object, start, end, exclusive) call to determine the start and end indexes of an array slice or range. If we had this function, we could use it for slices and splices with negative indices, as well as for our range-to-array conversion, and for range comprehensions. It could shorten the code that CoffeeScript currently produces for all of those cases.

So a __range(object, start, end, exclusive) special function that returns the correct start and end indices would be a great way to get this landed, if anyone wants to take a stab.

[weepy]

How about this:

__range: (object, start, end, xclusive) ->
  L: object.length  
  start: or 0
  end: or L - 1
  start: + L if start < 0 
  end: + L if end < 0
  e: - 1 if xclusive
  [start, end]

a :[1,2,3,4,5]

__range a, 0, 3      # [0,3]
__range a, 0, -1     # [0,4]
__range a, -1, -2    # [4,3]
__range a, undefined, -2     # [0,3]
__range a, undefined, undefined     #  [0,4]
__range a, 0, 2, true     # [0,1]

[StanAngeloff]

The __range function can be extracted from the existing __slice implementation. Jeremy and I exchanged a few gists a while back and got this at the end:

function __range(array, from, to, exclusive) {
  return [
    (from < 0 ? from + array.length : from || 0),
    (to < 0 ? to + array.length : to || array.length) + (exclusive ? 0 : 1)
  ];
}

[matehat]

Here, I have a branch that contains your recent work, with the factoring out of __range from __slice and __splice, all factored out into properties of Coffeescript object.

[jashkenas]

Stan and Matehat's branches are now merged to master, but a certain amount of the work has been reverted. The Coffeescript object was removed for reasons of speed and clarity...

__slice, __splice, and __range are gone as well. As wonderful as they were for slice and splice compilation, it doesn't make any sense to have a language where you can do array[0...-1], but not array[-1]. It's just too inconsistent.

Check out the compare view to see the changes from the branches that are now on master:

http://github.com/jashkenas/coffee-script/compare/a934cf4...master

Closing the ticket.

[weepy]

Is array[4..] gone as well ?