page0001
の編集
https://essen.osask.jp/?page0001
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
EssenRev4
FormattingRules
FrontPage
Help
InterWiki
InterWikiName
InterWikiSandBox
K
MenuBar
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SDL2_01
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
a21
a21_acl01
a21_bbs01
a21_challengers
a21_count
a21_edu01
a21_edu02
a21_edu03
a21_edu04
a21_edu05
a21_edu06
a21_edu07
a21_edu08
a21_edu09
a21_edu10
a21_edu11
a21_hlx000
a21_hlx001
a21_hlx001_1
a21_hlx001_2
a21_hlx001_3
a21_hlx002
a21_hlx002_1
a21_hlx003
a21_hlx003_1
a21_hlx004_1
a21_memo01
a21_opt
a21_opt02
a21_opt03
a21_p01
a21_special
a21_tl9a
a21_todo
a21_txt01
a21_txt01_10
a21_txt01_1a
a21_txt01_2
a21_txt01_2a
a21_txt01_2b
a21_txt01_3
a21_txt01_4
a21_txt01_5
a21_txt01_6
a21_txt01_6a
a21_txt01_7
a21_txt01_8
a21_txt01_8a
a21_txt01_9
a21_txt01_9a
a21_txt02
a21_txt02_10
a21_txt02_10a
a21_txt02_10b
a21_txt02_11
a21_txt02_11a
a21_txt02_12
a21_txt02_12a
a21_txt02_12b
a21_txt02_1a
a21_txt02_1b
a21_txt02_2
a21_txt02_2a
a21_txt02_3
a21_txt02_3a
a21_txt02_4
a21_txt02_4a
a21_txt02_5
a21_txt02_5a
a21_txt02_6
a21_txt02_6a
a21_txt02_6b
a21_txt02_6b_rev0
a21_txt02_6x
a21_txt02_7
a21_txt02_7a
a21_txt02_8
a21_txt02_8a
a21_txt02_9
a21_txt02_9a
a22_acl2_01
a22_acl2_02
a22_edu12
a22_intro01
a22_intro02
a22_intro03
a22_memman01
a22_memman02
a22_memman03
a22_memman04
a22_memman05
a22_memman06
a22_memman07
a22_memo01
a22_mingw_debug
a22_txt03
a22_txt03_1a
a22_txt03_1b
a22_txt03_2
a22_txt03_2a
a22_ufcs01
a23_bbs
a23_ec001
a23_ec002
a23_intro00
a23_intro000
a23_intro01
a23_intro02
a23_intro03
a23_intro04
a23_intro05
a23_intro06
a23_intro07
a23_intro08
a23_intro09
a23_intro10
a23_intro10wk1
a23_intro10wk2
a23_intro10wk3
a23_intro11
a23_intro12
a23_intro13
a23_intro13wk1
a23_intro14
a23_intro15
a23_intro16
a23_intro90
a23_intro91
a23_neopixel1
a23_os01
a23_useSelfMade
a23_usm001
a23_usm002
a23_usm003
a23_usm004
a23_usm005
a23_usm006
a23_usm007
a23_usm008
a23_usm009
a24_memo01
a24_osc20240310
a24_osc20241026
a24_raspberrypi01
a24_useSelfMade
aclib00
aclib01
aclib02
aclib03
aclib04
aclib05
aclib06
aclib07
aclib08
aclib09
aclib10
aclib11
aclib12
aclib13
aclib14
aclib15
aclib16
aclib17
aclib18
aclib19
aclib20
aclib21
aclib22
aclib23
aclib24
aclib25
aclib_bbs
arm64_01
avm0001
edu0001
edu0002
edu0003
esb02b_hrb
esb_dbg
esbasic0001
esbasic0002
esbasic0003
esbasic0004
esbasic0005
esbasic0006
esbasic0007
esbasic0008
esbasic0009
esbasic0010
esbasic0011
esbasic0012
esbasic0013
esbasic0014
esbasic0015
esbasic0016
esbasic0017
esbasic02a
esc0001
escm0001
essen_hist
esvm0001
esvm0002
esvm0003
esvm0004
esvm0005
esvm0006
esvm_i0
hh4a
idea0001
idea0002
idea0003
impressions
jck_0000
jck_0001
kawai
kbcl0_0000
kbcl0_0001
kbcl0_0002
kbcl0_0003
kbcl0_0004
kbcl0_0005
kbcl0_0006
kbcl0_0007
kclib1_0000
kclib1_0001
kclib1_0002
kclib1_0003
kclib1_0004
kclib1_0005
kclib1_0006
kclib1_0007
kclib1_0008
kclib1_0009
kclib1_0010
kpap0001
members
memo0001
osask4g
osask4g_r2
p20200311a
p20200610a
p20200610b
p20200624a
p20200711a
p20200716a
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
populars
seccamp
seccamp2019
sechack
sechack2019
seclang01
sh3_2020
sh3_2020_kw
sh3_2020_nk
sh3_2021_kw
sh3_2021_nk
sh3_2022_kw
sh3_2023_kw
sh3_2024_kw
sh3_kw_hist
termux001
termux002
text0001
text0001a
text0002
text0002a
text0003
text0004
text0005
text0006
text0006a
text0007
text0008
text0010
text0011
text0012
text0013
text0014
text0015
text0016
text0017
text0018
text0019
text0020
text0021
tl1c
tl2c
tl3c
tl3d
* EssenRev4 の基本的なアイデア -(by [[K]], 2018.03.05) ** (0) はじめに -EssenRev1: --セキュリティキャンプ2017で作っていたバージョン1 -EssenRev2: --セキュリティキャンプ2017で作っていたバージョン2 JITコンパイル方式 -EssenRev3: --その後迷走したバージョン -EssenRev4: --これから作るバージョン ** (1) 基本的なアイデア -「変数、型、関数だけではなく、構文や演算子を自由に作れる言語」という基本はまったく変わらない。 -まず最大の違いとして、動的型付き言語から静的型付き言語に変更。 --なぜ?それはそのほうがJITコンパイル時に高速なコードが容易にできそうだから。 --Rev1のころは速度を重視しなかったけど、速いのはやっぱり重要だと思った。あまりに遅いと便利でも使ってもらえない。 --C言語並みに早くなっている必要はないけど、C言語比で処理時間が10倍とかだと使う気が無くなる可能性がある。 -Rev3以前のように型を気にしないプログラミングがやりたいときは、var型か何かを作って、それはつまりなんでも型で、それを使うことで動的型付き言語として使えるようにしよう。でもきっと少し遅いだろうけど(実行時にバインディングを解決するので)。 -速度を出すためにJITコンパイルを基本に考えるけど、生成したコードをそのまま出力するのもありで、その場合は単一の.exeファイルになる。つまりコンパイル型の言語としても機能できる。 -ここで、なぜRev1のころは動的型付き言語を指向していたのかをメモしておこうと思う。静的型付き言語では、ほぼ同じ操作をしているだけなのに、対象の型が変わればコードも生成しなければいけない。たとえば整数でのソート、実数でのソート、文字列型でのソートがあった時に、それらは区別される。C++になればテンプレート型引数が使えるようになって、ユーザは記述しないで済むようになったものの、そんなの動的型付き言語であれば気にせず普通に書けば実現できることなので、それこそ目指すべき姿だろうと考えたのだ。 -Rev4ではそういうときはvar型の引数にしておけばいいと思っている。 ** (2) 上位構文の目標(1) - カッコ -みなさんはLISPという言語をご存知だろうか。私はこの言語はおそらくシンプルかつ多機能さという意味で究極の言語だろうと思う。しかしLISPで書かれたプログラムは(私にとっては)読みにくい。書きやすいとも感じられない。・・・どうしてそう感じるのか、ずっと考えてきた。理由もなく嫌っているのは、ただのわがままや難癖と大差ないと思うから。 -LISPで書かれたプログラムはカッコが多い。カッコのネストはちょっとしたことでもすぐに深くなり、インデントを工夫したり、もしくはエディタの支援なしでは対応関係が分からなくなってくる。そしてそれこそが、読みにくさの本質ではないかと今の私は考える。 -そのことを説明するために、いったんLISPを離れよう。数学では、計算は左から右へ順番にやる・・・というふうにはなっていない。足し算引き算よりも掛け算や割り算が優先されるし、べき乗はもっと優先される。なぜそんなことにしたんだろうか。私は少なくとも昨年まではこの習慣に批判的だった。もしすべての優先順位が同じなら、つまり演算子の優先順位なんかなければ、式を処理するプログラムはすごくシンプルになる。なぜ人類はこんなくだらない習慣を捨てられないのか。などと思ってきた。・・・しかし今は違う。この習慣は大変合理的である。プログラムがこれをどうにかするために努力することも必要なコストである。 -なぜそんなややこしい習慣があるのかと言えば、数式においては 2*a^2+3*a*b-c みたいな式が頻出し、その際にカッコを書きたくないかだ。そうに違いない。もしすべての演算子に優先順位がなければ、 2*(a^2)+(3*a*b)-c と書かなければ値が違ってしまう。このカッコを書きたくなかったから、ややこしい演算子の優先順位を作ったのだ。・・・つまり人類はカッコが大嫌いなのだ。カッコをなくすために代償を払ってもいいと思っているのだ。そしてLISPはこの原則を無視しているのだ。だから私はLISPが好きになれなかったのだと思う。 -私はビット演算が得意なプログラマなので、C言語でこんなコードをよく書く。 if ((flag & 1 << 12) != 0 && ((a ^ b) & 15) == 0) { ... } -なんだこれは。カッコが多いじゃないか。これはひとえに、C言語における&や|の優先順位が低すぎることによる。まずはそこを改善しなければいけないと思っている。 -さらに関数の呼び出しでもカッコは必要だし、ifやforで多用する { } だって、中カッコではあるけど、カッコはカッコだと思っている。これを減らすすべはないだろうか。インデントもそんなにすぐれた解決法だとは思わない。スペースやタブの量でプログラムの意味が変わるなんて、ネタ言語である「Whitespace」を笑えないではないか。インデントはプログラマの自由であるべきだ。 -こうして「何がダメなのか」はおおよそわかっているものの、「じゃあどうしたらいいのか」はほとんどわかってない。ノーアイデアである。数学に学ぶとすれば、数学は引数(添え字とか)を下付き文字にしたり、上付き文字にしたり、省略したりと、いろいろ工夫している・・・ように見える。それを真似するといいんだろうか?? -まずカッコを減らす簡単なアイデアとしては、代入がある。 ここで A = a+b-c とおく -みたいなやつである。これをやればカッコは減る。もしかしたら見通しもよくなるかもしれない。 -ではなぜこれをやらないのかというと、なんか変数を減らしたいという衝動があるから・・・かな?違うかもしれないけど、仮にそうだとしよう。変数を減らしたい衝動としては、記述量が増えてしまうから?変数が増えてしまうから?変数の型を決めなければいけないから?宣言がめんどくさいから?? -いずれにせよ、その衝動を抑えるような仕組みが必要だろう。それさえあればこの問題は解決に向かうはずだ。 ** (3) 上位構文の目標(2) - 変数名を渡す仕組み -C言語では、変数aとbの値を確認したいときにこんな風に書くだろう。 printf("a=%d, b=%d\n", a, b); -しかし私はこの書き方が気に入らない。なぜaやbを二度書くのか?こんなのはミスの温床だ。そうじゃなくて、こう書けるようになりたい。 dump(a, b); -これで変数名とその値が表示できたらどんなに便利だろう。・・・ああそうとも、#defineマクロを使えば同じことはできるだろうさ。でもそれでいいのか。プリプロセッサなど使わずに、純粋な言語機能だけでこれをやりたいのだ。関数は実引数名(もしくは式)を受け取れたら素敵じゃないか。 ** (4) 下位機能での目標(1) - ポインタなど -プログラミング言語を作ろうという時に、ポインタなんかなくしてしまおう、あんなものがあるからバグやセキュリティホールの温床になるんだ、みたいな考え方がある。もしくは、intだってどんどん多倍長化して、どんなに大きな数でも入れられるようにしよう、そうすればオーバーフローに悩まされることはない!という考え方がある。・・・これは確かにその通りで、私もそのように考えていた時期があったが、今はそうは思わない。 -EssenRev4では、ポインタはあるしポインタがおかしくなることもありうるし、オーバーフローも起こりうる。しかし、それらはすべて容易に検出できる。そこがC言語とは違う。Essenは過保護な言語を目指さない。できることは一通りできるが、おかしなことをやってしまった時に教えてくれるのだ。それを目指す。 --なお、このポインタのチェックやオーバーフロー検出などは、以前作った OSECPU-VM rev2 でかなり試したので、うまくいく自信がある。 ** (5) 型情報の提供 -CやC++の言語処理系は、構造体のメンバ情報などをすべて知っているくせに、それをプログラムに渡してはくれない。ある構造体のポインタが渡されたとして、メンバ名、メンバへのオフセット、型などを全部教えてくれたらすごく便利だとは思わないだろうか?汎用のオブジェクトダンプツールが簡単に作れるようになる。でも既存の処理系はこれらの情報を全くよこさない。けしからん! * こめんと欄 #comment
タイムスタンプを変更しない
* EssenRev4 の基本的なアイデア -(by [[K]], 2018.03.05) ** (0) はじめに -EssenRev1: --セキュリティキャンプ2017で作っていたバージョン1 -EssenRev2: --セキュリティキャンプ2017で作っていたバージョン2 JITコンパイル方式 -EssenRev3: --その後迷走したバージョン -EssenRev4: --これから作るバージョン ** (1) 基本的なアイデア -「変数、型、関数だけではなく、構文や演算子を自由に作れる言語」という基本はまったく変わらない。 -まず最大の違いとして、動的型付き言語から静的型付き言語に変更。 --なぜ?それはそのほうがJITコンパイル時に高速なコードが容易にできそうだから。 --Rev1のころは速度を重視しなかったけど、速いのはやっぱり重要だと思った。あまりに遅いと便利でも使ってもらえない。 --C言語並みに早くなっている必要はないけど、C言語比で処理時間が10倍とかだと使う気が無くなる可能性がある。 -Rev3以前のように型を気にしないプログラミングがやりたいときは、var型か何かを作って、それはつまりなんでも型で、それを使うことで動的型付き言語として使えるようにしよう。でもきっと少し遅いだろうけど(実行時にバインディングを解決するので)。 -速度を出すためにJITコンパイルを基本に考えるけど、生成したコードをそのまま出力するのもありで、その場合は単一の.exeファイルになる。つまりコンパイル型の言語としても機能できる。 -ここで、なぜRev1のころは動的型付き言語を指向していたのかをメモしておこうと思う。静的型付き言語では、ほぼ同じ操作をしているだけなのに、対象の型が変わればコードも生成しなければいけない。たとえば整数でのソート、実数でのソート、文字列型でのソートがあった時に、それらは区別される。C++になればテンプレート型引数が使えるようになって、ユーザは記述しないで済むようになったものの、そんなの動的型付き言語であれば気にせず普通に書けば実現できることなので、それこそ目指すべき姿だろうと考えたのだ。 -Rev4ではそういうときはvar型の引数にしておけばいいと思っている。 ** (2) 上位構文の目標(1) - カッコ -みなさんはLISPという言語をご存知だろうか。私はこの言語はおそらくシンプルかつ多機能さという意味で究極の言語だろうと思う。しかしLISPで書かれたプログラムは(私にとっては)読みにくい。書きやすいとも感じられない。・・・どうしてそう感じるのか、ずっと考えてきた。理由もなく嫌っているのは、ただのわがままや難癖と大差ないと思うから。 -LISPで書かれたプログラムはカッコが多い。カッコのネストはちょっとしたことでもすぐに深くなり、インデントを工夫したり、もしくはエディタの支援なしでは対応関係が分からなくなってくる。そしてそれこそが、読みにくさの本質ではないかと今の私は考える。 -そのことを説明するために、いったんLISPを離れよう。数学では、計算は左から右へ順番にやる・・・というふうにはなっていない。足し算引き算よりも掛け算や割り算が優先されるし、べき乗はもっと優先される。なぜそんなことにしたんだろうか。私は少なくとも昨年まではこの習慣に批判的だった。もしすべての優先順位が同じなら、つまり演算子の優先順位なんかなければ、式を処理するプログラムはすごくシンプルになる。なぜ人類はこんなくだらない習慣を捨てられないのか。などと思ってきた。・・・しかし今は違う。この習慣は大変合理的である。プログラムがこれをどうにかするために努力することも必要なコストである。 -なぜそんなややこしい習慣があるのかと言えば、数式においては 2*a^2+3*a*b-c みたいな式が頻出し、その際にカッコを書きたくないかだ。そうに違いない。もしすべての演算子に優先順位がなければ、 2*(a^2)+(3*a*b)-c と書かなければ値が違ってしまう。このカッコを書きたくなかったから、ややこしい演算子の優先順位を作ったのだ。・・・つまり人類はカッコが大嫌いなのだ。カッコをなくすために代償を払ってもいいと思っているのだ。そしてLISPはこの原則を無視しているのだ。だから私はLISPが好きになれなかったのだと思う。 -私はビット演算が得意なプログラマなので、C言語でこんなコードをよく書く。 if ((flag & 1 << 12) != 0 && ((a ^ b) & 15) == 0) { ... } -なんだこれは。カッコが多いじゃないか。これはひとえに、C言語における&や|の優先順位が低すぎることによる。まずはそこを改善しなければいけないと思っている。 -さらに関数の呼び出しでもカッコは必要だし、ifやforで多用する { } だって、中カッコではあるけど、カッコはカッコだと思っている。これを減らすすべはないだろうか。インデントもそんなにすぐれた解決法だとは思わない。スペースやタブの量でプログラムの意味が変わるなんて、ネタ言語である「Whitespace」を笑えないではないか。インデントはプログラマの自由であるべきだ。 -こうして「何がダメなのか」はおおよそわかっているものの、「じゃあどうしたらいいのか」はほとんどわかってない。ノーアイデアである。数学に学ぶとすれば、数学は引数(添え字とか)を下付き文字にしたり、上付き文字にしたり、省略したりと、いろいろ工夫している・・・ように見える。それを真似するといいんだろうか?? -まずカッコを減らす簡単なアイデアとしては、代入がある。 ここで A = a+b-c とおく -みたいなやつである。これをやればカッコは減る。もしかしたら見通しもよくなるかもしれない。 -ではなぜこれをやらないのかというと、なんか変数を減らしたいという衝動があるから・・・かな?違うかもしれないけど、仮にそうだとしよう。変数を減らしたい衝動としては、記述量が増えてしまうから?変数が増えてしまうから?変数の型を決めなければいけないから?宣言がめんどくさいから?? -いずれにせよ、その衝動を抑えるような仕組みが必要だろう。それさえあればこの問題は解決に向かうはずだ。 ** (3) 上位構文の目標(2) - 変数名を渡す仕組み -C言語では、変数aとbの値を確認したいときにこんな風に書くだろう。 printf("a=%d, b=%d\n", a, b); -しかし私はこの書き方が気に入らない。なぜaやbを二度書くのか?こんなのはミスの温床だ。そうじゃなくて、こう書けるようになりたい。 dump(a, b); -これで変数名とその値が表示できたらどんなに便利だろう。・・・ああそうとも、#defineマクロを使えば同じことはできるだろうさ。でもそれでいいのか。プリプロセッサなど使わずに、純粋な言語機能だけでこれをやりたいのだ。関数は実引数名(もしくは式)を受け取れたら素敵じゃないか。 ** (4) 下位機能での目標(1) - ポインタなど -プログラミング言語を作ろうという時に、ポインタなんかなくしてしまおう、あんなものがあるからバグやセキュリティホールの温床になるんだ、みたいな考え方がある。もしくは、intだってどんどん多倍長化して、どんなに大きな数でも入れられるようにしよう、そうすればオーバーフローに悩まされることはない!という考え方がある。・・・これは確かにその通りで、私もそのように考えていた時期があったが、今はそうは思わない。 -EssenRev4では、ポインタはあるしポインタがおかしくなることもありうるし、オーバーフローも起こりうる。しかし、それらはすべて容易に検出できる。そこがC言語とは違う。Essenは過保護な言語を目指さない。できることは一通りできるが、おかしなことをやってしまった時に教えてくれるのだ。それを目指す。 --なお、このポインタのチェックやオーバーフロー検出などは、以前作った OSECPU-VM rev2 でかなり試したので、うまくいく自信がある。 ** (5) 型情報の提供 -CやC++の言語処理系は、構造体のメンバ情報などをすべて知っているくせに、それをプログラムに渡してはくれない。ある構造体のポインタが渡されたとして、メンバ名、メンバへのオフセット、型などを全部教えてくれたらすごく便利だとは思わないだろうか?汎用のオブジェクトダンプツールが簡単に作れるようになる。でも既存の処理系はこれらの情報を全くよこさない。けしからん! * こめんと欄 #comment
テキスト整形のルールを表示する