haskell-jp / random #5

( random を占領するのもアレだし、 questions とは別に「既に書いたコードを添削して頂く」ためのチャンネルがあってもいいかも、と思うなどした）

code-review を立てました

mizunashiさん、別件です、NegativeLiterals について、脱糖の仕方が変わるというのは知りませんでした、よくdocumentを読み込まんでますね、すごい！

ただ、最近たまたまGHCのLexer.xのコードを読んでたのですが、NegativeLiteralsの設定によって、シンタックスに影響（変化）が出るようです。
この拡張を使うと、マイナスの符号がついた数値リテラルを、（カッコなしでも）負数として優先的に解釈しています。

https://github.com/ghc/ghc/blob/master/compiler/parser/Lexer.x#L494

例えば、通常は、マイナス記号は、数値の符号としては解釈されないで、マイナスの演算子として字句解析されているのでこういう結果になります。

Prelude> 2 * -1
<interactive>:16:1: error:
    Precedence parsing error
        cannot mix ‘*’ [infixl 7] and prefix `-' [infixl 6] in the same infix expression

ですが、NegativeLiterals拡張を使うと、カッコでくくらなくても、`-1`のカタマリを数値リテラルとして直接、字句解析しています。

Prelude> :set -XNegativeLiterals
Prelude> 2 * -1
-2

以下も同様です。

Prelude> :{
Prelude| f (-1) = "OK"
Prelude| f _ = "NG"
Prelude| :}

Prelude> f (-1)
"OK"

Prelude> f -1

<interactive>:7:1: error:
    • Non type-variable argument in the constraint: Num (a -> [Char])
      (Use FlexibleContexts to permit this)
    • When checking the inferred type
        it :: forall a. (Eq a, Num a, Num (a -> [Char])) => a -> [Char]

Prelude> :set -XNegativeLiterals
Prelude> f -1
"OK"

と、ここまで書いて、そういう事を言ってるのではない？

Oh… シンタックス解釈に影響が出るんですね．知りませんでした… 特にUsers Guideに記載がなかったので，脱糖の仕方を @negative @decimal の時だけ変えるだけだと思ってました… Twitterの方は修正しておきます

ありがとうございます :bow:

なるほど，僕がドキュメントを読み間違えていたようですね．結果的に脱糖に違いが出るってことなんですね．

お騒がせしました

Brickって公式Twitterあったんですねｗ
https://twitter.com/brick_haskell/

あ、いえ、脱糖のことは知らなかったので、面白くてためになりました！:+1:

iruyanさん、sed での lisp 実装もあります。
https://news.ycombinator.com/item?id=10221515
https://github.com/shinh/sedlisp
（Haskellから離た話題ですが、Lispがらみということで、まぁ:sweat_smile:）

頭おかしい(笑)

syocyさんの、「A tour of Go in Haskell」、 「the most popular links from Haskell Weekly in 2017」で6th:tada:
http://taylor.fausak.me/2017/12/28/haskell-weekly-in-2017/

今年もHaskell界からの豊富で多彩な情報で楽しませてもらいました。
ではこのへんで、皆さん良いお年を、Happy Haskell:haskell::bamboo:

江添さんのブログ https://cpplover.blogspot.jp/2017/12/haskell_26.html
のGHCのエラーメッセージの話が興味深いですね。
GHC 8 になったときに型の判定の仕方が変ったんですかねぇ。Release Notes にはそれらしい記述がないように思いますが。。。

型シグネチャーがないとき、再帰的に定義する関数に対するプログラマの意図が左辺にあらわれると見なすか、右辺の使用に現れると見なすかが変更になってますよね。

なんと

なにができるのか気になってます

GUIアプリケーションを作ろうと思ったんですが、色々試した結果lts-10系(ghc-8.2系)でビルドできるライブラリがそもそもないということが分かりました(泣いた)

ビルドできるようにprだそう

@fujiyan18 has joined the channel

GUIの件、久々にGtk関係見ましたが、lts-10.xにはgtk3もgi-gtkも無いし、
extra-deps追加してgi-gtkをビルドしても、GHC 8.2.xのバグでpanic起こすし、悲惨なことになってますね…:cry:

とりあえず、lts-10.xでhaskell-giアプリを作成するための回避方法としては
https://github.com/haskell-gi/haskell-gi/wiki/Overloading#disabling-overloading
の方法で、overloadingを無効化してgi-gtkをビルドして、
こちらで記述するアプリのソースも、OverloadedLabels拡張を使わないスタイルで記述する感じですね。
※Window 7(64-bit)/lts-10.2でビルド確認済

ただ、GHCのバグが解決したら、再びOverloadedLabels拡張を使うスタイルが標準になることを思うと、
今、OverloadedLabels拡張を使わないスタイルのソースを増やすのも何だかなぁ
という感じです… :disappointed_relieved:

QtとwxWidgetのバインディングはそもそもメンテされてなくて、gtkだけが命綱という状況がそもそもつらい……

@goroii has joined the channel

あけましておめでとうございます。

GHC 8.2.xのバグ直したいですよね。たまにぶつかりますし。
今年は頑張ってpatchだしていきたいです。（新年の抱負ということで。）
https://ghc.haskell.org/trac/ghc/wiki/Newcomers

名古屋で haskell ...

私もHaskellで働いてみたくはある(˘ω˘)

GHCの数値リテラル系のsyntax highlightについて書いておきました。
https://mail.haskell.org/pipermail/haskell-cafe/2018-January/128395.html

ついでに、ほろ酔い（しらふです、仕事します）正月ポエムも。
https://qiita.com/takenobu-hs/items/dc85d455fef41c091383

Happy New Haskell! :haskell:

hirataraさん、typo情報有難うございました。 よく識別できますねすごい。

遅れましたが、みなさまあけましておめでとうございます。:clap:

@masako lee has joined the channel

reotaso [11:04 AM]
場所が違ったら申し訳ありません。


[11:05]
一生懸命書いたのでご一読頂き、何かお気付きの点やご指摘がありましたらごいっぽうください。先生方の気持ちと日本にいるHaskellerの思いを届けたく。世界中のSPJ含む先生や教授、本の著者とメッセージをやりとりしました。

それではまだまだ続きますがこちらの件、お目通し、RTのほど何卒よろしくおねがいします。

Haskell Advent Calender (その５)11日目、私が担当させて頂きました。
Samuel Gélineau からの返信その1(翻訳)

https://qiita.com/reotasosan/items/cce796d32105a5f25854 (edited)



masako lee [11:24 AM]
joined general.


kazu [1:07 PM]
企業ではなく、起業ではないでしようか？


[1:10]
IBMを買はいない の意味が分かりません。
直訳すると IBMを買って解雇された人はいない だと思います。


masako lee [1:44 PM]
@kazu 山本さんありがとうございます！早速修正させて頂きます。


masako lee [1:53 PM]
@kazu 山本さん、企業の訳ですが、companyなので一般的な企業だと思われます。
仮に起業だとしたら、startupなどの言葉を使うのかなと思います。
ただcompanyは仲間という意味もあるのでSamuelに後ほど尋ねようと思います。

IBMの件については、山本さんがご指摘くださったようにIBMを買ったからといって解雇された人はいない
プラス意訳を加えるのであれば、30-40年前は、コンピューターと言えばIBMという時代がありました。
故に新しい言語を採用するのはリスクが大きいと判断されました。
意訳は加えた良いでしょうか？

ひとまず、IBMに関しては直訳をつっこみたいとおもいます。
お忙しいところありがとうございます。 (edited)


matsubara0507 [2:24 PM]
@masako lee

Choosing Haskell is still a bold choice at the moment. For example, a friend created a startup and chose Haskell for the backend,

2. Haskellを選択することは、今でも勇気が必要です。例えば、友人が企業してHaskellをバックエンドに使いました。

この部分の「企業」のコトでは？


masako lee [2:42 PM]
ああそっちのだったんですね。大変失礼しました。すぐ修正します。

kazu [2:43 PM]
先ほど携帯から入力したので、言葉足らずでしたが、そちらです。

masako lee [2:43 PM]
かしこまりました。

[2:44]
IBMの補足についてはいかがしましょう。お手すきの際にお願いします。

[2:45]
修正しました

kazu [2:50 PM]
意訳の加筆は必要ないでしょう。原文は読者の知性を信頼しているような感じですし。:-) (edited)


masako lee [2:52 PM]
承知です。またお気付きの点がございましたらお手すきの際にご指摘お願いします。ありがとうございます。

kazu [2:58 PM]

The reason the small number of available Haskellers makes it seem like hiring is going to be difficult is that with popular languages, it is often necessary to interview a large number of candidates before finding one which is worth hiring.

[2:58]
の訳ですが、

[2:59]
Haskellerの数が少なくて採用が難しいと思わせる理由は、多くの人気のある言語では、採用する価値のある人を見つけるには、しばしばたくさんの候補者に会う必要があるからです。

[2:59]
ぐらいだと思います。

mizunashi-mana [3:10 PM]
“Haskellerの数が少ないために採用が難しいと思われてしまう理由は” ぐらいがいいのではないでしょうか？


masako lee [3:19 PM]
文言編集しました。

例えば10人のHaskellerをのなかで優秀な人を採用するのに1人だとして、
人気言語は30人のうち2人か3人という認識であってますか？

[3:19]
そのくらいHaskellerが少ないという問題

kazu [3:42 PM]
他の言語ではたくさん合わないと良い人に巡り会えないが、Haskellだとすぐ良い人に出会うと言うことをマネージャーがわかってないと言うニュアンスです。


naohaq [3:43 PM]
IBMの件、 "IBMのPCを買ったという理由でクビになった人はいない" (だからMacじゃなくてIBMにしておこう) というような観点では、Haskell は安全ではないように見える(Javaとかを選択した方が安全そうに見える) という意味を読み取るのにやや時間がかかりました^^;;


masako lee [3:45 PM]
!here
kazuさんがおしゃる「他の言語ではたくさん合わないと良い人に巡り会えないが、Haskellだとすぐ良い人に出会うと言うことをマネージャーがわかってない」と言うニュアンスです。これすごくわかりやすいです。でも前の訳の方が適してますか？


[3:46]
!here
IBMの件、 "IBMのPCを買ったという理由でクビになった人はいない" (だからMacじゃなくてIBMにしておこう) というような観点では、Haskell は安全ではないように見える(Javaとかを選択した方が安全そうに見える) という意味を読み取るのにやや時間がかかりました^^;;


これについては、私も悩みまして、それで先ほど意訳プラスの
「IBMの件については、山本さんがご指摘くださったようにIBMを買ったからといって解雇された人はいない
プラス意訳を加えるのであれば、30-40年前は、コンピューターと言えばIBMという時代がありました。
故に新しい言語を採用するのはリスクが大きいと判断されました。
意訳は加えた良いでしょうか？」を加えた方が良いか尋ねました (edited)


[3:50]
!channel
みなさま大変恐れ入りますが、これから仕事がありますので一旦スラックを閉じさせて頂きます。
夜の10時近辺にまたお伺いします。お忙しい中ほんとうにありがとうございます。失礼いたします。

@masako lee Slackにおいて「通知が来る」投稿は「受け手にとって関係が深い」投稿です。
特にhereやchannelを使う場合は、本当にそこにいる全員にとって「関係が深い」投稿かどうか注意深く考察してから利用していただきたいと思います。

(正直場所を間違えるより注意すべき事項ですね)

わたしは関係が深いとおもいました。知って欲しかったからです。

とりあえず、原則として使わない方がいいと思います。

@here , @channel ですか？

@masako lee general に書くだけで、全員がその投稿を見ることになります。僕はそれで十分だったのではないかと思っています。通知には「急かす」役割も担っているので、よく吟味して本当に必要な場面だけで使っていただけるとありがたいです。

細かいルールがわからないので
規約？に含めていただけますと幸いです

はい。ちゃんと興味がある人は未読になっていれば後で読みます。
メンションを送るときは、重要かどうかというより、緊急性が重要です。

@ 承知です

承知です

規約に含めて頂きたいのでそれはおねがいします。すいません

ほかにもあるかもしれないし

蛇足ですが、今回であれば本文を書いた他に別に切り分けでgeneralにこういう議論してるからよければここに書いてるから見てねっていう風にすると良いと思いますね:)

kazuさんが助けてくださってほんとうに嬉しかったです
みなさんのごめいわくにならないようにしますね

@
承知です。アドバイスありがとうございました

改めて作ろうかとも思いましたが、よく考えたらすでに最低限のことは書いています（もっと見やすいところに置くことは別途検討するとしても）。
@masako lee :point_down: に書いたことでは不十分ですか？
https://haskell.jp/blog/posts/2017/01-first.html

@igrep
あっとhere,channel は緊急性を要するのできほんNGとか一言加えていただけると・・・

OK, Trelloのアカウントを持っていれば、ですが続きは https://trello.com/c/zkJRAxtj/77-slack-work-pace%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%82%A8%E3%83%81%E3%82%B1%E3%83%83%E3%83%88
でいいでしょうか？

ちょっと見れないので後で確認させてください

本当にシンプルに
これはやめましょうみたいなかんじでいいんですけど・・・
初心者にはなかなかつたわりづらいかもしれません

トレロはわたしもつかったことがありますので後でみます。失礼します。