# Slicing ideas

 Classic List Threaded
29 messages
12
Reply | Threaded
Open this post in threaded view
|

## Slicing ideas

 The fruits from a discussion on #lua with Rob Hoelz and Daniel Gruno on #lua: foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) t[1, 2, 3] = foo -> __newslice(t, foo, 1, 2, 3) Notes:         * Avoids reuse of __index and __newindex, due to stickyness           making it compatible with existing code.         * Syntax is backwards compatible with existing table           deferencing.         * __index and __newindex implementations can simply call the           slice equivalent if they want to share functionality.         * Slicing either in or out should raise a runtime error if there           isn't a suitable metamethod.         * From a different angle, a table deference is just a function           call waiting to be discovered. Anybody fancy doing a power patch to see how nice/useful/hateful it is in use? B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 2, 2012 at 11:47 AM, Rob Kendrick <[hidden email]> wrote: > foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) Just to check the intended meaning; t[1,2,3] gives you {t[1],t[2],t[3]} ? Pythonic slices use ranges, rather than explicit sequences, so the term 'slice' might be a bit confusing. (And there's others who would think that t[i,j] is 2D array access) steve d.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 12:00:10PM +0200, steve donovan wrote: > On Mon, Apr 2, 2012 at 11:47 AM, Rob Kendrick <[hidden email]> wrote: > > foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) > > Just to check the intended meaning; t[1,2,3] gives you {t[1],t[2],t[3]} ? No.  There is no intended meaning.  One could write a __slice function that did this, though. > Pythonic slices use ranges, rather than explicit sequences, so the > term 'slice' might be a bit confusing. > > (And there's others who would think that t[i,j] is 2D array access) Nothing stopping people making __slice do that, either. B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 2, 2012 at 12:09 PM, Rob Kendrick <[hidden email]> wrote: > No.  There is no intended meaning.  One could write a __slice function > that did this, though. Ah, so it's sugar for this particular global __slice - or is this meant to be a metamethod of t? steve d.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 12:15:04PM +0200, steve donovan wrote: > On Mon, Apr 2, 2012 at 12:09 PM, Rob Kendrick <[hidden email]> wrote: > > No.  There is no intended meaning.  One could write a __slice function > > that did this, though. > > Ah, so it's sugar for this particular global __slice - or is this > meant to be a metamethod of t? t[1, 2, 3] is to  __slice(t, 1, 2, 3) as t[1] is to __index(t, 1).  ie, a metamethod. B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 2, 2012 at 12:19 PM, Rob Kendrick <[hidden email]> wrote: > t[1, 2, 3] is to  __slice(t, 1, 2, 3) as t[1] is to __index(t, 1).  ie, a metamethod. Cool, now I get it.  And in the presence of __slice, does t[1] resolve to __slice(t,1)? steve d.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 12:27:53PM +0200, steve donovan wrote: > On Mon, Apr 2, 2012 at 12:19 PM, Rob Kendrick <[hidden email]> wrote: > > t[1, 2, 3] is to  __slice(t, 1, 2, 3) as t[1] is to __index(t, 1).  ie, a metamethod. > > Cool, now I get it.  And in the presence of __slice, does t[1] resolve > to __slice(t,1)? We'd not thought about it, but my initial feeling is "no", as it would require two table lookups to decide which to call, rather than one. B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 2, 2012 at 04:35, Rob Kendrick <[hidden email]> wrote: > On Mon, Apr 02, 2012 at 12:27:53PM +0200, steve donovan wrote: >> On Mon, Apr 2, 2012 at 12:19 PM, Rob Kendrick <[hidden email]> wrote: >> > t[1, 2, 3] is to  __slice(t, 1, 2, 3) as t[1] is to __index(t, 1).  ie, a metamethod. >> >> Cool, now I get it.  And in the presence of __slice, does t[1] resolve >> to __slice(t,1)? > > We'd not thought about it, but my initial feeling is "no", as it would > require two table lookups to decide which to call, rather than one. > > B. > Can we do something crazy like t['woah', {}, false] ? Personally I always thought __index and __newindex should just be able to take multiple inputs (using this syntax) and return multiple values, but apparently that requires some changes... and my first instinct seeing t[x,y] would be that it's 2D indexing, not slicing, but with metamethods you can make it work that way anyway. -- Sent from my toaster.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 04:41:10AM -0600, Rena wrote: > On Mon, Apr 2, 2012 at 04:35, Rob Kendrick <[hidden email]> wrote: > > On Mon, Apr 02, 2012 at 12:27:53PM +0200, steve donovan wrote: > >> On Mon, Apr 2, 2012 at 12:19 PM, Rob Kendrick <[hidden email]> wrote: > >> > t[1, 2, 3] is to  __slice(t, 1, 2, 3) as t[1] is to __index(t, 1).  ie, a metamethod. > >> > >> Cool, now I get it.  And in the presence of __slice, does t[1] resolve > >> to __slice(t,1)? > > > > We'd not thought about it, but my initial feeling is "no", as it would > > require two table lookups to decide which to call, rather than one. > > Can we do something crazy like t['woah', {}, false] ? Yes. > Personally I always thought __index and __newindex should just be able > to take multiple inputs (using this syntax) and return multiple > values, but apparently that requires some changes... and my first > instinct seeing t[x,y] would be that it's 2D indexing, not slicing, > but with metamethods you can make it work that way anyway. There are some issues with reusing them like this, beyond compatibility. Certainly for __newindex/__newsplice, you want things delivered in a different order to be useful.  Also, it's important for runtime errors to occur if you try to use multiple values in the dereference with code that is not expecting it, rather than silent confusion. But yes, you could make the metamethod do whatever you liked.  The choice of , was arbitary.  It could have easilly been colon.  For example, we could make these have identical syntatical meaning:         t[1, 2, 3]         t[1:2:3] meaning you could choose whichever made more logical sense. B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 In reply to this post by Rob Kendrick-2 Rob Kendrick <[hidden email]> writes: >> On Mon, Apr 2, 2012 at 11:47 AM, Rob Kendrick <[hidden email]> wrote: >> > foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) >> >> Just to check the intended meaning; t[1,2,3] gives you {t[1],t[2],t[3]} ? > > No.  There is no intended meaning.  One could write a __slice function > that did this, though. If there's no intended meaning, then the term "slice" is unnecessarily confusing/misleading. Why not just call them "__multi_index" (or "__mindex") etc; boring, but at least obvious extensions of the existing terms ("just like index, only with multiple indices"). -miles -- [|nurgle|]  ddt- demonic? so quake will have an evil kinda setting? one that             will  make every christian in the world foamm at the mouth? [iddt]      nurg, that's the goal
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 10:10:36PM +0900, Miles Bader wrote: > Rob Kendrick <[hidden email]> writes: > >> On Mon, Apr 2, 2012 at 11:47 AM, Rob Kendrick <[hidden email]> wrote: > >> > foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) > >> > >> Just to check the intended meaning; t[1,2,3] gives you {t[1],t[2],t[3]} ? > > > > No.  There is no intended meaning.  One could write a __slice function > > that did this, though. > > If there's no intended meaning, then the term "slice" is unnecessarily > confusing/misleading. > > Why not just call them "__multi_index" (or "__mindex") etc; boring, but > at least obvious extensions of the existing terms ("just like index, > only with multiple indices"). The word was selected at the beginning of the discussion on IRC, and not changed at the end.  I advocate no specific naming.  Except perhaps __plinth, because it sounds nice :) (Please don't CC me :) B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Apr 2, 2012, at 9:23 AM, Rob Kendrick wrote: > On Mon, Apr 02, 2012 at 10:10:36PM +0900, Miles Bader wrote: >> Rob Kendrick <[hidden email]> writes: >>>> On Mon, Apr 2, 2012 at 11:47 AM, Rob Kendrick <[hidden email]> wrote: >>>>> foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) >>>> >>>> Just to check the intended meaning; t[1,2,3] gives you {t[1],t[2],t[3]} ? >>> >>> No.  There is no intended meaning.  One could write a __slice function >>> that did this, though. >> >> If there's no intended meaning, then the term "slice" is unnecessarily >> confusing/misleading. >> >> Why not just call them "__multi_index" (or "__mindex") etc; boring, but >> at least obvious extensions of the existing terms ("just like index, >> only with multiple indices"). > > The word was selected at the beginning of the discussion on IRC, and not > changed at the end.  I advocate no specific naming.  Except perhaps > __plinth, because it sounds nice :) > > (Please don't CC me :) > > B. > Is the mechanism thought to be limited to exactly 3 arguments to the metamethod?  Could it be generalized to 2 or more "subscripts"? Louis Mamakos
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 09:35:58AM -0400, Louis Mamakos wrote: > > On Apr 2, 2012, at 9:23 AM, Rob Kendrick wrote: > > > On Mon, Apr 02, 2012 at 10:10:36PM +0900, Miles Bader wrote: > >> Rob Kendrick <[hidden email]> writes: > >>>> On Mon, Apr 2, 2012 at 11:47 AM, Rob Kendrick <[hidden email]> wrote: > >>>>> foo = t[1, 2, 3] -> __slice(t, 1, 2, 3) > >>>> > >>>> Just to check the intended meaning; t[1,2,3] gives you {t[1],t[2],t[3]} ? > >>> > >>> No.  There is no intended meaning.  One could write a __slice function > >>> that did this, though. > >> > >> If there's no intended meaning, then the term "slice" is unnecessarily > >> confusing/misleading. > >> > >> Why not just call them "__multi_index" (or "__mindex") etc; boring, but > >> at least obvious extensions of the existing terms ("just like index, > >> only with multiple indices"). > > > > The word was selected at the beginning of the discussion on IRC, and not > > changed at the end.  I advocate no specific naming.  Except perhaps > > __plinth, because it sounds nice :) > > > > (Please don't CC me :) > > > > B. > > > > Is the mechanism thought to be limited to exactly 3 arguments to the metamethod?  Could it be generalized to 2 or more "subscripts"? Good question.  Two options:         1. subscripts >= 2         2. subscripts ~= 1 B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 Rob Kendrick <[hidden email]> writes: > Good question.  Two options: > 1. subscripts >= 2 > 2. subscripts ~= 1 No reason not to allow zero... -miles -- Zeal, n. A certain nervous disorder afflicting the young and inexperienced.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 02, 2012 at 11:48:45PM +0900, Miles Bader wrote: > Rob Kendrick <[hidden email]> writes: > > Good question.  Two options: > > 1. subscripts >= 2 > > 2. subscripts ~= 1 > > No reason not to allow zero... Please don't CC me. In answer to your mail; this is why I'm leaning towards option 2, which allows everything that couldn't be handled by __index already.  (ie, subscripts == 1). B.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 In reply to this post by Louis Mamakos Louis Mamakos <[hidden email]> wrote: > > Is the mechanism thought to be limited to exactly 3 arguments to the > metamethod?  Could it be generalized to 2 or more "subscripts"? Another reason this is a good question is that the current metamethod implementation is tuned for overloading operators with a limited number of arguments. It's not a horrible problem because the compiler knows statically (from the syntax) when a multi-argument index is happening so it could be compiled to splice-specific byte code. Tony. -- f.anthony.n.finch  <[hidden email]>  http://dotat.at/Hebrides, Bailey: Cyclonic becoming northeast 5 to 7, occasionally gale 8. Rough. Rain or snow. Good, occasionally very poor.
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 On Mon, Apr 2, 2012 at 10:02 AM, Tony Finch <[hidden email]> wrote: > the compiler knows > statically (from the syntax) when a multi-argument index is happening what should happen on  t[unpack({1,2})]   ? note that there's no parenthesis around the unpack() call, so in theory, it could return any number of arguments -- Javier
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 In reply to this post by Tony Finch So.. Just playing with this thought experiment, what does t[f()] do? Multiret into a __slice, falling back into an __index with the first return (or nil if none) if not found? Sounds messy on the vm. Or does it truncate to one argument and just call __index? I'm not sold on the idea personally. I'd rather __index, __newindex were expanded to support multiple arguments if anything is to be done. Once you do that though, It's a bit how deep does the rabbit hole go? ie can you return multiple values from __slice? Can you assign multiple values to __newslice? ie would you want this to be able to be made to work: t[1,3] = 3,4,5 ? I bet the very thought of that would make Mike break out in hives... Alex
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 Alex Davies wrote: > I bet the very thought of that would make Mike break out in hives... I guess there's nothing new under the moon. 7.42 years ago I wrote:   http://lua-users.org/lists/lua-l/2004-11/msg00083.html  Subject: Things not to add to Lua (slices) --Mike
Reply | Threaded
Open this post in threaded view
|

## Re: Slicing ideas

 In reply to this post by Javier Guerra Giraldez Javier Guerra Giraldez <[hidden email]> wrote: > On Mon, Apr 2, 2012 at 10:02 AM, Tony Finch <[hidden email]> wrote: > > the compiler knows > > statically (from the syntax) when a multi-argument index is happening > > what should happen on  t[unpack({1,2})]   ? An excellent point. It might be possible to handle efficiently but I'm not certain. It's also rather weird that a function call in that location could lead to a different metamethod being invoked depending on the number of return values. Tony. -- f.anthony.n.finch  <[hidden email]>  http://dotat.at/Tyne, Dogger: Cyclonic, mainly east 4 or 5, becoming northeast 6 to gale 8, perhaps severe gale 9 later. Moderate becoming rough or very rough. Rain, snow later. Moderate or good, occasionally very poor later.
12