TinyHSP 他 のまとめページ (仮)クリーンHSPに関する議論
NO.77661 †
少しでも助けになればと思い、コメントします。
Mac版HSPを作った際の、
OpenHSPのLinux版からコンパイラとエンジンを分離したソースが残っていました。
コンパイラ：
https://github.com/dolphilia/hspcmp-macosx/tree/master/01_start/src
エンジン：
https://github.com/dolphilia/hsp3cl-macosx/tree/master/01_start/hsp3cl
（コンパイラはこのままmakeすればOKで、エンジンの方はmakefileを書き直す必要があります）
ほとんどの命令・関数が、
hsp3gr.cpp（描画系）
hsp3int.cpp（関数など）
で定義されています。
ご参考までに。
仕様の方、拝見しました。
オブジェクト制御命令はごっそり削ったんですね。
これなら実装はかなり容易なはずです！
描画部分はHSP3DishのようにOpenGLでいけるので、
モバイル対応もすんなりいけそうです。
（あるいはHSP3DishがTinyHSPに準拠しているとも言えなくもないですね）
以下は要望です：
screen命令での新規画面生成は、
Macやモバイルではかなり苦しいので、
その辺りの仕様は、お手柔らかにお願いします。
（第一パラメーターを廃止あるいは非推奨に・・・）
syscolorやsysfontの互換性も悩ませるところです。
システム依存の色やフォントの違いは、許容範囲だと助かります。
mouse命令は便利ですが悪用されると面倒な命令なので、非推奨の方向で・・・。
getkeyやstick命令は、
デスクトップとモバイルでの互換性が気になります。
最近はマルチタップも普通になってきたので、
その辺りをどうするかも。
あとモバイルは基本的にファイルへのアクセスをある程度制限をしてるので、
notesaveやbsaveやbmpsave、
bloadやnoteloadやmmloadやpicloadなどファイルアクセス系の、
扱い方も気になるところです。
run命令もファイルアクセスの関係で少し不安の残る命令です。
widthはOpenGLで実現しようとすると少しやっかいな命令です。
on...系命令はlparamやwparamに与えられる値の互換性が気になります。
line命令やmes命令でのアンチエイリアシングを許容するか、
あるいはアンチエイリアシングなしを強制するのか気になります。
mmloadやpicloadで扱える形式も環境に依存しそうなので、
その辺りの仕様もあるといいかな、と思います。
dolphilia氏 2016/12/20(Tue) 11:22:32
↑
NO.77690 †
dolphiliaさん、ありがとうございます！
以下、あくまで私の考えですが。
＞ TinyHSPは開発環境を包含するでしょうか。
あればオールインワンで親切ですが、特に開発環境を包含する必要はないと考えます。
エンジンのみの実装、あるいはコンパイラとエンジンのみでよろしいかと。
TinyHSPであることの仕様は最低限(コンパイラとエンジン)でよいと思います。
マルチプラットフォームへの展開をできるだけ楽に、簡潔にするという思惑もあるのですが、
コンパイラとエンジン以外の部分については、作っても作らなくてもかまわない。
そのあたりの充実不実は、実際に個々の環境で開発する方々に委ねていいと思ってます。
ただ、個人的に、専用エディタやヘルプなどはもちろんそろっていたほうが、
ビギナーが始めるときのお手軽さは増すとは思いますし、HSPらしいなーとも思います(^_^)
がそれはそれ、プログラミングの環境を充実させるのは仕様とは別のお話かなと。
いやもう「まとめ」についてもホントにありがとうございます！
我ながら言うばっかりでなかなか動かない人間でもあるので大助かりでございます(^_^)
kikeroga1氏 2016/12/23(Fri) 01:51:17
↑
NO.77728 †
sakuraさん、dolphiliaさん、諸々ありがとうございます。
資料拝見しました。さすがです。素晴らしいの一言です(^_^)
呑気なものでなかなかコメントできないときもあり恐縮ですが、
委細かまわず出来る人にどんどん進めてもらえると幸甚でございます。
＞ WineやVimの環境を利用するのがよいのかなぁと思います。
ちなみにWineはバージョンが上がると以前動いていたものが
動かなくなるというパターンが少なくないと聞いてますが、
大丈夫ですかね？
Linux環境だと安定した過去バージョンで固定するのも意外と
面倒だったりするのかなと思ってたりしますが。
kikeroga 2016/12/26(Mon) 11:57:56
↑
NO.77765 †
kikerogaさん、ご回答ありがとうございます！
RUN命令の件、
思い出があって良いなぁと思います。羨ましいです。
そのような思いは大切にしたいと思っているので、
残す方向に転換したいと思います。
省きたいと思った理由は、私の気まぐれです。^^
palette系命令は、個人的には好きな命令です。
sakuraさん、資料の更新ありがとうございます！
＞ 何かもっとインパクトのあるメリットやアイデアが必要のような気がします。
３つほど案を考えてみました。
1. スマホでゲームが作れる（タブレットPCを含む）
今はパソコンを持たない人もたくさんいます。これが実現すれば、プログラミングを体験していただく良いきっかけになり得ると思います。プログラミングの敷居がぐんと下がるかもしれません。
2. Arduino上で動作する
タイニーさを突き詰める方向性です。フロッピーブートのゲームを作るようなチープな体験ができると思います。
これを実現するには今の仕様では大きすぎるので、構文や命令などを大幅に削減することが必要になると思います。
3. モダンな構文にする
これは逆にHSPをモダンな構文にして、オブジェクト指向などの仕様を取り入れる方向性です。需要は少なからずあると思います。とはいえBASIC風の文法やタイニーさは諦める必要があるかもしれません。ご興味のあるものはあったでしょうか。
dolphilia氏 2016/12/30(Fri) 16:34:37
↑
NO.77766 †
皆さんのアイデアやご意見、色々と参考になります。
話が少しずつ進んでいることを嬉しく思います(^^
誰か中心になる人がいれば進めやすい方法で実現されるといいですね。
何らかの成果や技術のフィードバックができれば、HSP3DishやHSP本体にとっても良い結果になるかと思います。
さくらさん、掲示板ではお久しぶりです。
HSP古株の書き込みを見ることができて嬉しいです。
Tinyな仕様というのは、どこまで切り詰めて、どこまでのアプリを
作成することをイメージするかによって変わってきますね。
さくらさんも書かれていますが、現状のHSP3DishはかなりTinyな仕様で
作られているので、標準命令についてはそちらとある程度変わらない形で実装して
(OpenHSPのソースを使えばかなりそのままで行けそうな気がします)
描画やシステム面での統一を最優先にするというのも1つの形かと感じました。
そして、ポイントはエディタを含めてマルチプラットフォームにする必要がある点で、
ここがクリアできればかなり実現度が高くなるのではないかと思います。
＞dolphiliaさん
macOS版HSPの開発、興味深く拝見しております。
「1. スマホでゲームが作れる（タブレットPCを含む）」が実現できるだけでも、
大きな意義があるのではないかと思います。
もちろんLinuxやMacOSXもアリだと思います。何よりLinuxで動作すると、
raspberry piなどの小型端末でも動作するようになるので、色々な可能性が広がります。
＞これはWeb版HSPに詳しい方にお伺いしたい点なのですが、
＞emscriptenはOS固有のAPI、例えばWin32APIなどは動くのでしょうか。
emscriptenはC/C++の標準ライブラリやOpenGLなどをサポートしていますが、
Win32APIなどWindows固有の仕様には対応していません。
＞OpenHSPからJSに移植する上でのポイントや難所はあるでしょうか。
zakkiさんが作られたHSP3Dishのemscripten版(hsp3js)は、OpenHSPに入っていますが、
描画に関してはOpenGL版とあまり変わりません。
htmlから扱う際のファイルシステムやサウンドの再生には少しクセがあるかと思います。
＞WebAssembly?は実用的でしょうか。
まだあまり詳しく知らないのですが、基本的にはモバイル系などで高速に動かせるよう
今後普及を目指していくような状態ではないでしょうか。
emscriptenなどと同様に汎用的なライブラリをターゲットに作っておけば、将来的に対応はできるのではないかと思います。
おにたま氏 2016/12/30(Fri) 18:14:53
↑
NO.77771 †
皆さん、本当にありがとうございます。
おかげ様で想定以上の意見交換の場になってきました。
＞ 資料を整理していて思ったのですが、HSP3Dishやコンパクト版(hsp3c)と変わらなく
＞ なっていくのではないと思うのは、私だけでしょうか?
sakuraさん、まさにそこです。
誰かがそのうち疑問を呈しそうだと思っていたところを
ご指摘頂き、ありがとうございます。
もし元々 hsp3dish や hsp3c がマルチプラットフォームを意識した仕様なのであれば、
tinyhsp にとってかわってもよいと思いますが、Linuxのディストリビューションのごとく
その仕様は異なる目的で策定されており、似て非なるものです。
TinyHSPの制約上で作れば"どの環境でもソースの修正なしで動く"
完全互換という仕様を明示することこそ、TinyHSPのキモなのです。
例えばWindows版、Linux版、MacOS版、hsp3dishなど、それぞれの環境で
「最初から各環境で動くように命令を調整して作ればいい」と作ったものは
あれこれ気を使って作る必要があります。ライトユーザはやらないでしょう。
この命令だけ使ってこうやって作ればいいよーという互換性維持の開発メソッドを公開してもよいかもですが、
どうせならTinyHSPという仕様を作って「TinyHSP配下で作ればどの環境でも動く」と明示しちゃったほうが
わかりやすいし、そんなものがあったら欲しいよなーと思ったのが、この提案の発端なのです。
これは実は(特にライトユーザには)大きな印象を与えると私は感じているのです。
現状の各環境版HSPでこんな感じの互換レベルになってるのを
Windows ≒ macOS ≒ Linux ＞ Android/iPhone
TinyHSPでは"明確に"こう示したい
Windows ＝ macOS ＝ Linux ＝ Android/iPhone
と思っているのです。
＞ dolphiliaさん
RUN命令の件、ありがとうございます(^_^)
感激です。
以下はかなり意義の高いアプローチになりそうですね。
＞ 1. スマホでゲームが作れる（タブレットPCを含む）
＞ 2. Arduino上で動作する
おにたまさん、コメントありがとうございます！
＞ ポイントはエディタを含めてマルチプラットフォームにする必要がある点で、
＞ ここがクリアできればかなり実現度が高くなるのではないかと思います。
エディタを含めてというのは望むべくもないですが、
仕様として含めてしまうと開発の負荷が高いかなと考えていました。
＞ 現状のHSP3DishはかなりTinyな仕様で
＞ 作られているので、標準命令についてはそちらとある程度変わらない形で実装して
＞ (OpenHSPのソースを使えばかなりそのままで行けそうな気がします)
おっしゃるとおりTinyHSPの仕様を前提にベストなやり方ができれば良いと思います。
開発の労力は少ないに越したことはありませんよね。
ちなみに、例えばですが、既存の各環境版HSPで hsp3c のごとく
#include "tinyhsp"
とかして作れば各環境で完全互換になるなら、そんな実装でもＯＫだと思ってます。
いずれにしてもその仕様準拠で動く各環境版のコンパイラとランタイムが必要になるわけですが、
あれこれ検討・模索しながらも楽しみながら進めていければ理想でございます。
kikeroga氏 2016/12/31(Sat) 08:46:23
↑
NO.77773 †
dolphiliaさん、コメントありがとうございます。
＞1. スマホでゲームが作れる（タブレットPCを含む）
＞プログラミングの敷居がぐんと下がるかもしれません。
HSP一式のアーカイブをダウンロードしてインストールして
スクリプトエディタを起動し、適当なサンプルを読み込んで
少しいじくれば短時間で、それなりのものが作れるという簡便さ
はあります。
でも、少し実用性のある見栄えのするものと作ろうとするとそれなりに
学習コストは高いように思えます。
これは、どの言語にも言えるのですが・・・・
スマホでゲームが簡単に作れるようにする仕様が浮かびません(^^;
＞2. Arduino上で動作する
マルチプラットフォーム化は、今後のHSPの活躍の場を広げる意味では良いことと
思います。
HSP3Dishで既に実現しているので、Dishの今後の拡張等に期待したいですね。
＞3. モダンな構文にする
構造化等には魅力を感じますが、HSPの開発初期からの言語思想に反するように
思えるのでちょっと賛成しかねます。
個人的にはいずれにしても、Tinyなものにするには、大幅に命令等を削って
超高速化や軽量化した利用用途を限定したものが良いように感じます。
たとえば、ゲーム開発だけに特化するとか、入門用の言語教育に使える簡便なものとか、
可能であれば中間言語方式ではなく本格的なネィテブコードのコンパイラにするとか(^^;
おにたまさん
コメントありがとうございます。
20年以上もサポートして頂いていることにユーザーの一人として感謝致します。
私自身は、今はもうほとんどHSPでプログラミングをすることもないのですが
今後、どのように進化・発展していくのかが楽しみです。
kikerogaさん、コメントありがとうございます。
さて、どんな仕様にまとめられるか・・・・
他の方の意見がほしいところですね。
sakura氏 2016/12/31(Sat) 11:24:15
↑
NO.77775 †
Windows = macOS = Linux = Android/iPhone ( = Web)といった多くのプラットフォームとの
互換性がソースレベルでも保て、難しい命令(?)もけずられていることで
初心者や学生でも学習できる簡単な言語がさらに簡単に学べるようになり、
さらには中・上級者は多プラットフォームへの移行も簡単にできそうな、
ぜひ実現してほしいHSPの形だと思いました。
＞ 1. スマホでゲームが作れる(タブレットPCを含む)
スマホなどでもゲームなどが作れる。これが実現すれば「簡単に学習・使用」ができるHSPが
さらに簡単に使用できるようになって私はとてもいいと思います。
くちくん氏 2016/12/31(Sat) 12:19:44
↑
NO.77805 †
明けましておめでとうございます！
資料を更新しました。
ダウンロード
↓
http://hspnext.com/download/hsp_commnd_20170101_11a.zip
dolphiliaさん、コメントありがとうございます。
＞こうしてみるとHSPの言語仕様は想像以上に大きいのですね。
HSPは、ちょっとスキルがあれば何でも出来てしまう恐ろしい仕様なんですね(笑)
＞TinyHSPをより軽量化するにあたって、
＞こうしたらいいんじゃないかというような、
＞アイデアはおありでしょうか
今は、ちょっとアイデアは思い浮かびません。
本題のテーマである軽量化、クリーンなHSPから外れますが個人的な興味として、
高速に大量のデータ処理ができたり、HSPの優れたグラフィック処理を
利用したデータ分析に応用できたりする強力な専用エンジンがほしいです。
まあ、これはアプリの領域なんですが・・・
現状のHSPでも十分ですけどね。
d3moduleではなくて、d3.jsに匹敵するようなもの、誰か作ってくれませんかね(^^);
余談ですみませんでした。
くちくんさん、ご意見ありがとうございます。
＞互換性がソースレベルでも保て、難しい命令(?)もけずられていることで
＞初心者や学生でも学習できる簡単な言語がさらに簡単に学べるようになり、
＞さらには中・上級者は多プラットフォームへの移行も簡単にできそうな、
＞ぜひ実現してほしいHSPの形だと思いました。
HSPの原点回帰という点で目指すべき方向性と思います。
sakura氏 2017/1/2(Mon) 08:23:32
↑
NO.77817 †
新年おめでとうございます
自分も言語作成している身でして、そういう面から書き込みします
http://zuzazann.boy.jp/wiki/index.php?HSPソース投稿Wiki
HSPソース投稿Wikiとでっちあげて 8割がた自分ばかり更新してます
（嬉しいことにちょこちょこ利用者さんはいます）
書き始めて2年くらい経ちましたが 実はそんなにやってるようなやってないような。です
自分なんかは仕様が固まってなくて行き当たりばったりでやってます
仕様はオリジナルでやるよりＨＳＰにならおう。とは思ってますが
YACCを採用してスクリプト言語的にしよう。とか 初期から構想に入ってなくて
後付けでどこまでいけるかわかんなかったりしてます
ライブラリがちょっと考えどこで
軽くJAVAのライブラリを使おうか軽くTcl/Tkを使おうかサーバーサイドにして
軽くブラウザチックにしようか 軽くHSPをエミュレートしようか色々考えています
GUIは好きなんですけど 考えると自分、そんなに高速描画しないので
軽く使えれば十分なんですよね
そういう意味ではライブラリは転用させて欲しくあります
Tinyと読むと変数が１字とかユーザー作成サブルーチンが使いにくそう。とか
そっちの軽量のようで違うっぽくもあるので 誤解を招きそうで確かに違う名称がふさわしそうですね
自分的にはOPEN HSPのソースコードの量がものすごくて理解しきれないので
全部で１万行くらいのプログラム言語作成学習用であったらなあ。と思います
それくらいの言語が少ないのか 自分の検索が下手なのかあんまり見ないです
自分は仕様を決めるにしてもWEBに決めたことを載せちゃうと実行しないので
そういうのやめましたが
それをあえてすることで協力者が出てくるのはすごい現象ですねｗ
結局、仕様を決める人と実装する人の役割分担をしちゃうくらいの勢いでないと
辛そうですね。そこまでの仕様の具体化具合は
ホラONITAMAさんだって実装前にそういうことあまり言わないでしょ
なので新機能を語るスレ。とか建てたい勢いでもあるくらいです
自分としてはプログラム言語作成をもたもたやってるそばからビュンビュン追い抜かれていって
寂しくもあるし、自分の才能のなさがふがいなくもあります
そういう時は結果より過程が大切さ。とか
やることに理由なんていあらない。とか偉い人の言葉を思い出すしかないっすよ
みたいなかんじに応援しております（どんなだｗ）
Y_repeat氏 2017/1/3(Tue) 08:08:27
↑
NO.77818 †
そう言えば HSPの方針については あまり議論がされてないみたいだったので
そういう議論もあっていいかもですね
ONITAMAさんも参加されていることから
tinyHSPが実現せずともこの議論にすでにフィードバックしている部分もあるかもしれませんね
dishの仕様とかも未だ流動的かもしれませんし
Y_repeat氏 2017/1/3(Tue) 08:18:26
↑
NO.77819 †
自分の黒歴史的に某ゲームの掲示板の常連だった黒歴史がありまして
意見はしても自分で作る訳ではないもどかしさがあったので
プログラミングを再開させたんですが
自分はなくても大丈夫みたいなスタンスで論じてしまうので
ってかそんなんだからあんまり議論の火蓋はきらなかったんですが
たぶん仕様を決める人も大事で
ってか時に作業をする人より上に置かれるくらい
なので貫きたいことがあったら 叩かれても曲がらない釘のごとく
貫いて欲しいですね
自分は結局叩かれると曲がってしまう釘のようなので
Y_repeat氏 2017/1/3(Tue) 08:31:24
↑
NO.77822 †
HSPはもともと難しい前準備なしにエディタを起動して、いきなりソースを打ち込んで使える簡便さが大きな魅力でした。
ライブラリが肥大化したことで、できることは増えたのですが、どの機能を使っていいか、どの命令がプラグインに依存しているかなど
混乱する要素も増えてきていると感じています。何とかするべき所だとは思っていますが(^^;
そういった意味では、初心者やちょっとした用途で汎用的に使えるシステムは、制約はあるものの原点に戻ってシンプルさがあって一定の需要があると考えています。
＞sakura さん
＞20年以上もサポートして頂いていることにユーザーの一人として感謝致します。
ありがとうございます!
素晴らしい資料の作成、相変わらずの良い仕事ですね。
命令を削って軽量化という方向も間違っていないと思います。
＞dolphilia さん
＞フィードバックする方法には、
＞具体的にどんなものがあるでしょうか。
ソースコードが公開されていれば、有用なコードや変更はこちらでOpenHSPに取り込むことが可能です。
また、TinyHSPなど他のランタイムと共用して修正のしやすい形でOpenHSP側のソースコードを変更するなどのフィードバックもできるかと思います。
機能の拡張よりも、最小限に削ってまとめることの方が難しい作業だとは思いますが、
必要なものを見極めた上で大胆に削って、限定した形になることを願っています(^^
ちなみに、私もpalette系の命令は愛着がありますが、最近のビデオカードやマルチプラットフォーム化を考えると余計なものになっていると思います。
おにたま氏 2017/1/3(Tue) 10:59:01
↑
NO.77852 †
Academic HSP
VSにAcademic版があったのと
学習用言語 プログラム言語作成学習用 の用途を想定して
でも結局一番貢献した人に決定権がある気がします
＞TinyHSPはオープンソースで、
＞Githubで開発するようにしてみます。
＞上記のTinyHSPは私の遊び心も入ってしまっているので、
＞このスレッドで検討されている「クリーンなHSP」は、
＞じっくりと仕様を検討していければいいな、と思っています。
仕様書に変数は一字とか書いてて思いっきり仕様がTinyBasic?になってて
焦りましたが 別のプロジェクトなんですな
TinyBasic?もGPLが多くて
いや別ライセンスで配布して 暗号かけた版みたいな
HSPみたいな配布形態にしたくて
BSD版もあるみたいなんですけどもｗ
完成したら研究させていただきますｗ
「クリーンなHSP」にガッチリ参加してもいいんですけど
自分書き方がボトムアップで
ifの段階でif x thenになってしまっているのでｗ
#{にする決定が下せないｗ
しかも中間言語で既に２年くらい経過している１０年計画必須でｗ
この具体化具合はもっとスピード感がある人がふさわしいと思います
LinuxもUbuntuちょっと触った具合で
何が移植性あって何が移植性ないのかわからなく
そういう意味では言語を作成する人とライブラリを作成する人を分けた方が良さそうですね
というかHSP3CLは結構行数かかってる印象なので
言語仕様と実装をスリム化させたら
言語としては十分な感じもします
全部で一万行くらいで どうかｗ
短くなったけどその分ややこしいとかじゃなく
ややこしさもせめて現状で
＞HSP処理系ではないのですが、こういうのはいかがでしょうか。
近いうちに見てみますねー
豊四季tinybasicは最近、書籍買いましたです
自分としては
HSPのHSPCMP.DLLとか（たしか）
「プログラミング言語を作る」書籍情報のサンプルとか（ちゃんと書籍買いましたｗ）
http://kmaebashi.com/programmer/devlang/book/index.html
「いまどきのプログラム言語の作り方」書籍情報のサンプルとか（ちゃんと書籍買いましたｗ）
http://d.hatena.ne.jp/yaneurao/20051031
とか書写してます。読むのも打ち込むのも辛いのでｗ
tinyBasicもちょこちょこ写経とか書写とかしてます
Y_repeat氏 2017/1/6(Fri) 01:21:40
↑
NO.77853 †
資料を更新しました。
↓
http://hspnext.com/download/hsp_commnd_20170106_11b.zip
kikerogaさん
＞名称はイメージが大事だと思いますので、他の方の意見も欲しいところです。
ネーミング(案)に参加します(^^;
HSP Best
↓
Basic Enjoy Script Training
- - -
└ or Try
＜基本ポリシー＞
基本的なスクリプトを利用して楽しみながら学習(挑戦)する。
Learn While enjoying Using basic script
dolphiliaさん
＞TinyHSPはオープンソースで、
＞Githubで開発するようにしてみます。
＞https://github.com/dolphilia/tinyhsp
ちらっと、拝見しました。仕事の取り掛かりが速いですね。どんな形になるか
楽しみにしています。
＞私もHSPに正規表現が標準で搭載されたら良いなとか、
＞深層学習やVR・AR技術を実行できるようなエンジンがあれば良いな、
＞なんて考えたりします。
HSPが世界に羽ばたけるような実務に密着した実用性の高いものになると良いですね(笑)
おにたまさん、コメントありがとうございます。
まあ、どれだけサポートが出来ているのかわかりませんが、資料は整理しておくと
誰かの役に立つのかもしれません。
このスレッドを楽しんでやっています。
sakura氏 2017/1/6(Fri) 21:03:10
↑
NO.77857 †
現在の名称を仮称とすれば良いのでは？
色々議論するのも良いのですが、取りあえず土台とし
て極簡単な物を作るのが最優先だと思います。
仕様を固めた上で作るのは当然重要ですが、ある程度
作り込んでテスト公開したら動作不良ばかりで、修正
を繰り返したらソースがスパゲティーになって訳が分
からない状態になったり、もしかしたら開発環境自体
を考え直す必要になるかも知れません。
互換性を担保出来る最小限の命令や関数だけなら、ま
ず不具合も無いだろうし問題が有ってもキズは浅くて
済みます。あとは段階的に命令を増やして最終目的に
持って行きます。
それと人間の欲求に限りは有りません、特に多数の意
見を求める場合は、目標を高く設定することになりが
ちです。暫定仕様として一旦線引きするのも重要です。
暫定目標としてはＨＳＰ２相当の命令・関数から、マ
クロ定義されている物や、特殊な使い方が必要なもの
（極端に言えばプリプロセッサ全て）を消せば、相当
シンプルな物しか残らないでしょう。この辺りを暫定
目標として話を進めた方がスムーズに行きそうな気が
します。
KA氏 2017/1/7(Sat) 19:19:40
↑
NO.77860 †
KAさん
＞色々議論するのも良いのですが、取りあえず土台とし
＞て極簡単な物を作るのが最優先だと思います。
進め方としての、ご意見に賛成ですが、実現の可能性は別として
色々議論する過程を楽しんでいる人も多いのではないかと思います。
＞暫定目標としてはＨＳＰ２相当の命令・関数から、マ
＞クロ定義されている物や、特殊な使い方が必要なもの
＞（極端に言えばプリプロセッサ全て）を消せば、相当
＞シンプルな物しか残らないでしょう。この辺りを暫定
＞目標として話を進めた方がスムーズに行きそうな気が
＞します。
同感です。今回のTinyHSPの目標実現としてはHSP2相当が良いと考えます。
しかし、極端に命令が少ないと作れるものも制限されるし、
少し、いいものを作ろうとするとかなりのスキルが要求されるように
思えます。HSP2時代の初期の頃も、拡張プラグインに頼っていましたね。
資料更新しました。(ほぼ、最終更新版となります。しばらく、更新しません。)
↓
http://hspnext.com/download/hsp_commnd_20170107_11c.zip
sakura氏 2017/1/7(Sat) 22:10:13
↑
NO.77862 †
sakuraさん
その「楽しむ」が、それで終わりに成らないと良いんですが・・。
過去、方向性は異なりますが、似たような考えで立ち上げたサイト
が殆ど機能していない現実問題として、「なぜ機能していないのか」
を分析してみる必要はあると思います。
ＨＳＰ２相当と言ったのは、あくまで開発者側の立場で「暫定」とし
ています、当然利用者側から不満は出てくるでしょう。その不満を元
に適時バージョンアップし、不具合を修正していくという意味合いで
す。
話の途中で水を差したくは無かったのですが、似たような過去の失敗
を教訓として今後に生かす姿勢はほしいです。
毎回文句（イチャモン）ばかり言っていますが、今回のプロジェクト
に否定的な訳ではありません。議論をまとめるのなら閑古鳥の鳴いて
いるサイトを再利用したり、論点が多肢に渡るのなら論点毎にＷＩＫ
Ｉ形式にするなど、やりやすい方法はあると思います。
この読みやすいとは言えない掲示板で、あれやこれや議論が飛び回っ
ていては、読みにくくて仕方がありません。
辛辣（かな？）な書き方ですが、何かの参考になれば幸いです。
KA氏 2017/1/8(Sun) 00:43:54
↑
NO.77863 †
KAさん
コメントありがとうございます。
＞その「楽しむ」が、それで終わりに成らないと良いんですが・・。
終わりになる可能性は否定しません。
私も、過去このようなブロジェクト的なものを多く見てきましたが
うまくいったものは、ほとんど知りません。
＞毎回文句（イチャモン）ばかり言っていますが、今回のプロジェクト
＞に否定的な訳ではありません。
危惧されていることや、HSPに対する気持は発言から十分読み取れます。
貴重なご意見、ありがとうございます。
まあ、たまには今回のようなスレッドでの議論も良いのではないでしょうか?
議論の成り行きにイライラする人もいるのかもしれませんが・・・・
KAさんの見識で力を貸して頂ければ、ここに参加している皆さんも力強いと
思うのですが・・・・
sakura氏 2017/1/8(Sun) 08:24:20
↑
NO.77867 †
とりあえずCで使うライブラリの開発は始まってどうでしょうか
ってやる人いないのかな？
とりあえず
言語としてはＣ言語まんま（開発後回し）で クリーンＨＳＰのライブラリを使用
ってかんじでどうでしょうか？
それでもある程度ＨＳＰ感覚で開発できるでしょうし
自分の中間言語もまったくライブラリ書いてないので
そういうのがあると非情にありがたいです
自分の中間言語はそろそろＣに移植かな？って思ってるとこです
gosub的サブルーチンを実装すれば 中間言語としてはある程度完成です
配列もまだ実装してないか
＞＞その「楽しむ」が、それで終わりに成らないと良いんですが・・。
＞終わりになる可能性は否定しません。
＞私も、過去このようなブロジェクト的なものを多く見てきましたが
＞うまくいったものは、ほとんど知りません。
面白そうな企画なのですが
この書き込みを見て心配にはなりました
Y_repeat氏 2017/1/8(Sun) 22:38:34
↑
NO.77869 †
Ｃで開発するならＣで開発するとして
新しい言語を開発するのではなく
Ｃスクリプトを生成するかんじだとどうでしょうか
ってＨＳＰＣもそんなかんじでしたっけ？
動けばいいってんじゃなくて
生成後のスクリプトも人間が読みやすいかんじでお願いします
自分の中間言語も親言語記述をそのまま受け入れようと思っているのですが
仕様がなかなか固定しないですね
現状、自分しか使えない。みたいなｗ
自分でも上手く動かし方がよくわかってない。みたいなｗ
機械的に決まってる仕様をエデイタ的ツールでカバーしようとは思っているのですが
Y_repeat氏 2017/1/8(Sun) 22:53:18
↑
NO.77871 †
sakuraさん
言いたくは無いけどつい言ってしまう性分で、自覚は
していますが中々直らない物です。
私の見識など何の役にも立たないと思いますが、書く
と長くなるので、しばらくは静観します。
KA氏 2017/1/8(Sun) 23:45:31
↑
NO.77885 †
Y_repeatさん
＞言語としてはＣ言語まんま（開発後回し）で クリーンＨＳＰのライブラリを使用
＞ってかんじでどうでしょうか？
＞それでもある程度ＨＳＰ感覚で開発できるでしょうし
＞自分の中間言語もまったくライブラリ書いてないので
＞そういうのがあると非情にありがたいです
私は、C言語は昔、HSPの拡張プラグインを作成する時に少しだけ
かじった程度の素人同然ですが、2004年当時、似たようなことができないかと
試行錯誤したことがあります。
過去のフォルダを探してみたら、ゴミみたいのものですが、
参考になるかどうかわかりませんが、ソースがありました。
必要な部分を部品として活用して頂けたら、ありがたいです。
あまりに幼稚な書き方でみなさんに笑われるかもしれませんが、アップ
しておきます。
http://hspnext.com/download/HSP参考程度のゴミソース.zip
＞面白そうな企画なのですが
＞この書き込みを見て心配にはなりました
すみません。何か心配させるようなことを書いて・・・・
KAさんと同様、このプロジェクトがうまくいってほしいという
思いを理解して下さい。
KAさん
コメント、ありがとうございます。
＞言いたくは無いけどつい言ってしまう性分で、自覚は
＞していますが中々直らない物です。
私の個人的な見解ですが、物事の本質を見極めての発言と理解しています。
なかなか、本質や本音を言える人が少なくなっているので、・・・・
kikerogaさん
＞少なくともこのスレッドを立てた意義は想定以上に大きかったようで
＞良かったと思っています。
＞あとはもう成るようになるでしょう！(^o^)
もう少し、がんばってみますか(^^;
sakura氏 2017/1/9(Mon) 14:23:34
↑
NO.77891 †
下記、大変失礼しましたm(_ _)m
誤）おのたま氏
正）おにたま氏
＞ もう少し、がんばってみますか(^^;
sakuraさん、
貴重なソースを公開して頂き、ありがとうございます。
勉強させて頂きます。
私も何か心配させるようなことを書きましたかね(^^;
ネットの発言は温度感が難しいですが
「もうヤメましょう」という意味合いではないので
今後ともよろしくお願いします。
kikeroga氏 2017/1/9(Mon) 16:57:09
↑
NO.77899 †
kikerogaさんへ
＞このスレッドは"TinyHSPの提案"として立てましたが、
＞・おのたま氏がコメントし、そのプロットと意義を認めてくれたこと
＞・sakuraさんが大変素晴らしいベースドキュメントを作成してくれたこと
＞・dolphiliaさんがtiniyhspのプロジェクトを開設してくれたこと
＞と十二分な成果を果たしており、その役割を終えているように思います。
＞今以上に論議を発展させる場所としては、ご指摘の通りWikiやその他の仕組みで
＞進めるほうが適切だとは思いますが、これから先のことも、私自身も含めて
＞何がどうなろうと、誰かができることをやるだけです。
＞少なくともこのスレッドを立てた意義は想定以上に大きかったようで
＞良かったと思っています。
そうでしたね。ここのスレッドは"TinyHSPの提案"というタイトルでしたね
そういうタイトル的には結構役目を果たせたかもしれません
ではこのスレッドを受け次のスレッドを立てて欲しいなあとも思います
僕もwikiを立てましたが僕のwikiなんてたいして訪問者いないでしょう
なので引き続き公式BBSで議論をするなら続けて欲しくあります
自分もプログラム言語作成を目標としてやってる身としては実りありましたので
僕の今年は10年計画の3年目くらいとしての目標は
ドラゴンブックを購入して読破する！ですｗ
言語開発者としてこの書籍を読破していない人はモグリと某書籍に書いてあったので
いつか読まなきゃなあと思っていたところです
RHGも2014に購入して読破していない僕ですが
せめて購入して一か月につき一章づつ読む。を今年の抱負にします
Y_repeat氏 2017/1/10(Tue) 07:30:29
↑
NO.77902 †
この企画には大変肯定的です。
だからこそ言わずにはいられないのですが、すでに話にも出ているように、
ここでこのまま議論を続けるのはよい選択ではないように思います。
口の悪い言い方になってしまいますが、
現状はこの企画とは直接関係のない話題が飛び交いすぎていて
(それが悪いことだと言うつもりはありませんが)、
このままでは雑談スレッドに成り果ててしまう気がしてなりません。
専用のフォーラム等を設け、問題点をピックアップして
個別に解決してゆくような形になれば、
もっと議論の内容が把握しやすい状態で話が進むのではないでしょうか。
現状どういう問題について決め兼ねているのかを把握しやすくなれば
それぞれの問題の解決手段について意見する人ももっと増えるはずです。
HIJIKI氏 2017/1/10(Tue) 13:17:09
↑
NO.77903 †
そんなことを言っておきながら、
企画自体には何の意見も残さずに退場するのはどうかと思うので、
遅ればせながら、そして拙い意見ですが期待の表現ということで書かせていただきます。
■言語の名称について
これは皆さんが既にたくさん良い物を提案されてますので、
以下はあえてセンスのない頭で別の観点から捻り出したものです。
(逆に言うと、センスのない者にしかできないかもしれないのであえて書かせていただきました。)
・MyHSP (自分の物と言えてしまうくらい小型で見通しが効くという意味で。)
・HSPCore (中核のみが実装されているという意味で。)
・HandyHSP (手のひらサイズのHSPという意味で。)
・PalmHSP (同上。英語ではHandyが[便利な]や[有用な]と取られてしまうようなので。)
・PalmSizedHSP (同上。略さず表記したもの。略称が[PSHSP]となり回文で面白いと思ったので。)
・HSP-- (デクリメントされたHSPという意味で、C++に対するHSP--。ただ字面が見づらい。)
・HSP-1 (同上。字面を考慮。HSP1と混同しかねない？)
・HSP-=1 (同上。)
・HSP0 (ゼロに戻ったHSPという意味で。ゼロがオーに見えるかもしれない。)
・HSPZero (同上。見間違いを考慮。)
■言語仕様について
ソースコードを変更することなく、あらゆる環境で同じ動作をする HSP の機能縮小版
ということだと認識しているので、その前提で書かせていただきますが、
もし私の認識が違えば教えていただけると幸いです。
削る命令と残す命令の水準は、代替手段があるかというのはいかがでしょうか。
例えば、stick命令はgetkey命令で代用が効くので両方は不要である、など
本家HSPの命令や機能のうち、企画仕様上再現可能なものを全て移植するのではなく、
文字通り必要最低限に抑えるほうがこの企画の魅力をより高めると思います。
それで言うと、HSPに標準でマクロとして定義されている命令も不要ということになり、
この辺りは意見が割れそうですね。
記法については、
本家HSPのソースコードを(記述されている命令が対応していれば)、
また逆に、「クリーンなHSP」で記述されたコードを、本家HSPにも
そのまま流用できることが望ましいと思います。
そうすれば「プログラミングの入り口」の前の「HSPの入り口」として学習用に十分に力を発揮するほか、
今までHSPを利用してきたユーザーも(追加学習も必要なく)案件によって
使い分けることができて良いのではないでしょうか。
長くなりましたが、何かの参考になれば幸いです。
この企画の成就を心よりお祈り申しあげます。
HIJIKI氏 2017/1/10(Tue) 13:35:57
↑
NO.77904 †
こんにちわ
自分のとこのmediawikiですが
デフォルトでもハイライトしてくれて頼もしいんですが
自分が利用しているロリポップの鯖は
データベースが一人一つしか運営出来ないみたく書いてるとこがあって
mediawikiは一つしか運営できないっぽいです
という訳でせっかくのmediawikiですので もっと活用したいですね
というところで
次のスレッドを立てるとしたら どういう趣旨のスレッドにすべきか
そういう話もした方がいいのではないか？と思います
このスレッドは TinyHSPの提案 ということで「提案・要望」スレッドとなっています
＞このままでは雑談スレッドに成り果ててしまう気がしてなりません。
という懸念をHIJIKIさんが持たれているようなので
逆に最初から「雑談」スレッドとして立ててみてはどうでしょうか
とはいえあまり重要ではない雑談は自分のとこのwikiでってことでお願いします
dolphiliaさんのtinyHSPも開発の途中経過とか
更新履歴削除って書いてましたが
せっかくなので更新履歴はUPし続けて欲しいですね
開発の提案だけして 梯子を外すみたいなのは悪いなあ。と思いませんか？
後はさくらさんがドキュメントをもう少し加筆するようなので
それも期待出来ます
自分も言語作成をテーマにプログラミングしてる身としては
モチベーションの上がる小論文（＝エッセイ）の執筆お待ちしています
このスレッドと連携して今年の抱負とか書いてもいいですし
今後半年の抱負でも４半期の抱負でも今月の抱負でも
展望によって抱負の期間はお任せします
自分のとこのwikiに関する意見もありましたら
そういう話も出ていいと思います
他にも次のスレッドで 議論したいテーマがありましたら
書き込みましょう
という訳で 次のスレッドお待ちしてまーす
２、３日くらい間をあけて 誰も次のスレッドを立てないようでしたら
僕が「雑談」スレッドを立てます
Y_repeat氏 2017/1/10(Tue) 14:13:47
↑
NO.77905 †
KAさんの助言に従い ここのとことかの まとめサイトなwikiを開設しました
http://zuzazann.boy.jp/media_wiki_120/index.php?title=メインページ
・運営方針 ちょいちょい変更してますｗ
Y_repeat氏 2017/1/10(Tue) 17:07:15
↑
NO.77908 †
HIJIKIさん、ご賛同ありがとうございます。
欲しいですよね、こんなHSP(^_^)
名称に関しては色々候補を出しておいて、実際には
開発する方が気に入ったものを付けてくれればよいかと
私は思っております。
Y_repeatさん、色々ありがとうございます(^_^)
TinyHSPの話題が継続されるのは良いことだと思います。
次のスレッド、お任せいたします。
kikeroga氏 2017/1/11(Wed) 11:44:34
↑
NO.77916 †
スレッドのタイトルは少々考えてたんですけど
「HSP討論会」「タグ：雑談」でどうでしょうか
討論をtinyHSP及びクリーンHSPに限らず
せっかくなのでHSP全般に関する討論もあっていいんじゃないでしょうか
スレッドの内容は
tinyHSPに関すること クリーンHSPに関すること HSPに関することでしてみたかった意見
小論文（エッセイ） エッセイの日本語訳は「小論文」みたいですｗ
雑談：今年（今月）の抱負 ロールモデル
その他のご意見
ということで予定しています
Y_repeat的には HSP公式BBSのまとめサイトをなんとなくやってみたい気がしてました
しかし HSP公式BBS には書き込みが まとめるには多すぎるかんじがしてたので
特定のスレッド内の書き込み限定なら出来るかもしれない。という後付けがあったりｗ
Y_repeatは雑誌が結構好きなので
（最近はちょいちょいしか読んでないですが そもそもものすごい読んだ時期もなかったりｗ）
WEB MAGAZINE感覚でwikiを運営していけたらなぁと思います
そして せっかく関連wikiを運営するなら 対象を割と広くしても面白いかもしれないかな。と思いました
ということで
「せっかくなのでHSP全般に関する討論もあっていいんじゃないでしょうか」と書きました
Y_repeat的には今回はなるべく裏側から支援したい気持ちがありまして
裏側から支援する意味でまとめサイトも作ったんですが
スレの後半あたりから 前に出過ぎな気もする残念感ｗ
＞kikerogaさん
ほめてただいたりして こっぱずかしいですｗ
Y_repeat氏 2017/1/12(Thu) 00:42:02
少しでも助けになればと思い、コメントします。
Mac版HSPを作った際の、
OpenHSPのLinux版からコンパイラとエンジンを分離したソースが残っていました。
コンパイラ：
https://github.com/dolphilia/hspcmp-macosx/tree/master/01_start/src
エンジン：
https://github.com/dolphilia/hsp3cl-macosx/tree/master/01_start/hsp3cl
（コンパイラはこのままmakeすればOKで、エンジンの方はmakefileを書き直す必要があります）
ほとんどの命令・関数が、
hsp3gr.cpp（描画系）
hsp3int.cpp（関数など）
で定義されています。
ご参考までに。
仕様の方、拝見しました。
オブジェクト制御命令はごっそり削ったんですね。
これなら実装はかなり容易なはずです！
描画部分はHSP3DishのようにOpenGLでいけるので、
モバイル対応もすんなりいけそうです。
（あるいはHSP3DishがTinyHSPに準拠しているとも言えなくもないですね）
以下は要望です：
screen命令での新規画面生成は、
Macやモバイルではかなり苦しいので、
その辺りの仕様は、お手柔らかにお願いします。
（第一パラメーターを廃止あるいは非推奨に・・・）
syscolorやsysfontの互換性も悩ませるところです。
システム依存の色やフォントの違いは、許容範囲だと助かります。
mouse命令は便利ですが悪用されると面倒な命令なので、非推奨の方向で・・・。
getkeyやstick命令は、
デスクトップとモバイルでの互換性が気になります。
最近はマルチタップも普通になってきたので、
その辺りをどうするかも。
あとモバイルは基本的にファイルへのアクセスをある程度制限をしてるので、
notesaveやbsaveやbmpsave、
bloadやnoteloadやmmloadやpicloadなどファイルアクセス系の、
扱い方も気になるところです。
run命令もファイルアクセスの関係で少し不安の残る命令です。
widthはOpenGLで実現しようとすると少しやっかいな命令です。
on...系命令はlparamやwparamに与えられる値の互換性が気になります。
line命令やmes命令でのアンチエイリアシングを許容するか、
あるいはアンチエイリアシングなしを強制するのか気になります。
mmloadやpicloadで扱える形式も環境に依存しそうなので、
その辺りの仕様もあるといいかな、と思います。
dolphilia氏 2016/12/20(Tue) 11:22:32
↑
NO.77690 †
dolphiliaさん、ありがとうございます！
以下、あくまで私の考えですが。
＞ TinyHSPは開発環境を包含するでしょうか。
あればオールインワンで親切ですが、特に開発環境を包含する必要はないと考えます。
エンジンのみの実装、あるいはコンパイラとエンジンのみでよろしいかと。
TinyHSPであることの仕様は最低限(コンパイラとエンジン)でよいと思います。
マルチプラットフォームへの展開をできるだけ楽に、簡潔にするという思惑もあるのですが、
コンパイラとエンジン以外の部分については、作っても作らなくてもかまわない。
そのあたりの充実不実は、実際に個々の環境で開発する方々に委ねていいと思ってます。
ただ、個人的に、専用エディタやヘルプなどはもちろんそろっていたほうが、
ビギナーが始めるときのお手軽さは増すとは思いますし、HSPらしいなーとも思います(^_^)
がそれはそれ、プログラミングの環境を充実させるのは仕様とは別のお話かなと。
いやもう「まとめ」についてもホントにありがとうございます！
我ながら言うばっかりでなかなか動かない人間でもあるので大助かりでございます(^_^)
kikeroga1氏 2016/12/23(Fri) 01:51:17
↑
NO.77728 †
sakuraさん、dolphiliaさん、諸々ありがとうございます。
資料拝見しました。さすがです。素晴らしいの一言です(^_^)
呑気なものでなかなかコメントできないときもあり恐縮ですが、
委細かまわず出来る人にどんどん進めてもらえると幸甚でございます。
＞ WineやVimの環境を利用するのがよいのかなぁと思います。
ちなみにWineはバージョンが上がると以前動いていたものが
動かなくなるというパターンが少なくないと聞いてますが、
大丈夫ですかね？
Linux環境だと安定した過去バージョンで固定するのも意外と
面倒だったりするのかなと思ってたりしますが。
kikeroga 2016/12/26(Mon) 11:57:56
↑
NO.77765 †
kikerogaさん、ご回答ありがとうございます！
RUN命令の件、
思い出があって良いなぁと思います。羨ましいです。
そのような思いは大切にしたいと思っているので、
残す方向に転換したいと思います。
省きたいと思った理由は、私の気まぐれです。^^
palette系命令は、個人的には好きな命令です。
sakuraさん、資料の更新ありがとうございます！
＞ 何かもっとインパクトのあるメリットやアイデアが必要のような気がします。
３つほど案を考えてみました。
1. スマホでゲームが作れる（タブレットPCを含む）
今はパソコンを持たない人もたくさんいます。これが実現すれば、プログラミングを体験していただく良いきっかけになり得ると思います。プログラミングの敷居がぐんと下がるかもしれません。
2. Arduino上で動作する
タイニーさを突き詰める方向性です。フロッピーブートのゲームを作るようなチープな体験ができると思います。
これを実現するには今の仕様では大きすぎるので、構文や命令などを大幅に削減することが必要になると思います。
3. モダンな構文にする
これは逆にHSPをモダンな構文にして、オブジェクト指向などの仕様を取り入れる方向性です。需要は少なからずあると思います。とはいえBASIC風の文法やタイニーさは諦める必要があるかもしれません。ご興味のあるものはあったでしょうか。
dolphilia氏 2016/12/30(Fri) 16:34:37
↑
NO.77766 †
皆さんのアイデアやご意見、色々と参考になります。
話が少しずつ進んでいることを嬉しく思います(^^
誰か中心になる人がいれば進めやすい方法で実現されるといいですね。
何らかの成果や技術のフィードバックができれば、HSP3DishやHSP本体にとっても良い結果になるかと思います。
さくらさん、掲示板ではお久しぶりです。
HSP古株の書き込みを見ることができて嬉しいです。
Tinyな仕様というのは、どこまで切り詰めて、どこまでのアプリを
作成することをイメージするかによって変わってきますね。
さくらさんも書かれていますが、現状のHSP3DishはかなりTinyな仕様で
作られているので、標準命令についてはそちらとある程度変わらない形で実装して
(OpenHSPのソースを使えばかなりそのままで行けそうな気がします)
描画やシステム面での統一を最優先にするというのも1つの形かと感じました。
そして、ポイントはエディタを含めてマルチプラットフォームにする必要がある点で、
ここがクリアできればかなり実現度が高くなるのではないかと思います。
＞dolphiliaさん
macOS版HSPの開発、興味深く拝見しております。
「1. スマホでゲームが作れる（タブレットPCを含む）」が実現できるだけでも、
大きな意義があるのではないかと思います。
もちろんLinuxやMacOSXもアリだと思います。何よりLinuxで動作すると、
raspberry piなどの小型端末でも動作するようになるので、色々な可能性が広がります。
＞これはWeb版HSPに詳しい方にお伺いしたい点なのですが、
＞emscriptenはOS固有のAPI、例えばWin32APIなどは動くのでしょうか。
emscriptenはC/C++の標準ライブラリやOpenGLなどをサポートしていますが、
Win32APIなどWindows固有の仕様には対応していません。
＞OpenHSPからJSに移植する上でのポイントや難所はあるでしょうか。
zakkiさんが作られたHSP3Dishのemscripten版(hsp3js)は、OpenHSPに入っていますが、
描画に関してはOpenGL版とあまり変わりません。
htmlから扱う際のファイルシステムやサウンドの再生には少しクセがあるかと思います。
＞WebAssembly?は実用的でしょうか。
まだあまり詳しく知らないのですが、基本的にはモバイル系などで高速に動かせるよう
今後普及を目指していくような状態ではないでしょうか。
emscriptenなどと同様に汎用的なライブラリをターゲットに作っておけば、将来的に対応はできるのではないかと思います。
おにたま氏 2016/12/30(Fri) 18:14:53
↑
NO.77771 †
皆さん、本当にありがとうございます。
おかげ様で想定以上の意見交換の場になってきました。
＞ 資料を整理していて思ったのですが、HSP3Dishやコンパクト版(hsp3c)と変わらなく
＞ なっていくのではないと思うのは、私だけでしょうか?
sakuraさん、まさにそこです。
誰かがそのうち疑問を呈しそうだと思っていたところを
ご指摘頂き、ありがとうございます。
もし元々 hsp3dish や hsp3c がマルチプラットフォームを意識した仕様なのであれば、
tinyhsp にとってかわってもよいと思いますが、Linuxのディストリビューションのごとく
その仕様は異なる目的で策定されており、似て非なるものです。
TinyHSPの制約上で作れば"どの環境でもソースの修正なしで動く"
完全互換という仕様を明示することこそ、TinyHSPのキモなのです。
例えばWindows版、Linux版、MacOS版、hsp3dishなど、それぞれの環境で
「最初から各環境で動くように命令を調整して作ればいい」と作ったものは
あれこれ気を使って作る必要があります。ライトユーザはやらないでしょう。
この命令だけ使ってこうやって作ればいいよーという互換性維持の開発メソッドを公開してもよいかもですが、
どうせならTinyHSPという仕様を作って「TinyHSP配下で作ればどの環境でも動く」と明示しちゃったほうが
わかりやすいし、そんなものがあったら欲しいよなーと思ったのが、この提案の発端なのです。
これは実は(特にライトユーザには)大きな印象を与えると私は感じているのです。
現状の各環境版HSPでこんな感じの互換レベルになってるのを
Windows ≒ macOS ≒ Linux ＞ Android/iPhone
TinyHSPでは"明確に"こう示したい
Windows ＝ macOS ＝ Linux ＝ Android/iPhone
と思っているのです。
＞ dolphiliaさん
RUN命令の件、ありがとうございます(^_^)
感激です。
以下はかなり意義の高いアプローチになりそうですね。
＞ 1. スマホでゲームが作れる（タブレットPCを含む）
＞ 2. Arduino上で動作する
おにたまさん、コメントありがとうございます！
＞ ポイントはエディタを含めてマルチプラットフォームにする必要がある点で、
＞ ここがクリアできればかなり実現度が高くなるのではないかと思います。
エディタを含めてというのは望むべくもないですが、
仕様として含めてしまうと開発の負荷が高いかなと考えていました。
＞ 現状のHSP3DishはかなりTinyな仕様で
＞ 作られているので、標準命令についてはそちらとある程度変わらない形で実装して
＞ (OpenHSPのソースを使えばかなりそのままで行けそうな気がします)
おっしゃるとおりTinyHSPの仕様を前提にベストなやり方ができれば良いと思います。
開発の労力は少ないに越したことはありませんよね。
ちなみに、例えばですが、既存の各環境版HSPで hsp3c のごとく
#include "tinyhsp"
とかして作れば各環境で完全互換になるなら、そんな実装でもＯＫだと思ってます。
いずれにしてもその仕様準拠で動く各環境版のコンパイラとランタイムが必要になるわけですが、
あれこれ検討・模索しながらも楽しみながら進めていければ理想でございます。
kikeroga氏 2016/12/31(Sat) 08:46:23
↑
NO.77773 †
dolphiliaさん、コメントありがとうございます。
＞1. スマホでゲームが作れる（タブレットPCを含む）
＞プログラミングの敷居がぐんと下がるかもしれません。
HSP一式のアーカイブをダウンロードしてインストールして
スクリプトエディタを起動し、適当なサンプルを読み込んで
少しいじくれば短時間で、それなりのものが作れるという簡便さ
はあります。
でも、少し実用性のある見栄えのするものと作ろうとするとそれなりに
学習コストは高いように思えます。
これは、どの言語にも言えるのですが・・・・
スマホでゲームが簡単に作れるようにする仕様が浮かびません(^^;
＞2. Arduino上で動作する
マルチプラットフォーム化は、今後のHSPの活躍の場を広げる意味では良いことと
思います。
HSP3Dishで既に実現しているので、Dishの今後の拡張等に期待したいですね。
＞3. モダンな構文にする
構造化等には魅力を感じますが、HSPの開発初期からの言語思想に反するように
思えるのでちょっと賛成しかねます。
個人的にはいずれにしても、Tinyなものにするには、大幅に命令等を削って
超高速化や軽量化した利用用途を限定したものが良いように感じます。
たとえば、ゲーム開発だけに特化するとか、入門用の言語教育に使える簡便なものとか、
可能であれば中間言語方式ではなく本格的なネィテブコードのコンパイラにするとか(^^;
おにたまさん
コメントありがとうございます。
20年以上もサポートして頂いていることにユーザーの一人として感謝致します。
私自身は、今はもうほとんどHSPでプログラミングをすることもないのですが
今後、どのように進化・発展していくのかが楽しみです。
kikerogaさん、コメントありがとうございます。
さて、どんな仕様にまとめられるか・・・・
他の方の意見がほしいところですね。
sakura氏 2016/12/31(Sat) 11:24:15
↑
NO.77775 †
Windows = macOS = Linux = Android/iPhone ( = Web)といった多くのプラットフォームとの
互換性がソースレベルでも保て、難しい命令(?)もけずられていることで
初心者や学生でも学習できる簡単な言語がさらに簡単に学べるようになり、
さらには中・上級者は多プラットフォームへの移行も簡単にできそうな、
ぜひ実現してほしいHSPの形だと思いました。
＞ 1. スマホでゲームが作れる(タブレットPCを含む)
スマホなどでもゲームなどが作れる。これが実現すれば「簡単に学習・使用」ができるHSPが
さらに簡単に使用できるようになって私はとてもいいと思います。
くちくん氏 2016/12/31(Sat) 12:19:44
↑
NO.77805 †
明けましておめでとうございます！
資料を更新しました。
ダウンロード
↓
http://hspnext.com/download/hsp_commnd_20170101_11a.zip
dolphiliaさん、コメントありがとうございます。
＞こうしてみるとHSPの言語仕様は想像以上に大きいのですね。
HSPは、ちょっとスキルがあれば何でも出来てしまう恐ろしい仕様なんですね(笑)
＞TinyHSPをより軽量化するにあたって、
＞こうしたらいいんじゃないかというような、
＞アイデアはおありでしょうか
今は、ちょっとアイデアは思い浮かびません。
本題のテーマである軽量化、クリーンなHSPから外れますが個人的な興味として、
高速に大量のデータ処理ができたり、HSPの優れたグラフィック処理を
利用したデータ分析に応用できたりする強力な専用エンジンがほしいです。
まあ、これはアプリの領域なんですが・・・
現状のHSPでも十分ですけどね。
d3moduleではなくて、d3.jsに匹敵するようなもの、誰か作ってくれませんかね(^^);
余談ですみませんでした。
くちくんさん、ご意見ありがとうございます。
＞互換性がソースレベルでも保て、難しい命令(?)もけずられていることで
＞初心者や学生でも学習できる簡単な言語がさらに簡単に学べるようになり、
＞さらには中・上級者は多プラットフォームへの移行も簡単にできそうな、
＞ぜひ実現してほしいHSPの形だと思いました。
HSPの原点回帰という点で目指すべき方向性と思います。
sakura氏 2017/1/2(Mon) 08:23:32
↑
NO.77817 †
新年おめでとうございます
自分も言語作成している身でして、そういう面から書き込みします
http://zuzazann.boy.jp/wiki/index.php?HSPソース投稿Wiki
HSPソース投稿Wikiとでっちあげて 8割がた自分ばかり更新してます
（嬉しいことにちょこちょこ利用者さんはいます）
書き始めて2年くらい経ちましたが 実はそんなにやってるようなやってないような。です
自分なんかは仕様が固まってなくて行き当たりばったりでやってます
仕様はオリジナルでやるよりＨＳＰにならおう。とは思ってますが
YACCを採用してスクリプト言語的にしよう。とか 初期から構想に入ってなくて
後付けでどこまでいけるかわかんなかったりしてます
ライブラリがちょっと考えどこで
軽くJAVAのライブラリを使おうか軽くTcl/Tkを使おうかサーバーサイドにして
軽くブラウザチックにしようか 軽くHSPをエミュレートしようか色々考えています
GUIは好きなんですけど 考えると自分、そんなに高速描画しないので
軽く使えれば十分なんですよね
そういう意味ではライブラリは転用させて欲しくあります
Tinyと読むと変数が１字とかユーザー作成サブルーチンが使いにくそう。とか
そっちの軽量のようで違うっぽくもあるので 誤解を招きそうで確かに違う名称がふさわしそうですね
自分的にはOPEN HSPのソースコードの量がものすごくて理解しきれないので
全部で１万行くらいのプログラム言語作成学習用であったらなあ。と思います
それくらいの言語が少ないのか 自分の検索が下手なのかあんまり見ないです
自分は仕様を決めるにしてもWEBに決めたことを載せちゃうと実行しないので
そういうのやめましたが
それをあえてすることで協力者が出てくるのはすごい現象ですねｗ
結局、仕様を決める人と実装する人の役割分担をしちゃうくらいの勢いでないと
辛そうですね。そこまでの仕様の具体化具合は
ホラONITAMAさんだって実装前にそういうことあまり言わないでしょ
なので新機能を語るスレ。とか建てたい勢いでもあるくらいです
自分としてはプログラム言語作成をもたもたやってるそばからビュンビュン追い抜かれていって
寂しくもあるし、自分の才能のなさがふがいなくもあります
そういう時は結果より過程が大切さ。とか
やることに理由なんていあらない。とか偉い人の言葉を思い出すしかないっすよ
みたいなかんじに応援しております（どんなだｗ）
Y_repeat氏 2017/1/3(Tue) 08:08:27
↑
NO.77818 †
そう言えば HSPの方針については あまり議論がされてないみたいだったので
そういう議論もあっていいかもですね
ONITAMAさんも参加されていることから
tinyHSPが実現せずともこの議論にすでにフィードバックしている部分もあるかもしれませんね
dishの仕様とかも未だ流動的かもしれませんし
Y_repeat氏 2017/1/3(Tue) 08:18:26
↑
NO.77819 †
自分の黒歴史的に某ゲームの掲示板の常連だった黒歴史がありまして
意見はしても自分で作る訳ではないもどかしさがあったので
プログラミングを再開させたんですが
自分はなくても大丈夫みたいなスタンスで論じてしまうので
ってかそんなんだからあんまり議論の火蓋はきらなかったんですが
たぶん仕様を決める人も大事で
ってか時に作業をする人より上に置かれるくらい
なので貫きたいことがあったら 叩かれても曲がらない釘のごとく
貫いて欲しいですね
自分は結局叩かれると曲がってしまう釘のようなので
Y_repeat氏 2017/1/3(Tue) 08:31:24
↑
NO.77822 †
HSPはもともと難しい前準備なしにエディタを起動して、いきなりソースを打ち込んで使える簡便さが大きな魅力でした。
ライブラリが肥大化したことで、できることは増えたのですが、どの機能を使っていいか、どの命令がプラグインに依存しているかなど
混乱する要素も増えてきていると感じています。何とかするべき所だとは思っていますが(^^;
そういった意味では、初心者やちょっとした用途で汎用的に使えるシステムは、制約はあるものの原点に戻ってシンプルさがあって一定の需要があると考えています。
＞sakura さん
＞20年以上もサポートして頂いていることにユーザーの一人として感謝致します。
ありがとうございます!
素晴らしい資料の作成、相変わらずの良い仕事ですね。
命令を削って軽量化という方向も間違っていないと思います。
＞dolphilia さん
＞フィードバックする方法には、
＞具体的にどんなものがあるでしょうか。
ソースコードが公開されていれば、有用なコードや変更はこちらでOpenHSPに取り込むことが可能です。
また、TinyHSPなど他のランタイムと共用して修正のしやすい形でOpenHSP側のソースコードを変更するなどのフィードバックもできるかと思います。
機能の拡張よりも、最小限に削ってまとめることの方が難しい作業だとは思いますが、
必要なものを見極めた上で大胆に削って、限定した形になることを願っています(^^
ちなみに、私もpalette系の命令は愛着がありますが、最近のビデオカードやマルチプラットフォーム化を考えると余計なものになっていると思います。
おにたま氏 2017/1/3(Tue) 10:59:01
↑
NO.77852 †
Academic HSP
VSにAcademic版があったのと
学習用言語 プログラム言語作成学習用 の用途を想定して
でも結局一番貢献した人に決定権がある気がします
＞TinyHSPはオープンソースで、
＞Githubで開発するようにしてみます。
＞上記のTinyHSPは私の遊び心も入ってしまっているので、
＞このスレッドで検討されている「クリーンなHSP」は、
＞じっくりと仕様を検討していければいいな、と思っています。
仕様書に変数は一字とか書いてて思いっきり仕様がTinyBasic?になってて
焦りましたが 別のプロジェクトなんですな
TinyBasic?もGPLが多くて
いや別ライセンスで配布して 暗号かけた版みたいな
HSPみたいな配布形態にしたくて
BSD版もあるみたいなんですけどもｗ
完成したら研究させていただきますｗ
「クリーンなHSP」にガッチリ参加してもいいんですけど
自分書き方がボトムアップで
ifの段階でif x thenになってしまっているのでｗ
#{にする決定が下せないｗ
しかも中間言語で既に２年くらい経過している１０年計画必須でｗ
この具体化具合はもっとスピード感がある人がふさわしいと思います
LinuxもUbuntuちょっと触った具合で
何が移植性あって何が移植性ないのかわからなく
そういう意味では言語を作成する人とライブラリを作成する人を分けた方が良さそうですね
というかHSP3CLは結構行数かかってる印象なので
言語仕様と実装をスリム化させたら
言語としては十分な感じもします
全部で一万行くらいで どうかｗ
短くなったけどその分ややこしいとかじゃなく
ややこしさもせめて現状で
＞HSP処理系ではないのですが、こういうのはいかがでしょうか。
近いうちに見てみますねー
豊四季tinybasicは最近、書籍買いましたです
自分としては
HSPのHSPCMP.DLLとか（たしか）
「プログラミング言語を作る」書籍情報のサンプルとか（ちゃんと書籍買いましたｗ）
http://kmaebashi.com/programmer/devlang/book/index.html
「いまどきのプログラム言語の作り方」書籍情報のサンプルとか（ちゃんと書籍買いましたｗ）
http://d.hatena.ne.jp/yaneurao/20051031
とか書写してます。読むのも打ち込むのも辛いのでｗ
tinyBasicもちょこちょこ写経とか書写とかしてます
Y_repeat氏 2017/1/6(Fri) 01:21:40
↑
NO.77853 †
資料を更新しました。
↓
http://hspnext.com/download/hsp_commnd_20170106_11b.zip
kikerogaさん
＞名称はイメージが大事だと思いますので、他の方の意見も欲しいところです。
ネーミング(案)に参加します(^^;
HSP Best
↓
Basic Enjoy Script Training
- - -
└ or Try
＜基本ポリシー＞
基本的なスクリプトを利用して楽しみながら学習(挑戦)する。
Learn While enjoying Using basic script
dolphiliaさん
＞TinyHSPはオープンソースで、
＞Githubで開発するようにしてみます。
＞https://github.com/dolphilia/tinyhsp
ちらっと、拝見しました。仕事の取り掛かりが速いですね。どんな形になるか
楽しみにしています。
＞私もHSPに正規表現が標準で搭載されたら良いなとか、
＞深層学習やVR・AR技術を実行できるようなエンジンがあれば良いな、
＞なんて考えたりします。
HSPが世界に羽ばたけるような実務に密着した実用性の高いものになると良いですね(笑)
おにたまさん、コメントありがとうございます。
まあ、どれだけサポートが出来ているのかわかりませんが、資料は整理しておくと
誰かの役に立つのかもしれません。
このスレッドを楽しんでやっています。
sakura氏 2017/1/6(Fri) 21:03:10
↑
NO.77857 †
現在の名称を仮称とすれば良いのでは？
色々議論するのも良いのですが、取りあえず土台とし
て極簡単な物を作るのが最優先だと思います。
仕様を固めた上で作るのは当然重要ですが、ある程度
作り込んでテスト公開したら動作不良ばかりで、修正
を繰り返したらソースがスパゲティーになって訳が分
からない状態になったり、もしかしたら開発環境自体
を考え直す必要になるかも知れません。
互換性を担保出来る最小限の命令や関数だけなら、ま
ず不具合も無いだろうし問題が有ってもキズは浅くて
済みます。あとは段階的に命令を増やして最終目的に
持って行きます。
それと人間の欲求に限りは有りません、特に多数の意
見を求める場合は、目標を高く設定することになりが
ちです。暫定仕様として一旦線引きするのも重要です。
暫定目標としてはＨＳＰ２相当の命令・関数から、マ
クロ定義されている物や、特殊な使い方が必要なもの
（極端に言えばプリプロセッサ全て）を消せば、相当
シンプルな物しか残らないでしょう。この辺りを暫定
目標として話を進めた方がスムーズに行きそうな気が
します。
KA氏 2017/1/7(Sat) 19:19:40
↑
NO.77860 †
KAさん
＞色々議論するのも良いのですが、取りあえず土台とし
＞て極簡単な物を作るのが最優先だと思います。
進め方としての、ご意見に賛成ですが、実現の可能性は別として
色々議論する過程を楽しんでいる人も多いのではないかと思います。
＞暫定目標としてはＨＳＰ２相当の命令・関数から、マ
＞クロ定義されている物や、特殊な使い方が必要なもの
＞（極端に言えばプリプロセッサ全て）を消せば、相当
＞シンプルな物しか残らないでしょう。この辺りを暫定
＞目標として話を進めた方がスムーズに行きそうな気が
＞します。
同感です。今回のTinyHSPの目標実現としてはHSP2相当が良いと考えます。
しかし、極端に命令が少ないと作れるものも制限されるし、
少し、いいものを作ろうとするとかなりのスキルが要求されるように
思えます。HSP2時代の初期の頃も、拡張プラグインに頼っていましたね。
資料更新しました。(ほぼ、最終更新版となります。しばらく、更新しません。)
↓
http://hspnext.com/download/hsp_commnd_20170107_11c.zip
sakura氏 2017/1/7(Sat) 22:10:13
↑
NO.77862 †
sakuraさん
その「楽しむ」が、それで終わりに成らないと良いんですが・・。
過去、方向性は異なりますが、似たような考えで立ち上げたサイト
が殆ど機能していない現実問題として、「なぜ機能していないのか」
を分析してみる必要はあると思います。
ＨＳＰ２相当と言ったのは、あくまで開発者側の立場で「暫定」とし
ています、当然利用者側から不満は出てくるでしょう。その不満を元
に適時バージョンアップし、不具合を修正していくという意味合いで
す。
話の途中で水を差したくは無かったのですが、似たような過去の失敗
を教訓として今後に生かす姿勢はほしいです。
毎回文句（イチャモン）ばかり言っていますが、今回のプロジェクト
に否定的な訳ではありません。議論をまとめるのなら閑古鳥の鳴いて
いるサイトを再利用したり、論点が多肢に渡るのなら論点毎にＷＩＫ
Ｉ形式にするなど、やりやすい方法はあると思います。
この読みやすいとは言えない掲示板で、あれやこれや議論が飛び回っ
ていては、読みにくくて仕方がありません。
辛辣（かな？）な書き方ですが、何かの参考になれば幸いです。
KA氏 2017/1/8(Sun) 00:43:54
↑
NO.77863 †
KAさん
コメントありがとうございます。
＞その「楽しむ」が、それで終わりに成らないと良いんですが・・。
終わりになる可能性は否定しません。
私も、過去このようなブロジェクト的なものを多く見てきましたが
うまくいったものは、ほとんど知りません。
＞毎回文句（イチャモン）ばかり言っていますが、今回のプロジェクト
＞に否定的な訳ではありません。
危惧されていることや、HSPに対する気持は発言から十分読み取れます。
貴重なご意見、ありがとうございます。
まあ、たまには今回のようなスレッドでの議論も良いのではないでしょうか?
議論の成り行きにイライラする人もいるのかもしれませんが・・・・
KAさんの見識で力を貸して頂ければ、ここに参加している皆さんも力強いと
思うのですが・・・・
sakura氏 2017/1/8(Sun) 08:24:20
↑
NO.77867 †
とりあえずCで使うライブラリの開発は始まってどうでしょうか
ってやる人いないのかな？
とりあえず
言語としてはＣ言語まんま（開発後回し）で クリーンＨＳＰのライブラリを使用
ってかんじでどうでしょうか？
それでもある程度ＨＳＰ感覚で開発できるでしょうし
自分の中間言語もまったくライブラリ書いてないので
そういうのがあると非情にありがたいです
自分の中間言語はそろそろＣに移植かな？って思ってるとこです
gosub的サブルーチンを実装すれば 中間言語としてはある程度完成です
配列もまだ実装してないか
＞＞その「楽しむ」が、それで終わりに成らないと良いんですが・・。
＞終わりになる可能性は否定しません。
＞私も、過去このようなブロジェクト的なものを多く見てきましたが
＞うまくいったものは、ほとんど知りません。
面白そうな企画なのですが
この書き込みを見て心配にはなりました
Y_repeat氏 2017/1/8(Sun) 22:38:34
↑
NO.77869 †
Ｃで開発するならＣで開発するとして
新しい言語を開発するのではなく
Ｃスクリプトを生成するかんじだとどうでしょうか
ってＨＳＰＣもそんなかんじでしたっけ？
動けばいいってんじゃなくて
生成後のスクリプトも人間が読みやすいかんじでお願いします
自分の中間言語も親言語記述をそのまま受け入れようと思っているのですが
仕様がなかなか固定しないですね
現状、自分しか使えない。みたいなｗ
自分でも上手く動かし方がよくわかってない。みたいなｗ
機械的に決まってる仕様をエデイタ的ツールでカバーしようとは思っているのですが
Y_repeat氏 2017/1/8(Sun) 22:53:18
↑
NO.77871 †
sakuraさん
言いたくは無いけどつい言ってしまう性分で、自覚は
していますが中々直らない物です。
私の見識など何の役にも立たないと思いますが、書く
と長くなるので、しばらくは静観します。
KA氏 2017/1/8(Sun) 23:45:31
↑
NO.77885 †
Y_repeatさん
＞言語としてはＣ言語まんま（開発後回し）で クリーンＨＳＰのライブラリを使用
＞ってかんじでどうでしょうか？
＞それでもある程度ＨＳＰ感覚で開発できるでしょうし
＞自分の中間言語もまったくライブラリ書いてないので
＞そういうのがあると非情にありがたいです
私は、C言語は昔、HSPの拡張プラグインを作成する時に少しだけ
かじった程度の素人同然ですが、2004年当時、似たようなことができないかと
試行錯誤したことがあります。
過去のフォルダを探してみたら、ゴミみたいのものですが、
参考になるかどうかわかりませんが、ソースがありました。
必要な部分を部品として活用して頂けたら、ありがたいです。
あまりに幼稚な書き方でみなさんに笑われるかもしれませんが、アップ
しておきます。
http://hspnext.com/download/HSP参考程度のゴミソース.zip
＞面白そうな企画なのですが
＞この書き込みを見て心配にはなりました
すみません。何か心配させるようなことを書いて・・・・
KAさんと同様、このプロジェクトがうまくいってほしいという
思いを理解して下さい。
KAさん
コメント、ありがとうございます。
＞言いたくは無いけどつい言ってしまう性分で、自覚は
＞していますが中々直らない物です。
私の個人的な見解ですが、物事の本質を見極めての発言と理解しています。
なかなか、本質や本音を言える人が少なくなっているので、・・・・
kikerogaさん
＞少なくともこのスレッドを立てた意義は想定以上に大きかったようで
＞良かったと思っています。
＞あとはもう成るようになるでしょう！(^o^)
もう少し、がんばってみますか(^^;
sakura氏 2017/1/9(Mon) 14:23:34
↑
NO.77891 †
下記、大変失礼しましたm(_ _)m
誤）おのたま氏
正）おにたま氏
＞ もう少し、がんばってみますか(^^;
sakuraさん、
貴重なソースを公開して頂き、ありがとうございます。
勉強させて頂きます。
私も何か心配させるようなことを書きましたかね(^^;
ネットの発言は温度感が難しいですが
「もうヤメましょう」という意味合いではないので
今後ともよろしくお願いします。
kikeroga氏 2017/1/9(Mon) 16:57:09
↑
NO.77899 †
kikerogaさんへ
＞このスレッドは"TinyHSPの提案"として立てましたが、
＞・おのたま氏がコメントし、そのプロットと意義を認めてくれたこと
＞・sakuraさんが大変素晴らしいベースドキュメントを作成してくれたこと
＞・dolphiliaさんがtiniyhspのプロジェクトを開設してくれたこと
＞と十二分な成果を果たしており、その役割を終えているように思います。
＞今以上に論議を発展させる場所としては、ご指摘の通りWikiやその他の仕組みで
＞進めるほうが適切だとは思いますが、これから先のことも、私自身も含めて
＞何がどうなろうと、誰かができることをやるだけです。
＞少なくともこのスレッドを立てた意義は想定以上に大きかったようで
＞良かったと思っています。
そうでしたね。ここのスレッドは"TinyHSPの提案"というタイトルでしたね
そういうタイトル的には結構役目を果たせたかもしれません
ではこのスレッドを受け次のスレッドを立てて欲しいなあとも思います
僕もwikiを立てましたが僕のwikiなんてたいして訪問者いないでしょう
なので引き続き公式BBSで議論をするなら続けて欲しくあります
自分もプログラム言語作成を目標としてやってる身としては実りありましたので
僕の今年は10年計画の3年目くらいとしての目標は
ドラゴンブックを購入して読破する！ですｗ
言語開発者としてこの書籍を読破していない人はモグリと某書籍に書いてあったので
いつか読まなきゃなあと思っていたところです
RHGも2014に購入して読破していない僕ですが
せめて購入して一か月につき一章づつ読む。を今年の抱負にします
Y_repeat氏 2017/1/10(Tue) 07:30:29
↑
NO.77902 †
この企画には大変肯定的です。
だからこそ言わずにはいられないのですが、すでに話にも出ているように、
ここでこのまま議論を続けるのはよい選択ではないように思います。
口の悪い言い方になってしまいますが、
現状はこの企画とは直接関係のない話題が飛び交いすぎていて
(それが悪いことだと言うつもりはありませんが)、
このままでは雑談スレッドに成り果ててしまう気がしてなりません。
専用のフォーラム等を設け、問題点をピックアップして
個別に解決してゆくような形になれば、
もっと議論の内容が把握しやすい状態で話が進むのではないでしょうか。
現状どういう問題について決め兼ねているのかを把握しやすくなれば
それぞれの問題の解決手段について意見する人ももっと増えるはずです。
HIJIKI氏 2017/1/10(Tue) 13:17:09
↑
NO.77903 †
そんなことを言っておきながら、
企画自体には何の意見も残さずに退場するのはどうかと思うので、
遅ればせながら、そして拙い意見ですが期待の表現ということで書かせていただきます。
■言語の名称について
これは皆さんが既にたくさん良い物を提案されてますので、
以下はあえてセンスのない頭で別の観点から捻り出したものです。
(逆に言うと、センスのない者にしかできないかもしれないのであえて書かせていただきました。)
・MyHSP (自分の物と言えてしまうくらい小型で見通しが効くという意味で。)
・HSPCore (中核のみが実装されているという意味で。)
・HandyHSP (手のひらサイズのHSPという意味で。)
・PalmHSP (同上。英語ではHandyが[便利な]や[有用な]と取られてしまうようなので。)
・PalmSizedHSP (同上。略さず表記したもの。略称が[PSHSP]となり回文で面白いと思ったので。)
・HSP-- (デクリメントされたHSPという意味で、C++に対するHSP--。ただ字面が見づらい。)
・HSP-1 (同上。字面を考慮。HSP1と混同しかねない？)
・HSP-=1 (同上。)
・HSP0 (ゼロに戻ったHSPという意味で。ゼロがオーに見えるかもしれない。)
・HSPZero (同上。見間違いを考慮。)
■言語仕様について
ソースコードを変更することなく、あらゆる環境で同じ動作をする HSP の機能縮小版
ということだと認識しているので、その前提で書かせていただきますが、
もし私の認識が違えば教えていただけると幸いです。
削る命令と残す命令の水準は、代替手段があるかというのはいかがでしょうか。
例えば、stick命令はgetkey命令で代用が効くので両方は不要である、など
本家HSPの命令や機能のうち、企画仕様上再現可能なものを全て移植するのではなく、
文字通り必要最低限に抑えるほうがこの企画の魅力をより高めると思います。
それで言うと、HSPに標準でマクロとして定義されている命令も不要ということになり、
この辺りは意見が割れそうですね。
記法については、
本家HSPのソースコードを(記述されている命令が対応していれば)、
また逆に、「クリーンなHSP」で記述されたコードを、本家HSPにも
そのまま流用できることが望ましいと思います。
そうすれば「プログラミングの入り口」の前の「HSPの入り口」として学習用に十分に力を発揮するほか、
今までHSPを利用してきたユーザーも(追加学習も必要なく)案件によって
使い分けることができて良いのではないでしょうか。
長くなりましたが、何かの参考になれば幸いです。
この企画の成就を心よりお祈り申しあげます。
HIJIKI氏 2017/1/10(Tue) 13:35:57
↑
NO.77904 †
こんにちわ
自分のとこのmediawikiですが
デフォルトでもハイライトしてくれて頼もしいんですが
自分が利用しているロリポップの鯖は
データベースが一人一つしか運営出来ないみたく書いてるとこがあって
mediawikiは一つしか運営できないっぽいです
という訳でせっかくのmediawikiですので もっと活用したいですね
というところで
次のスレッドを立てるとしたら どういう趣旨のスレッドにすべきか
そういう話もした方がいいのではないか？と思います
このスレッドは TinyHSPの提案 ということで「提案・要望」スレッドとなっています
＞このままでは雑談スレッドに成り果ててしまう気がしてなりません。
という懸念をHIJIKIさんが持たれているようなので
逆に最初から「雑談」スレッドとして立ててみてはどうでしょうか
とはいえあまり重要ではない雑談は自分のとこのwikiでってことでお願いします
dolphiliaさんのtinyHSPも開発の途中経過とか
更新履歴削除って書いてましたが
せっかくなので更新履歴はUPし続けて欲しいですね
開発の提案だけして 梯子を外すみたいなのは悪いなあ。と思いませんか？
後はさくらさんがドキュメントをもう少し加筆するようなので
それも期待出来ます
自分も言語作成をテーマにプログラミングしてる身としては
モチベーションの上がる小論文（＝エッセイ）の執筆お待ちしています
このスレッドと連携して今年の抱負とか書いてもいいですし
今後半年の抱負でも４半期の抱負でも今月の抱負でも
展望によって抱負の期間はお任せします
自分のとこのwikiに関する意見もありましたら
そういう話も出ていいと思います
他にも次のスレッドで 議論したいテーマがありましたら
書き込みましょう
という訳で 次のスレッドお待ちしてまーす
２、３日くらい間をあけて 誰も次のスレッドを立てないようでしたら
僕が「雑談」スレッドを立てます
Y_repeat氏 2017/1/10(Tue) 14:13:47
↑
NO.77905 †
KAさんの助言に従い ここのとことかの まとめサイトなwikiを開設しました
http://zuzazann.boy.jp/media_wiki_120/index.php?title=メインページ
・運営方針 ちょいちょい変更してますｗ
Y_repeat氏 2017/1/10(Tue) 17:07:15
↑
NO.77908 †
HIJIKIさん、ご賛同ありがとうございます。
欲しいですよね、こんなHSP(^_^)
名称に関しては色々候補を出しておいて、実際には
開発する方が気に入ったものを付けてくれればよいかと
私は思っております。
Y_repeatさん、色々ありがとうございます(^_^)
TinyHSPの話題が継続されるのは良いことだと思います。
次のスレッド、お任せいたします。
kikeroga氏 2017/1/11(Wed) 11:44:34
↑
NO.77916 †
スレッドのタイトルは少々考えてたんですけど
「HSP討論会」「タグ：雑談」でどうでしょうか
討論をtinyHSP及びクリーンHSPに限らず
せっかくなのでHSP全般に関する討論もあっていいんじゃないでしょうか
スレッドの内容は
tinyHSPに関すること クリーンHSPに関すること HSPに関することでしてみたかった意見
小論文（エッセイ） エッセイの日本語訳は「小論文」みたいですｗ
雑談：今年（今月）の抱負 ロールモデル
その他のご意見
ということで予定しています
Y_repeat的には HSP公式BBSのまとめサイトをなんとなくやってみたい気がしてました
しかし HSP公式BBS には書き込みが まとめるには多すぎるかんじがしてたので
特定のスレッド内の書き込み限定なら出来るかもしれない。という後付けがあったりｗ
Y_repeatは雑誌が結構好きなので
（最近はちょいちょいしか読んでないですが そもそもものすごい読んだ時期もなかったりｗ）
WEB MAGAZINE感覚でwikiを運営していけたらなぁと思います
そして せっかく関連wikiを運営するなら 対象を割と広くしても面白いかもしれないかな。と思いました
ということで
「せっかくなのでHSP全般に関する討論もあっていいんじゃないでしょうか」と書きました
Y_repeat的には今回はなるべく裏側から支援したい気持ちがありまして
裏側から支援する意味でまとめサイトも作ったんですが
スレの後半あたりから 前に出過ぎな気もする残念感ｗ
＞kikerogaさん
ほめてただいたりして こっぱずかしいですｗ
Y_repeat氏 2017/1/12(Thu) 00:42:02