問題タブ [either]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
scala - scoobi concatenate DListsの問題
次の構造の scala scoobiコード (今のところローカルで実行) があります。
また、processSource は次のようなオブジェクトです。
さて、私の問題は、getRidOfRight が返すべき出力の一部しか返さないことです。なぜ?
scala - Scala ライブラリが動的バインディングを避けるのはなぜですか?
私がライブラリを書いていたら、私は習慣的に Option を次のように書いていました:
map
実装にポリモーフィズムを使用していることに注意してください。ただし、 map の実際の実装は完全に Option クラスにあり、次のようになります。
私の実装はよりクリーンで (ポリモーフィズムの利点を参照してください)、おそらくより高速であると主張します。同様のケースではなく、Either
型の一致が使用されます。C の人々が Java に来るときに使用するステートメントを思い出します。興味深いことに、類似の実装は私の OOP 流派に従っています。したがって、より短いソリューションが で選択されたと思います。他の理由はありますか?if
switch
Try
Option
haskell - Haskell初心者は期待される型と一致しません
I または O のいずれかである 4 つの値のリストを のリストにデコードするプログラムを作成する必要があります[Either Bool Bool]
。おそらく使用する必要があることはわかっていますが、頭を包むことはできません。私はこの問題を解決することができないので、今、私は完全に絶望的です.
入力と出力の例は次のようになります: [I,O,O,I] => [Left True, Right False]
ここに私が持っている現在のコードがあります:
これらは私が得るエラーです:
現在、この問題を解決するのに役立つものは何でも大歓迎です。私は一日の大部分でこれを試しましたが、単に解決できません。
functional-programming - リストの内容に応じて、どちらかのリストを Left または Right にする慣用的な Scala の方法
どちらかのリストがあります
その結果Right
、リスト内のすべてが if である場合、Right
else が必要ですLeft
。これは、リストにバイアスをかける必要があるように思えます (Try
代わりに使用するなど) が、そうではない、またはすべきではないと仮定しましょう。
結果のRight
orの内容Left
は常に同じです (例: 文字列、以下を参照) - コンテナのみが異なります。たとえば、上記のリストでは、このリストから文字列を作成したいので、結果はLeft
likeになりLeft("Right(5) -> Left(abc) -> Right(42)")
ます。Right(12)
の代わりに別のものがある場合は、Left("abc")
になりますRight("Right(5) -> Right(12) -> Right(42)")
。
Left
リストに少なくとも 1 つあるかどうかを手動で確認し、結果として aLeft
または aを作成する if で分岐することもできますRight
が、もっと Scala に似た方法はないのでしょうか?
exception-handling - Clojureで純粋にエラーを処理しますか?
私はビッグバン スタイルのプログラミングを使用してゲームに取り組んでおり、状態全体を単一のデータ構造として定義し、単一のアトムに対してスワップすることで状態の変化を管理しています。
ゲームでは、クライアントから送信されたデータを信頼できないため、サーバーはいくつかの動きが無効になる可能性を予測して、それを防ぐ必要があります。世界の状態を交換するための関数を書くとき、純粋な状態から始めることができます。ただし、無効なリクエストの可能性を考慮する必要があります。私は、慣用的な Clojure の不幸な道に影響を与えるのは、単純に例外をスローすることだと信じています。そのため、純粋だった可能性のある関数が副作用の例外に感染しています。おそらく、これはあるべき姿です。
私の目標は、可能な限り最後の瞬間まで副作用を延期することです. 私は Haskell の世界に足を踏み入れたことはほとんどありませんが、Either モナドの概念は知っています。幸福な道と不幸な道を考えると、常にこの 2 つの可能性があることがわかります。swap!
不幸な道を無視しているので、これだけでは不十分だと思います。アイデアの精神は次のとおりです。
Clojure コミュニティは、例外を処理するためのより機能的なアプローチを採用しましたか?