"lineAtOffset"?

[Mark Waddingham]

On 2015-10-29 18:11, Ben Rubinstein wrote:
> 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.

That's the problem if you use functional forms. In an English-like 
setting though that concern goes:

   <chunk>Offset() => the <chunk> offset of x [ after y ] in z

It is the camel-casing which causes keyword explosion (synonyms aren't 
really a problem when you don't have to camel-case things).

> 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.

Indeed - this is true. We've experimented with English-like syntax for 
this in LCB:

    the [ first | last ] index of x [ ( before | after ) y ] in z

> 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 think that might work for the offset() functions - I shall ponder... 
The resulting value would probably have to be negative as well - since 
offset() and friends return the delta between the starting index and the 
found index (which I'm not sure is actually as useful as absolute 
offsets).

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps