Skip to content

第2章の疑問 #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kdnk opened this issue Jan 22, 2019 · 1 comment
Open

第2章の疑問 #1

kdnk opened this issue Jan 22, 2019 · 1 comment

Comments

@kdnk
Copy link
Owner

kdnk commented Jan 22, 2019

疑問におもったこと

  • 宣言的プログラミングモデル
    • 部分データ構造 partial data structure の上で関数を計算すること

2.2.6 部分値 partial value

  • 束縛されていない変数を含んでいるかもしれないデータ構造 == 部分値(partial value)

  • 手続き値(閉包)

    • 自由識別子 by p.59
    • 「自由識別子は仮引数のこともあり」????
      • 仮引数って時点で定義されてるんじゃないの?自由識別子は定義されていない識別子のことなはず。
    • p.67 上部の言っていることがちゃんと理解できていない気がする...????

2.3.1 構文

  • レコードとパターンにおいて、その引数 x_1 … x_n はすべてことなるものでなければならない
  • それにより、すべての「変数の、変数への束縛」が明示的な核言語操作としてかけることが保証される(7)

2.4.5 基本概念再訪

  • 変数識別子と静的スコープ
    • なぜここで、{ y=1, x=y } みたいなことをしている????
  • 手続き定義と宣言
    • なんで Proc の CE は ずっと Φ???? 外部参照がないから? → 多分そう。Proc の仮引数に必要なものが揃っているので、Proc 自身は環境をもっていない。

2.5.1 末尾呼び出し最適化

  • なぜ、この大きくなり方が問題にならないのか
    • 本当に必要なのは、1 つの変数だけ。それ以外は格納域にある必要はない。
    • 「この例の場合、変数を格納域でなくスタックに格納すれば問題は解決できる」なんで????
    • 「スタックに用意に格納できないようなデータを大量に持っている」どんな????
    • なので、不要な変数を削除するという問題は解決しないといけないらしい

2.5.4 ガーベッジコレクションは黒魔術ではない

  • メモリリークを避けること
    • 必要がなくなったデータ構造を参照しないようにしなければならない
    • 「宣言的モデルでこの掃除をできないことはないが厄介である」????
    • 外部資源が Mozart データ構造を必要とする場合????

2.6.3 対話的インタフェース(declare 文)

  • 「前の declare と違うのは、が(declare を含んでいなければ)大域的変数を宣言しないことである」????

2.7.2 例外を持つ宣言的モデル

  • catch 文は意味スタック上の「マーカー」????
  • catch
    • 「catch 文は skip 文同様、何もしない」????
@kdnk
Copy link
Owner Author

kdnk commented Jan 22, 2019

勉強会中のメモ

  • 終端記号と非終端記号
    • tree で書いたときに最後かどうか
    • 文法は2階層
      • 実際に字句として現れるか抽象的なものか
  • 文脈自由文法と文脈依存文法
    • 表現力が階層によって違っている
      • チョムスキー階層
        • プログラミングに限らない言語の階層
        • c++のパースが遅いのは、文法規則が複雑だから
      • 文法を考えるとき、EBNFは明らからにわかりやすい
      • これで定義してから、制約を追加したほうがわかりやすい
        • こういうふうに考えると、実行時エラーが起こることも理解できる。
      • 実行時にチェックされることもある
        • どこまでが文法なのかは言語によって異なる
        • この言語は実行まで含めている?
        • コンパイルのフェーズと実行のフェーズは分かれている
        • ex 使っていない変数を使っていても、コンパイルは通るけど、実行時にエラーになる。
  • 言語の意味
    • 数学的 → この前の形式的とかの議論と同じ。厳密に、論理的に定義されている。
      • ruby は数学的に定義されていない。MRI
    • 意味論
      • 計算するということはこういうことという定義
      • sqlは操作的意味論ではない。
        • 関係論理。論理的意味。
          • どうやってjoinするに関しては言及しない。join とはこういうことであると示すだけ。
      • 計算というものがどういう操作をすることなのかを定義することができれば、操作的意味論であると言える?ruby は最初の処理系が神様
      • 仕様と実装を切り離すのが大切
  • 単一代入格納域
    • この本だと部分データ構造 は 部分値のこと
      • 関数型と論理型
        • 関数を一般化したのが論理的
          • 関数をもうちょっと一般化したので宣言的ととりあえず読んでいる
    • 言語抽象と糖衣構文
      • エンジニアには、手続きと関数は違うものと認識されている → 言語抽象
      • 言語を拡張する方法は2つある
      • 創造的拡張原則
        • 言語抽象と糖衣構文
        • 核言語を拡張すること
      • 便利機能 → 糖衣構文
    • 意味言明 semantic statement
    • 環境と格納域
      • 環境: ラベルからデータの写像
        • その場ごとに違う
      • 格納域
        • グローバルに1つ
  • 入れ子マーカ
  • 関数と手続き
    • 中の処理に興味がある → 手続き
    • 返り値に興味がある → 関数

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant