Closed17

プログラミング言語 Ches

がーねっとがーねっと

プログラミング言語 Ches

概要

Ches に関するアイデア / 意見 / 知見などをまとめる場所

質問, 意見, 感想など

公式 Twitter @Ches_lang にメンション & ツイートをお願いします
(例)「Ches に~~のような機能はありますか? @Ches_lang

ツイートに気づき次第返信します

どなたからでも、ごく小さなことでも大歓迎です

特徴

  • 初学者でも扱いやすい
  • 高い実用性
    • オブジェクト指向 & クラスベース
  • 安全性重視
    • 強い静的型付け
    • 扱いやすい例外システム
  • 中間言語を採用
  • 速度向上
    • GC の廃止

リンク

GitHub リポジトリ
トップページ
言語紹介

がーねっとがーねっと

[提案] ベクタなどの範囲外参照

内容

範囲外を参照した時に例外や返り値で処理するのでなく Rust でいうパニックを起こす
事前に範囲内であるかチェックされていることが前提っていう

問題点

インデックスのチェックを書き忘れると致命的
パニックを起こさせるほどなら明示的に書かせたほうがいい?
(改善例) Rust でいう unwrap() のような関数でエラーを握りつぶす

がーねっとがーねっと

[進捗] 2021/08/17

要約

自作 PEG パーサ ( FCPEG パーサ ) を制作中
ほとんどの機能は実装済みなのであとは動作テストくらい

がーねっとがーねっと

[解説] FCPEG の雑紹介

概要

Ches のコンパイルは現在開発中の PEG パーサを用いる
名前は FCPEG; Functional Ches PEG と FunCobal をかけあわせたもの
FunCobal は共同開発者の Haruka Sato 氏が開発するプログラミング言語

コード例

FCPEG では規則をブロックに分けて定義する
Main ブロックの定義と start 文の記述は必須
ここでは設定ファイルの記述を省略する

[Main]{
    % Main ブロックを定義,
    % 使用するブロックを指定,
    + use Expr,
    % 開始の規則を指定,
    + start Expr.ID,
}

[Expr]{
    % Expr ブロックを定義
    % ID 規則を定義
    %     アルファベットで始まりアルファベット, 数字, 一部記号が 0 回以上続く文字列にマッチ
    ID <- [a-zA-Z] [a-zA-Z0-9_]*
}
がーねっとがーねっと

[提案] 命名規則: snake_case

概要

変数, 関数名などでは snake_case を用いる
camelCase よりも見やすいし打ちやすい

がーねっとがーねっと

[提案] for / for-in 構文

概要

for 文のカバー範囲は割と広い

構文

for
    println("無限ループ")
end
for true
    println("真偽値が true である限りループ")
end
## 問題点へ
for 10
    println("10 回ループ")
end
## for-in 構文
for elem in iterator
    println("イテレータでループ")
end

問題点

for truefor 10 がややこしいかも
指定する変数を間違えた時に型エラーで教えてほしい
for i in 10for i in range(10) にする?

メモ

for-in 構文で代入される変数を省略できたほうが楽 + 処理を最適化できそう

(例) for elem in iterator -> for in iterator

がーねっとがーねっと

[提案] インクリメント / デクリメントの廃止

概要

これを使われるとどこで変数をいじってるのかわかりづらい
+= -= 演算子で置き換えられる

がーねっとがーねっと

[提案] Rust 風の変数の扱い

変数の扱いは Rust を参考にする
安全性確保と GC の廃止ができればいいなと

可変 / 不変 ( mutable / immutable )

不変な変数は値の変更ができない
変数がデフォルトで不変なのは記述ミスで余計な変数を改変できなくするため
mut キーワードを使うと可変な変数を定義できる
(例) let mut num = 1

所有権

大部分は Rust の所有権と同様

所有権の移動

変数を他の変数に代入する時や引数として渡す時は例外を除き所有権が移動する
例外となるケースはコピーや参照渡しなど
Rust とは異なり、組込型の値が暗黙的にコピーされることはない ( 動作を統一するため )

参照

変数の参照はそれぞれ一つしか生み出せない

問題点

所有権と参照の概念は初学者にとって高い壁になる
ただし Ches のコンセプトには欠かせない要素なので問題はどう仕様を簡易化するかになる

がーねっとがーねっと

[雑話] Ches と Rust

概要

