Comments on: SELECT/SKIP bug or feature?

In R2, if you use select with /skip, it returns a block:

data: [a 10 "bob" b 20 "ted" c 30 "sam"]
select/skip data 'b 3
[20 "ted"]

That can be useful at times - because you get the remaining contents of the "implied" record.

However, in R3:

select/skip data 'b 3
20

which is consistent with the definition of select, but not with R2 behavior.

Comments?

12 Comments

Comments:

Henrik 29-Apr-2009 12:52:39	First I'd ask whether there are other equally simple ways to achieve the R2 behavior, before changing R3. The R3 result may be consistent, but the R2 result is very useful.
Maarten 29-Apr-2009 13:01:20	1 - see Henrik 2 - I'd like to have a select/deep refinement for nested blocks. 3 - /deep in other places. reduce/deep Why is compose the only "lucky" one?
Shadwolf 29-Apr-2009 13:05:40	I'm a simple guy so select/skip 'b 3 I understand it like this. Locate b in my block return me the items you found and from the third item stop your work. That ca be resumed as locate 'b in my block and return me the 2 next items. I don't get the meaning of select 'b 3 in R3 returning only 1 item since we say skip from the 3rd items...
Brian Hawley 29-Apr-2009 13:13:23	This sounds like a job for slice! (see recent discussions in R3 chat for details). A slice! would be a subseries reference to the series. It might be a problem for multitasking though; generating a copy might be better. Overall, I have to say that I prefer the R2 behavior. It generates a copy of the record - the series can be protected and you can still change the data you get. Bugs 686 and 730 are related to this.
-pekr- 29-Apr-2009 15:23:54	R3 behaviour is correct, although not much useful. OTOH - if we want forskip behaviour, in R2 we used /skip. Because skip is also a regular function name, I think it was not lucky refinement name selection. I have no clear opinion on that ... If you "do select skip data 3 'b" in R2, you get the same result as in R3.
Gregg Irwin 29-Apr-2009 17:34:54	Is there a good reason to change the behavior?
Brian Hawley 29-Apr-2009 17:52:09	One thing we need to discuss right away is /skip lengths of less than 1. We need to decide, system-wide, whether /skip < 1 should generate an error, like DIFFERENCE/skip, or whether it should be treated as if /skip 1 was specified without error, like MOVE/skip. All other functions that take /skip hang when < 1, or behave unpredictably. I have been a fan of the /skip < 1 being treated as /skip 1, because otherwise you would need to wrap every call to function/skip in error-handling code unless you perform data flow analysis. This would speed up correct code. The alternative would be to have it generate an error, and then let that error be a debugging tool. Or trip during runtime. Either way it could prevent potential data corruption, and if tested ahead of time it would aid in that data flow analysis. Which should we choose? Consistency is king here. We have many functions to fix.
Brian Hawley 29-Apr-2009 17:55:46	Gregg, change from what? Do you mean change SELECT/skip from the R2 behavior, or change R3 to go back to the R2 behavior? R3 has already changed by accident. The question is whether to change it back to be compatible with R2. The answer to that question is another question: Which behavior is better?
Ingo Hohmann 30-Apr-2009 4:54:33	I understand the 'skip refinement like: "treat the series as consisting of virtual records" so for me it makes sense to return the remainder of the virtual record here. So far I haven't had any problem with the 'skip value being < 1. To me it sounds like a coding error, so raising an error would be the correct action. But I don't have strong opinion on this.
Anton Rolls 30-Apr-2009 13:27:12	I found "select/skip" only once in all my code, and it was in a commented section! But I think I prefer the R3 behaviour, where it returns only a single value. IIRC I was a bit surprised, in R2, for /skip to return a block.
Gregg Irwin 6-May-2009 14:21:52	Carl, why did you design it that way? And why would you change it now? Not saying you shouldn't, but what do you see differently, after using it all these years. While it seems like "/skip 2" would be implicit, in terms of common key-value pairs, the design works well for many other uses. When you do need the very common "/skip 2" behavior, it's more of a pain. I imagine I'm not alone in not using /skip in many of these cases, relying, instead, on not having a value that may also be a key. That's a bit risky, but it looks so much cleaner. :) The R3 behavior solves that problem, but creates a problem for skip sizes other than 2. Since /skip is designed for records of any size–and since it changed by accident–I would go back to R2's behavior and add something that makes it easy to treat a series as key-value pairs for lookups.
Brian Hawley 6-May-2009 15:59:37	Gregg: add something that makes it easy to treat a series as key-value pairs for lookups. Like the map! type, for instance.

Post a Comment:

You can post a comment here. Keep it on-topic.