設計者のみで使うような超マイナー言語ではないので、ユーザからの設計に対する疑問は当然出てくるとと思います。 このページは繰り返されるそれらの疑問に答えるために作りました。
基本的には、
思いつき・提案→構想→実装→仕様化
という順序です。（あまりに基本的な機能は最初から仕様化されています）
「提案」された案は、なるべく実用的なものを仕様に取り入れるようにします。
これは設計者である私による、ある種の完璧主義の影響もないとは言い切れません。
合理的な理由として、まず、発展したプログラミング言語の大抵は、実装系非依存であるという点です。
また、実装系に依存したコードというのは維持が容易でないのです。
あさやけの構想の一部に「コンパイラでも、インタプリタでも同じコードが使いまわせるくらい、
抽象性が高くて分かりやすくて、不変の文法であれば、スクリプトを書く作業と維持する作業は楽になるだろうな」と
いうものもありました。
スクリプト言語の文法は非常にころころ変わります。実装系非依存であるということは、同時に
「そう簡単に文法の仕様を変更できない」「私の実装に文法は凝り固まってはいけない」という暗示に
なっているのです（他の実装系が存在しなくても、暗示になっていることに変わりはありません）。また、
私の実装系から得た経験を当てにしないという意味でもありません。
確かに、他の日本語プログラミング言語では大抵エントリーポイントというものはありません。
スクリプト言語では普通のことで、上から順番に処理されるというのがお決まりのパターンです。
あさやけでは採用しませんでした。その理由の一つ目は、順序依存性というものです。
メインコード（エントリーポイントがない言語での開始コードとしましょう）がクラスの前にあったら、
メインコードでそのクラスを使ってよいのか、悩んでしまうでしょう。（ただ、「メインコードの前に
クラスは読み込まれます」と言えばそれで済みます。）あさやけでは、関数やクラスの間に順序依存性がないと
言うことで、この問題を一掃しています。
二つ目は、自由なコードの実現です。例えば、あさやけ用にあさやけで書かれたライブラリがあったとします。
実は、ライブラリでエントリーポイントを定義してしまうことも可能です（こういう仕組みで有名なのは
スクリーンセーバーです）。また、開始コードがいろんなところに移動できるので、モジュール化も容易です。
三つ目は、システムから関数が呼ばれるということを理解してもらう、ということです。
仕組みは意外と簡単です。あさやけの内部では、一時的な変数をたら回しすることで命令を実行しています。
その中で、関数や代入などに渡された変数は、当然それらの操作に渡されます。
その変数は操作に必要な値を取り出されます。
実は関数や代入などへ渡されなかった式の最後の残り物へ、特別な処理を送信します。
この処理を利用して、値にも動作にもなる多様な変数を作ることができます。