Slicing ideas

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

Slicing ideas

Rob Kendrick-2
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

steve donovan
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

Rob Kendrick-2
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

steve donovan
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

Rob Kendrick-2
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

steve donovan
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

Rob Kendrick-2
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

Rena
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

Rob Kendrick-2
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

Miles Bader-2
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

Rob Kendrick-2
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

Louis Mamakos

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

Rob Kendrick-2
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

Miles Bader-2
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

Rob Kendrick-2
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

Tony Finch
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

Javier Guerra Giraldez
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

Alex Davies
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

Mike Pall-38
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

Tony Finch
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