Re: fn:slice()

> If we're going to have a modifier argument that changes the behaviour then it should be a map, not a string, to make it extensible. But even then, I don't like having a modifier argument that changes the essence of what the function does quite so fundamentally.

I also regarded fn:slice to be a filter expression (as it returns
items of a sequence that match certain conditions). But I see your

I think it’s too much of a commitment to introduce four separate
functions that do pretty much the same. Maybe it’s sufficient in most
cases to use the new fn:index-where function:

  let $s := 1 to 10
  let $i := index-where($s, function($i) { $i = 5 }) => head()
  return (
    subsequence($s, 1, $i - 1) (: items-before :),
    subsequence($s, 1, $i) (: items-until :),
    subsequence($s, $i) (: items-from :),
    subsequence($s, $i + 1) (: items-after :)
    subsequence($s, $i, 1) (: item-at :)

It’s surely not as compact as it could be. On the other hand,
returning subsequences based on a functional predicate is not
something that’s done all the time.

Looking at other contexts may help. In many JavaScript applications,
90% of array processing is done via map, filter and indexOf (or, more
recently, find/findIndex), and it seems to work pretty fine. Dedicated
functions for processing subsequences before/after a specific index
might be nice additions, but I wouldn’t necessarily expect them as
language core functions.

Received on Saturday, 5 December 2020 09:35:07 UTC