個人的な話だが私は Rust が大好きである
学習コストが高いという欠点はあるが書きやすいし高い安全性が保証される
Ches のコンセプトともマッチしている部分があるため主に Rust を参考にした言語設計をしようと思う

先に投稿した [提案] Rust 風の変数の扱い も Rust からの影響を受けたものである

余談

Ches の実装ではもともと C++ を用いていたが Rust を勧められそちらに移行した
ということで軽く勉強し実装をしてみたところ、体感ではあるがバグの回数がかなり減少
事前にコンパイルエラーで教えてくれることがどれだけありがたいことか・・・

がーねっとがーねっと

[メモ] 言語設計での考慮要素

概要

Ches の言語設計では以下の要素を考慮する
ふと思いついた内容なので後々編集するかも

  • 安全性 ... 記述ミスやバグを生みづらい
  • 明瞭性 ... 明示的で読みやすく書きやすい
  • 簡素性 ... シンプルでわかりやすい
がーねっとがーねっと

[雑話] 安全性と低学習コストの両立 (下書き)

概要

安全性と低学習コストの両立をどのようにすればいいのだという嘆き
※ 言語設計に関しては割と無知に近いのでそこらへんの勉強はしたい

高い安全性を採るとなればそのための仕組みが必要、でもそのせいで学習コストが高くなることもある
どちらをどのくらい優先させるべきかを考えるべきなのか...
実際だとまた他の要素 (例えば実行速度) も考慮しなければならないのが難しい話

学習コスト

そもそも「学習コストが低い」というコンセプトに関して少し疑念が出てきた
Ches ではプログラミング初学者が学びやすいように難易度を下げるという方針を採っている
これは Rust がもっと学びやすければなと思ったことが理由の一つ

ただ安全性を犠牲にして学習コストを下げることはしたくないので結果的に安全性のほうが優先されていると思う
そうなれば低い学習コストというメリットが薄れるのでは
他言語の技術を取り入れるだけでなく独自の手法も考えるべきなのか

やはり安全性を両立させることは厳しいのか?
Rust のハードルが高いのはまあそういうことなんだろうけども...

がーねっとがーねっと

[報告] FCPEG: 順不同の繰り返し数を 0 回以上にした際の現象

概要

規則 (a, b)^[-1] において ba の検査が失敗する現象のメモ

対処

未検討

がーねっとがーねっと

[メモ] FCPEG: ToDo リスト (210818)

概要

所要時間は相対的なもの

  • デバッグ ... 所要時間: 長
  • エラー処理の変更 ... 所要時間: 中
  • 残りの機能の実装
    • [完] 設定ファイル ... 所要時間: 中
    • [完] use 文におけるエイリアス機能 ... 所要時間: 短
    • [完] 繰り返しにおける数値の単体指定 ... 所要時間: 短
  • コマンドラインツールの実装
がーねっとがーねっと

[雑話] 「一つの手段」と糖衣構文

概要

Twitter で Python の話題を見て思い出した ※ 筆者は Py 経験浅め

Ches では「誰が書いても同じコードになるようにする」理由で「一つのことに一つの手段」という設計方針がある ※ 呼び名は未確定
( The Zen of Python だと There should be one-- and preferably only one --obvious way to do it. に当たる? )

私はこの Ches の方針を「複数の同等機能から決まった一つの手段を選んで使う」ではなく「そもそも言語が複数の同等機能を与えないようにする」と解釈していた
しかしそれだと異なった構文で同等機能を与える糖衣構文が否定されることになる
ということで前者に解釈を切り替えることに

現在の解釈をまとめると

  • 異なった構文の同等機能が複数存在することを許容する
  • ただし使用ケースによって 必ず 決まった一つの構文を使うことになる

これで「誰が書いても同じコードになるようにする」という条件は満たせるかな

がーねっとがーねっと

[提案] private フィールドの命名 _field

現時点では private がデフォルトで public 化するには pub キーワードが必要
ただ、命名規則で区別したほうが書く時にアクセス範囲が明確にできていいのではと
(例) _field

そこで困るのは private なフィールドのアクセス自体はできるところ
ここはコンパイラにチェックしてもらうべきなんだろうけど、
変数名によってエラーを出すのも不自然かなと思ってしまう

がーねっとがーねっと

[メモ] 予約語の命名

  • なるべく名詞を使わない ... 変数名との重複を防ぐため
  • 区切り文字を使わない ... (誤例) reserved_word

(予約語の例) as str s32 u64 if for in fn

このスクラップは2023/12/04にクローズされました