"lineAtOffset"?

[Richard Gaskin]

Ben Rubinstein wrote:

> On 29/10/2015 15:47, Richard Gaskin wrote:
>
>> Like "lineOffset", "lineAtOffset" would take the same arguments and
>> operate similarly, but rather than returning the number of the matching
>> line it would return the text of that line.
...
> Of course this could be useful occasionally - but I'm not sure the value
> outweighs the cost - not so much the cost of implementation, as the cost of
> adding more words to the language.
>
> In code, it saves a single line.
>
> In efficiency, I grant there's a cost; but it seems to me that if the cost was
> high (i.e. you're searching in a really long piece of text, and you're doing
> it a very large number of times) then you could choose to mitigate that cost
> in various ways (e.g. doing split to get an array indexed by line number, or
> (depending on your situation) doing "offset" instead of line offset, and then
> taking a chunk starting sufficiently before the found character position and
> doing "lineoffset" on that...

True, we have alternatives.  I guess it boils down to how important we 
feel chunk expressions are as a defining part of the language.

Array splits are convenient and an excellent choice if you anticipate 
needing to extract values often.  But for a one-time lookup, the 
overhead of split can outweigh the cost of lineoffset + getting the line 
text.

I've been using character offsets for some cases as you describe, and 
since offset deals with fixed-size characters it's faster than any other 
chunk expression that needs to parse by delimiters.  But at that point 
the logic of my code starts to resemble how I'd do things in JavaScript 
or other common languages, fine for me but not the celebration of chunk 
expressions I find resonates with newcomers when I'm teaching the language.


> But mainly, I'm agin this proposal because, if there were to be changes to the
> offset suite of functions, I'd much rather that effort was spent on making
> them work backwards. It's fast and simple to do offset, lineoffset, etc to
> find the first occurrence of a fragment, or to walk 'forward' through the
> occurrences of a fragment; but it's neither fast nor simple to get the last
> occurrence, or to walk backwards through the occurences.
>
> There's an inconsistency here - LC makes it as easy to ask for the last item,
> or the third line from the end, as it does the first item, or the third line.
>   But the *offset functions only work in one direction.
>
> Also note that implementing the backwards offsets needn't (I think) require
> adding any new keywords, because we can use the skip parameter with a negative
> number.

I don't see the two as mutually exclusive.  Isn't there a request for 
backwards offset in the RQCC?


> Sorry to hijack your thread!

Not at all.  My tastes and preferences are only my own, so it's helpful 
to get feedback from others.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com