#author("2017-09-04T11:42:23+09:00","","") #author("2017-09-04T20:43:08+09:00","","") *** NO.77515 [#r7d5c57c] -詳細は以下資料を参照ください。 TinyHSPの提案_20161208.zip http://ux.getuploader.com/kikerogaupl/download/66/TinyHSP%E3%81%AE%E6%8F%90%E6%A1%88_20161208.zip こんなHSPあればいいなという単純な思い付きであり、願望なのですが 賛同・協力いただける方がいれば嬉しいです。 まずは発信をと思い、書き込みました。 気長に進めていければと思っています。 --kikeroga氏 2016/12/9(Fri) 16:10:55 *** NO.77548 [#lb4c042c] -マルチプラットフォーム対応の、OS依存の命令を抜いた実行環境としてのHSPという感じがしましたが、 現状のHSPが既にWin、iOS&Android、Web(JS)といくつかの環境の上で動いているので、 TinyHSPがHSP自体とどれくらい差異があって、コンパクトである利点がどれぐらいあるのか、の熱量がちょっと図りかねるところがありました。 とは言いつつ、クリーンなHSPがあると嬉しいことは個人的には多分にあると思ったので、興味あります! 私自身あんまり技術力ないので、開発にどれくらい貢献できるかは謎ですが、ひとまず話は聞いてみたいです。 --3k氏 2016/12/10(Sat) 17:09:36 *** NO.77566 [#ldd5061f] -3kさん、コメントありがとうございます。 現状既にWin、iOS&Android、Web(JS)といくつかの環境でHSPがあり HSPの知識は各環境で開発する際には十分に活かせると思います。 ただ、移植にはそれぞれの環境に合わせた修正が必要になりますよね。 プログラムソースレベルで完全互換とすることで、 おっしゃる通りのクリーンなHSP(開発環境、実行環境を選ばない)を 実現したいと思っています。 資料にあるTiny命令だけでプログラムを組んだとしても 各環境で完全に同じ動作はしないと思っていて、そこを合わせるのが TinyHSPになるかなぁと。 Tinyという名称にも由来しますが、命令数をしぼって少なくするのも 憶えやすそうとか、印象も実装も軽いとか、利点ととらえてます。 コンパクトである利点がどれぐらいなのかは私自身も検討できてないですが 個人的な想いが発端なので、こういうものが好きな人たちで楽しみながら 進められたら良いなと考えてます。 --kikeroga氏 2016/12/12(Mon) 13:18:17 ***NO.77572 [#i65dc440] -興味深い提案をありがとうございます。 ランタイムのバリエーションなどで色々と仕様が増えているHSPにおいて、複数プラットフォームで共通の仕様で動作する(クリーンな)形を目指すのは良いことだと思います。 広げた風呂敷を畳むような感じでしょうか。現在、HSP3Dishもありますが、開発環境も含めた形で方向性が見えるといいなと感じています。 --おにたま氏 2016/12/14(Wed) 00:04:35 ***NO.77590 [#pdb4fa70] -おにたまさん ご理解、コメントいただき、嬉しい限りです(^_^) > 広げた風呂敷を畳むような感じ 言われて初めて気づきました。 HSPは十分易しいと思うのですが、TinyHSP の意図として Visual Basic に対しての Small Basic のような感じはありますね。 色々ご意見いただいて、あとは作るだけ、くらいまで 仕様のイメージが固まるといいなと思ってます。 --kikeroga氏 2016/12/15(Thu) 16:48:55 ***NO.77638 [#w2fe3e33] -一からソースを書くということでしょうか? それともOpenHSPの派生になるのでしょうか? OpenHSPからの派生になると、実装が楽というわけにはいかないと思います。 言語仕様が多少変わることも含めてTinyHSPということでしょうか? どちらにしても協力したいと思います。 --tds12氏 2016/12/18(Sun) 15:14:32 ***NO.77644 [#w28a0dec] -tds12さん、コメントありがとうございます。 > 一からソースを書くということでしょうか? > それともOpenHSPの派生になるのでしょうか? 個人的にはOpenHSPのソースから改修したほうが既に知見をお持ちの方が多いこともあり、 メリットが多いんじゃないかなーとは思ってます。 また、派生というよりは機能縮小版に近い実装になるんじゃないかと考えてますが、 いかがなもんでしょうか? > OpenHSPからの派生になると、実装が楽というわけにはいかないと思います。 仕様、ソースとも新たに作る部分は出てきますね。 > 言語仕様が多少変わることも含めてTinyHSPということでしょうか? ご認識の通りです。 > どちらにしても協力したいと思います。 ありがとうございます。協力はどんなかたちでもOKですし、 コメントいただいてることが既に協力してもらっているのと同義です(^_^) --kikeroga氏 2016/12/19(Mon) 11:06:38 ***NO.77646 [#je5c2ba8] -面白そうなご提案だなあと思って見ていました。 何ができるかは謎ですが、手伝えそうなことがあればお手伝いしたいなと思っています。 > 個人的にはOpenHSPのソースから改修したほうが既に知見をお持ちの方が多いこともあり、 > メリットが多いんじゃないかなーとは思ってます。 横からで申し訳ないのですが、個人的には1から書いた方がよりコンパクト・クリーンになって 何かとやりやすいんじゃないかなと思います。 あと、個人的にはプラットフォーム間の互換性の他にも、本家より小さい分実行速度も速い みたいな+αがあるとさらに魅力的かなと思いました。 --undef32氏 2016/12/19(Mon) 21:04:02 ***NO.77660 [#i457f2d4] -undef32さん、コメントありがとうございます。 ソースについてはTinyHSPの仕様を前提にベストなやり方ができるといいですね。書き方についてはそんなにこだわっていません。 コンパクト・クリーンなソースなら見易さ、理解のしやすさも手伝って、移植もメンテもやりやすくなるでしょう。 また、早い、軽い、というのは魅力の一つでもありますね。 TinyHSPの特徴(メリット)を維持するには下記2点を厳守することが大切だと思っています。 ・絶対!機能拡張しない(…守れるのか?) ・異機種間の互換性重視(ソース/中間言語レベル) ご興味がある方には思い付きでも、ただのご賛同でもかまわないので、どんどんコメントください。 アイデアや留意することなど、何でも出し尽くさないと良い仕様にならないと思いますので。 TinyHSP的なものが皆さん潜在的な願望としてあったのかなと、意外と反応が良くて嬉しいです(^_^) --kikeroga氏 2016/12/20(Tue) 10:37:02 ***NO.77791 [#r56d5dcd] -kikerogaさん、ご意見ありがとうございます。 私も意見交換の場として盛り上がってきて嬉しいです。 TinyHSPという名称についてですが、 このTiny(=ちっぽけな、とても小さい)という言葉の意味と、 このスレッドで検討されている「クリーンなHSP」とでは、 幾らかイメージが異なってきているように感じます。 また処理系を実装する人たちの習慣に、 遊びで作ったような「とても小さな」処理系に、 Tiny...という名称をつけるという習慣があります。 もし発案者のkikerogaさんのお気持ちが許しましたらですが、 将来的に「TinyHSP」という名称を、 別なものに変えるというのはいかがでしょうか。 -sakuraさん、ご意見ありがとうございます。 追加していただいた「HSP3言語仕様互換性の検討」、 とても参考にしています。 こうしてみるとHSPの言語仕様は想像以上に大きいのですね。 > Tinyなものにするには、大幅に命令等を削って > 超高速化や軽量化した利用用途を限定したものが良いように感じます。 私もそのように感じています。 TinyHSPとしては、できるだけ軽量化した処理系を目指すのが良いと思います。 TinyHSPをより軽量化するにあたって、 こうしたらいいんじゃないかというような、 アイデアはおありでしょうか。 おにたまさん、ご回答ありがとうございます。 HSPは2.61のころから愛用させていただいています。 > emscriptenなどと同様に汎用的なライブラリをターゲットに作っておけば、将来的に対応はできるのではないかと思います。 ありがとうございます、 それを聞いて安心しました。 > 何らかの成果や技術のフィードバックができれば フィードバックする方法には、 具体的にどんなものがあるでしょうか。 もしよろしければ、 教えていただけるとたいへん助かります。 -くちくんさん、ご意見ありがとうございます。 > ぜひ実現してほしいHSPの形だと思いました。 私もこのスレッドで検討されている、 HSPをとても気に入っています。 「クリーンなHSP」と「TinyHSP」は、 別々のプロジェクト(仕様)に分けてもいいんじゃないかな、 とも思います。 それで、もし可能でしたら、 まずはより小さい「TinyHSP」の仕様をまとめてから、 「クリーンなHSP」の話し合いに移行できたら良いのかな、 と思っています。 --dolphilia氏 2017/1/1(Sun) 12:58:41 ***NO.77796 [#ac069862] -皆様、明けましておめでとうございます! dolphiliaさん、意欲的なコメントが多くて嬉しく思います(^_^) > 将来的に「TinyHSP」という名称を、 > 別なものに変えるというのはいかがでしょうか。 それこそまさにArduino上でも動作するような最小限の命令仕様のものが 本来の「TinyHSP」と言えるのでしょうね。 私が提案していたものとは確かにイメージが異なっていると思います。 名称に大きなこだわりはありませんので、より適切な感じの名称があれば 皆さんで色々考えていただけると良いですね。 > より小さい「TinyHSP」の仕様をまとめてから、 > 「クリーンなHSP」の話し合いに移行できたら良いのかな、 上記のような進め方は面白いですね、とても興味深い。 …何となくですが、HSP本家へ何らかの成果や技術のフィードバックが期待できそうです。 私は賛成です(^_^)/ ぜひともよろしくお願いします。 --kikeroga氏 2017/1/1(Sun) 17:19:04 ***NO.77808 [#xab3a207] >TinyHSPをより軽量化するにあたって、 >こうしたらいいんじゃないかというような、 >アイデアはおありでしょうか -例えばどの環境でもビルドできそうなC言語の標準命令だけで構築できる命令に絞る というのも一つの基準になるかと思います。 あるいは最古参であるPalo Alto版TinyBASICの命令仕様に倣うのも一興一案です。 (命令数がとても少ない) HSPらしい基準にするなら「d3module」が動く!とか、 と…これはあまり軽量化できそうにないですが。 いずれにせよ、TinyHSP→クリーンなHSPという流れに従うなら TinyHSPはきわめて各環境版をリリースし易いつくりにしたほうがよさそうですね。 --kikeroga氏 2017/1/2(Mon) 10:35:40 ***NO.77847 [#c30dae84] -kikerogaさん、ご回答ありがとうございます。 > 名称に大きなこだわりはありませんので、より適切な感じの名称があれば > 皆さんで色々考えていただけると良いですね。 賛同していただけて嬉しいです。 早速いくつか案を考えてみました。(末尾に記載します) > 例えばどの環境でもビルドできそうなC言語の標準命令だけで構築できる命令に絞るというのも一つの基準になるかと思います。 > あるいは最古参であるPalo Alto版TinyBASICの命令仕様に倣うのも一興一案です。 とても面白そうです! 参考にさせていただきます。 sakuraさん、素晴らしい資料をありがとうございます。 とても参考にさせていただいています。 「HSP本体機能を含めた周辺機能」などは、 まだこのスレッドではほとんど検討されていないので、 そういった点も追々検討していてければいいな、 と思っています。 > 高速に大量のデータ処理ができたり、HSPの優れたグラフィック処理を > 利用したデータ分析に応用できたりする強力な専用エンジンがほしいです。 私もHSPに正規表現が標準で搭載されたら良いなとか、 深層学習やVR・AR技術を実行できるようなエンジンがあれば良いな、 なんて考えたりします。 なんとなくですが、このスレッドではそういったことも、 自由に発言して良い雰囲気があるような気がしています。 -Y_repeatさん、ご意見ありがとうございます。 > 自分は仕様を決めるにしてもWEBに決めたことを載せちゃうと実行しないので すごくよく分かります。私も「これこれをやります」と言ってしまうと、実現できなくなるジレンマによく陥ります。 > 全部で1万行くらいのプログラム言語作成学習用であったらなあ。と思います HSP処理系ではないのですが、こういうのはいかがでしょうか。 lispy(lispインタプリタ:コメントを除くとpythonで90行) http://www.aoky.net/articles/peter_norvig/lispy.htm PL/0'(簡略化したPascal:lexとyaccとC言語を使って約600行) http://www.k.hosei.ac.jp/~nakata/oCompiler/PL0yacc/pl0yacc.html 豊四季タイニーBASIC(TinyBASICインタプリタ:C言語で1300行程度) https://github.com/vintagechips/ttbasic_lin -おにたまさん、ご回答ありがとうございます。 > ソースコードが公開されていれば、有用なコードや変更はこちらでOpenHSPに取り込むことが可能です。 > また、TinyHSPなど他のランタイムと共用して修正のしやすい形でOpenHSP側のソースコードを変更するなどのフィードバックもできるかと思います。 ありがとうございます。 TinyHSPはオープンソースで、 Githubで開発するようにしてみます。 https://github.com/dolphilia/tinyhsp > 必要なものを見極めた上で大胆に削って、限定した形になることを願っています(^^ 上記のTinyHSPは私の遊び心も入ってしまっているので、 このスレッドで検討されている「クリーンなHSP」は、 じっくりと仕様を検討していければいいな、と思っています。 「TinyHSP」とは別に、 このスレッドで検討されている「クリーンなHSP」に、 新しい名称を付けようと思っています。 7つほど候補を選んでみました。 1. Small HSP (小さな) 2. Light HSP(軽い) 3. Clear HSP(クリアな・分かりやすい) 4. Clean HSP(クリーンな・清潔な) 5. Common HSP(共通の) 6. Next HSP(次の) 7. Future HSP(未来の) この中に適切だと思う名称はあるでしょうか。 --dolphilia氏 2017/1/5(Thu) 12:40:16 ***NO.77877 [#zbb015a6] -sakuraさん、本当にありがとうございます! Y_repeatさん、 多様なご意見、ありがとうございます。 「Academic HSP」もなかなかいい発想だと思います。 名称は成るようになるでしょう!(^o^) KAさん、 強い興味を抱いていただいていることに感謝します。 sakuraさんもおっしゃってるように進め方に関するご意見に異論はありません。 このスレッドは"TinyHSPの提案"として立てましたが、 ・おにたま氏がコメントし、そのプロットと意義を認めてくれたこと ・sakuraさんが大変素晴らしいベースドキュメントを作成してくれたこと ・dolphiliaさんがtiniyhspのプロジェクトを開設してくれたこと と十二分な成果を果たしており、その役割を終えているように思います。 今以上に論議を発展させる場所としては、ご指摘の通りWikiやその他の仕組みで 進めるほうが適切だとは思いますが、これから先のことも、私自身も含めて 何がどうなろうと、誰かができることをやるだけです。 少なくともこのスレッドを立てた意義は想定以上に大きかったようで 良かったと思っています。 あとはもう成るようになるでしょう!(^o^) --kikeroga氏 2017/1/9(Mon) 12:25:49