Add API: sliding and slidingSizeStep
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 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 の本文から書いたものです。
説明
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:
- whether the returned value is
Array _orMaybe (NonEmptyArray _) - 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時間
- マージ済み PR（30日）
- 1
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
purescript/purescript-arrays のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 55/100
purescript/purescript-arrays#246 ·
-
generate functionオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 35/100
purescript/purescript-arrays#244 · コメント 2 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
purescript/purescript-arrays#242 · コメント 2 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
purescript/purescript-arrays#241 ·
-
`groupBy` has unexpected `l` argument for `a -> a -> Boolean` predicate再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 25/100
purescript/purescript-arrays#229 · コメント 3 件 ·
purescript/purescript-arrays の issue をすべて見る
似ている issue
-
ManageSieve proxy: a backend's NO/BYE greeting is skipped as a capability line and reported as EOFオープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
Mend: dependency security vulnerability
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
ManageIQ/manageiq-pods#1476 ·
メンテナーはふだん 1 日以内に返信
-
mcp: typed tool handlers lose wrapped JSON-RPC errors再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
modelcontextprotocol/go-sdk#1529 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
FinanceFlash/unvibecode#818 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100