Add API: sliding and slidingSizeStep

未关闭
  • 哪里不对？
#214 4 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
20/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
停滞
领域
api

调研方向

Read the linked context in issue #212 and the discussion here to understand the proposed API alternatives. The issue asks for a decision on return types and proposes four sliding functions, but does not specify implementation locations, tests, or settled behavior. Done would require agreeing on the API and defining its behavior before implementation.

由索引模型根据 Issue 内容生成。

描述

status: needs more info

Backlinking to #212 for more context. The question here is whether to add sliding, a function that returns windows of the array, and what its type signature should be. A variation of sliding is slidingSizeStep which allows one to control the size of the window and how far to step before creating a new window. We'll cover this function later in this issue.

Starting with sliding, the core question is what the return type should be. Below, I'll refer to various ideas for implementations using _N where N refers to the possible way forward.

-- as proposed in #212
_1 :: forall a. Array a -> Array (Tuple a a)

_2 :: forall a. Array a -> Array { previous :: Maybe a, current :: a, next :: Maybe a }

_3 :: forall a b. Array a -> (Tuple a a -> b) -> Array b

_1 is what is proposed in #212. _2 is what Harry proposed in his comment, functioning more like a Zipper. _3 is something I am proposing for unifying the other two. For example, if we implemented _1 and _3 in this library, _2 could still easily be implemented via (Tuple l r) -> {previous: Nothing, current: l, next: Just r}.

Since _2's zipper-like type might want additional features (e.g. a Functor instance) that is largely outside the scope of this project, I propose not implementing it as end-users can implement it and define their own Window type. Moreover, _3 enables more potential use cases we cannot imagine right now (e.g. slidingF ((Tuple l r) -> l + r) [0, 1, 2, 3] would produce [1, 3, 5]), simulating a scanl like feature.

Let's move on to slidingSizeStep. If we ignore the size and step arguments in the function, the question arises again as to what the return type should be. Here's two factors that come to mind:

  1. whether the returned value is Array _ or Maybe (NonEmptyArray _)
  2. whether the returned value is the complete subcollection or a zipper-like value
-- as proposed in #212
_11 :: forall a. Array a -> Array (NonEmptyArray a)

_12 :: forall a. Array a -> Maybe (NonEmptyArray (NonEmptyArray a))

_13 :: forall a. Array a -> Array { before :: List a, current :: a, after :: List a }

_14 :: forall a b. Array a -> (NonEmptyArray a -> b) -> Array b

I believe _11 is to be preferred over _12 because one can still get Foldable1 and friends without having to pay for the Just constructor unwrapping in _12 by doing something like this:

case NEA.fromArray $ slidingSizeStep [0, 1, 2, 3] of
  Nothing -> -- returned array is empty
  Just nea -> fold1 nea -- returned array is non-empty

_13 provides the same zipper-like idea. However, it cannot be implemented because arrays does not depend on lists. Working similar to sliding, _4 provides an escape hatch to this problem. One could use _4 in combination with my own arrays-zipper to get an Array-based zipper or use pointed-list to get a List-based zipper.

In conclusion, I propose we implement these four functions:

sliding :: forall a. Array a -> Array (Tuple a a)
sliding = slidingF identity

slidingF :: forall a b. (Tuple a a -> b) -> Array a -> Array b
slidingF = ...

slidingSizeStep :: forall a. Int -> Int -> Array a -> Array (NonEmptyArray a)
slidingSizeStep size step = slidingSizeStepF size step identity

slidingSizeStepF :: forall a b. Int -> Int -> (NonEmptyArray a -> b) -> Array a -> Array b 
slidingSizeStepF size step f arr = ...

I'm not yet considering rangeWithStep that was also proposed in #212 because I want to first cover these two functions and their variations.

主要语言
PureScript
星标
58
派生
70
平均合并
2 天 22 小时
30 天内合并 PR
1

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 有 Pull Request 模板
  • 没有贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

purescript/purescript-arrays 的其他 Issue

查看 purescript/purescript-arrays 的全部 Issue

相似的 Issue

更多 Backend & API Design Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。