HSPTV!掲示板

スレッド一覧 | 新規書き込み | 新着一覧 | 使い方 | 過去ログ

未解決

解決

停止

削除要請


	2016 1209	kikeroga	TinyHSPの提案	58

kikeroga

2016/12/9(Fri) 16:10:55|NO.77515

詳細は以下資料を参照ください。

TinyHSPの提案_20161208.zip
http://ux.getuploader.com/kikerogaupl/download/66/TinyHSP%E3%81%AE%E6%8F%90%E6%A1%88_20161208.zip

こんなHSPあればいいなという単純な思い付きであり、願望なのですが
賛同・協力いただける方がいれば嬉しいです。

まずは発信をと思い、書き込みました。

気長に進めていければと思っています。

この記事に返信する

2016/12/10(Sat) 17:09:36|NO.77548

マルチプラットフォーム対応の、OS依存の命令を抜いた実行環境としてのHSPという感じがしましたが、
現状のHSPが既にWin、iOS&Android、Web（JS）といくつかの環境の上で動いているので、
TinyHSPがHSP自体とどれくらい差異があって、コンパクトである利点がどれぐらいあるのか、の熱量がちょっと図りかねるところがありました。

とは言いつつ、クリーンなHSPがあると嬉しいことは個人的には多分にあると思ったので、興味あります！
私自身あんまり技術力ないので、開発にどれくらい貢献できるかは謎ですが、ひとまず話は聞いてみたいです。

kikeroga

2016/12/12(Mon) 13:18:17|NO.77566

3kさん、コメントありがとうございます。

現状既にWin、iOS&Android、Web（JS）といくつかの環境でHSPがあり
HSPの知識は各環境で開発する際には十分に活かせると思います。
ただ、移植にはそれぞれの環境に合わせた修正が必要になりますよね。

プログラムソースレベルで完全互換とすることで、
おっしゃる通りのクリーンなHSP(開発環境、実行環境を選ばない)を
実現したいと思っています。

資料にあるTiny命令だけでプログラムを組んだとしても
各環境で完全に同じ動作はしないと思っていて、そこを合わせるのが
TinyHSPになるかなぁと。

Tinyという名称にも由来しますが、命令数をしぼって少なくするのも
憶えやすそうとか、印象も実装も軽いとか、利点ととらえてます。

コンパクトである利点がどれぐらいなのかは私自身も検討できてないですが
個人的な想いが発端なので、こういうものが好きな人たちで楽しみながら
進められたら良いなと考えてます。

おにたま(管理人)

2016/12/14(Wed) 00:04:35|NO.77572

興味深い提案をありがとうございます。
ランタイムのバリエーションなどで色々と仕様が増えているHSPにおいて、複数プラットフォームで共通の仕様で動作する(クリーンな)形を目指すのは良いことだと思います。
広げた風呂敷を畳むような感じでしょうか。現在、HSP3Dishもありますが、開発環境も含めた形で方向性が見えるといいなと感じています。

kikeroga

2016/12/15(Thu) 16:48:55|NO.77590

おにたまさん

ご理解、コメントいただき、嬉しい限りです(^_^)

> 広げた風呂敷を畳むような感じ

言われて初めて気づきました。

HSPは十分易しいと思うのですが、TinyHSP の意図として
Visual Basic に対しての Small Basic のような感じはありますね。

色々ご意見いただいて、あとは作るだけ、くらいまで
仕様のイメージが固まるといいなと思ってます。

tds12

2016/12/18(Sun) 15:14:32|NO.77638

一からソースを書くということでしょうか？
それともOpenHSPの派生になるのでしょうか？

OpenHSPからの派生になると、実装が楽というわけにはいかないと思います。
言語仕様が多少変わることも含めてTinyHSPということでしょうか？

どちらにしても協力したいと思います。

kikeroga

2016/12/19(Mon) 11:06:38|NO.77644

tds12さん、コメントありがとうございます。

> 一からソースを書くということでしょうか？
> それともOpenHSPの派生になるのでしょうか？

個人的にはOpenHSPのソースから改修したほうが既に知見をお持ちの方が多いこともあり、
メリットが多いんじゃないかなーとは思ってます。
また、派生というよりは機能縮小版に近い実装になるんじゃないかと考えてますが、
いかがなもんでしょうか？

> OpenHSPからの派生になると、実装が楽というわけにはいかないと思います。

仕様、ソースとも新たに作る部分は出てきますね。

> 言語仕様が多少変わることも含めてTinyHSPということでしょうか？

ご認識の通りです。

> どちらにしても協力したいと思います。

ありがとうございます。協力はどんなかたちでもＯＫですし、
コメントいただいてることが既に協力してもらっているのと同義です(^_^)

undef32

2016/12/19(Mon) 21:04:02|NO.77646

面白そうなご提案だなあと思って見ていました。
何ができるかは謎ですが、手伝えそうなことがあればお手伝いしたいなと思っています。

> 個人的にはOpenHSPのソースから改修したほうが既に知見をお持ちの方が多いこともあり、
> メリットが多いんじゃないかなーとは思ってます。
横からで申し訳ないのですが、個人的には１から書いた方がよりコンパクト・クリーンになって
何かとやりやすいんじゃないかなと思います。

あと、個人的にはプラットフォーム間の互換性の他にも、本家より小さい分実行速度も速い
みたいな＋αがあるとさらに魅力的かなと思いました。

kikeroga

2016/12/20(Tue) 10:37:02|NO.77660

undef32さん、コメントありがとうございます。

ソースについてはTinyHSPの仕様を前提にベストなやり方ができるといいですね。書き方についてはそんなにこだわっていません。
コンパクト・クリーンなソースなら見易さ、理解のしやすさも手伝って、移植もメンテもやりやすくなるでしょう。

また、早い、軽い、というのは魅力の一つでもありますね。
TinyHSPの特徴(メリット)を維持するには下記２点を厳守することが大切だと思っています。

・絶対！機能拡張しない(…守れるのか？)
・異機種間の互換性重視(ソース／中間言語レベル)

ご興味がある方には思い付きでも、ただのご賛同でもかまわないので、どんどんコメントください。
アイデアや留意することなど、何でも出し尽くさないと良い仕様にならないと思いますので。

TinyHSP的なものが皆さん潜在的な願望としてあったのかなと、意外と反応が良くて嬉しいです(^_^)

dolphilia

2016/12/20(Tue) 11:22:32|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で扱える形式も環境に依存しそうなので、
その辺りの仕様もあるといいかな、と思います。

kikeroga

2016/12/21(Wed) 15:58:09|NO.77671

dolphiliaさん、ありがとうございます！

私自身は技術的な知見が浅いので、ご意見伺えて幸甚です。

おかげさまで一気に具体的な方向へ話が進んだようです。

ご要望の事項ですが、さしあたりで検討してみますと

> screen命令

screen 0,640,480

TinyHSPでは第一パラメータは0番しか指定できません。
（簡便さだけでなく、ウィンドウGUIのない環境に対する仕様でもある）

screen 1 とか 2 とか 0 以外にしたときの挙動は、

　①buffer 1 とか buffer 2 とかと同義にするのか？
　②screen 0 と同義にするのがいいのか？
　③エラーとするのか？

などいろいろと考えられますが、個人的には①がHSPらしく
第一パラメータも削らずに済むのでベターかと思います。

screen命令自体を書かなかった場合は暗黙の画面サイズが設定されるようにするなど
さしさわりのない仕様は通常のHSP準拠でよいと思っています。
なのでTinyHSPのソースは通常のHSP上でほぼそのまま動かせるものと想定しています。
（逆は難しい場合が多いでしょうが）

> システム依存の色やフォントの違い
システム依存部分は表示が異なってもOKと考えてます。
例えば実行したときに表示される色やフォントが各環境で異なったとしても
同等(あるいは最も類似する)の機能が呼び出されているのであれば
それでかまわないと考えています。

> mmloadやpicloadで扱える形式
扱える画像は bmp,png,jpg 音声は wav,mp3 のみにする。

> mouse命令
少なくとも Tiny の仕様はマルチタップなどは不要、最小限のマウス操作と
それに合わせたタッチ操作ができればよいのではないでしょうか。

> getkeyやstick命令
アルファベット、カーソルキー、ESC, BS, Shift キーなど
代表的なキーコードだけ各環境で合わせるようなイメージでおります。

例）Android のキーイベント
https://developer.android.com/reference/android/view/KeyEvent.html

> ファイルへのアクセス
フルパスの指定はもちろん可能とし、ファイル名のみ指定した際の
ディレクトリが各環境で同義になればいいかなーと思っています。

例えばWindowsならexeや実行ソースのあるカレントパス。
AndroidならSDカードに tinyhsp/files なんて読み書き可能なディレクトリを
作成しておいてカレントパスとするなど。

> width
削っちゃっていいかもしれません(^_^)

以上、答え切れてないと思いますが、皆さんの要望・見解も頂けると助かります。

kanamaru

2016/12/21(Wed) 17:13:56|NO.77672

このtinyhspは、どの環境でもソースが同じということは、
Javaのように仮想マシンを用意する形になるのですか？
また、axファイルやdpmファイルはhsp準拠にしますか？

kikeroga

2016/12/22(Thu) 09:43:13|NO.77687

kanamaruさん、コメントありがとうございます(^_^)

> Javaのように仮想マシンを用意する形になるのですか？

仮想マシンと呼ぶかはともかく、環境ごとにランタイムエンジンを用意するかたちになると思います。

> また、axファイルやdpmファイルはhsp準拠にしますか？

準拠でいけるような気はしてます。
ただ、細かいところで「ここはどうする？」「こんなときどうする？」という
シーンが環境ごとにあるかと思いますので、そのあたりを皆さんと出し合って
あれこれ検討出来たらと思っています。

dolphilia

2016/12/22(Thu) 14:23:08|NO.77689

ご回答ありがとうございます。

少しでも助けになればと思い、再びコメントします。

----

開発環境について質問・提案します。

TinyHSPは開発環境を包含するでしょうか。それともエンジンのみの実装となりますか。
包含するとしたらエディター、ヘルプマネージャー、HSPTV、デモ、Peasエディター、その他ヘルパーツールなどどこまでをサポートするでしょうか。

エディターを含めるとすれば、その機能についての具体的な仕様があればいいなとも思います。

----

当スレッドの現時点までのまとめを作りました。

PDF:
http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.pdf

DOCX:
http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.docx

Markdown:
http://hsp.dolphilia.com/tinyhsp/tinyhsp_20161222.md

自由に追加編集等していただければと思います。

kikeroga

2016/12/23(Fri) 01:51:17|NO.77690

dolphiliaさん、ありがとうございます！

以下、あくまで私の考えですが。

> TinyHSPは開発環境を包含するでしょうか。

あればオールインワンで親切ですが、特に開発環境を包含する必要はないと考えます。
エンジンのみの実装、あるいはコンパイラとエンジンのみでよろしいかと。

TinyHSPであることの仕様は最低限(コンパイラとエンジン)でよいと思います。

マルチプラットフォームへの展開をできるだけ楽に、簡潔にするという思惑もあるのですが、
コンパイラとエンジン以外の部分については、作っても作らなくてもかまわない。
そのあたりの充実不実は、実際に個々の環境で開発する方々に委ねていいと思ってます。

ただ、個人的に、専用エディタやヘルプなどはもちろんそろっていたほうが、
ビギナーが始めるときのお手軽さは増すとは思いますし、HSPらしいなーとも思います(^_^)

がそれはそれ、プログラミングの環境を充実させるのは仕様とは別のお話かなと。

いやもう「まとめ」についてもホントにありがとうございます！

我ながら言うばっかりでなかなか動かない人間でもあるので大助かりでございます(^_^)

sakura

2016/12/24(Sat) 13:48:11|NO.77693

TinyHSPの仕様を検討する上で必要となるのではないかと思い、
「HSPランタイム別命令一覧」を作成して見ました。
自由に編集して、加筆・修正して利用して下さい。

Console版(hspcl)とLinux版はドキュメントを探し切れなかったので
未完成です。どなたか、埋めてくれませんか?

Excelとpdf化したzipファイルを下記に置いてあります。

http://hspnext.com/download/hsp_commnd_20161224.zip

こんな形でしか協力できませんが、少しでもお役に立てば・・・・(^^;

sakura

2016/12/24(Sat) 18:29:38|NO.77699

すみません(@@;
少し、見直したら抜けがあったので追記しました。差替をお願いします。
対応命令の印付けも不完全ですので、仕上げにご協力願います。

ダウンロード先
↓
http://hspnext.com/download/hsp_commnd_20161224_10a.zip

dolphilia

2016/12/24(Sat) 19:48:38|NO.77700

kikerogaさん、ご回答ありがとうございます。

http://hsp.dolphilia.com/tinyhsp/tinyhsp_matome_20161224.zip

さっそくまとめに反映させました。

----

sakuraさん、すばらしい貢献です！

HSPランタイム別命令一覧、さっそく差替版を使わせていただきました。

http://hsp.dolphilia.com/tinyhsp/hsp_commnd_20161224_10b.zip

（Mac版の対応命令を最新のものにしました）

----

コンソール版・Linux版は未完なので、
引き続き、自由に編集して、加筆・修正して利用していただければと思います。

sakura

2016/12/24(Sat) 22:54:06|NO.77708

dolphiliaさん

利用して頂いて、ありがとうございます。
完全なドキュメントが少ないので、まだまだ、メンテが必要です。

また、少し加筆しました。

ダウンロード先
↓
http://hspnext.com/download/hsp_commnd_20161224_10c.zip

これから家族と、クリスマスケーキを食べます(^^)

sakura

2016/12/25(Sun) 22:41:23|NO.77723

console版に○印を付けて見ました。
Linux版は、OpenHSPのソースを見て見ると2004年6月から更新されていないのですね。
Wineで動かせるという記事を見たので、今後はLinux専用のランタイムというより
WineやVimの環境を利用するのがよいのかなぁと思います。

修正版です。

ダウンロード先
↓
http://hspnext.com/download/hsp_commnd_20161225_10d.zip

kikeroga

2016/12/26(Mon) 11:57:56|NO.77728

sakuraさん、dolphiliaさん、諸々ありがとうございます。

資料拝見しました。さすがです。素晴らしいの一言です(^_^)

呑気なものでなかなかコメントできないときもあり恐縮ですが、
委細かまわず出来る人にどんどん進めてもらえると幸甚でございます。

> WineやVimの環境を利用するのがよいのかなぁと思います。

ちなみにWineはバージョンが上がると以前動いていたものが
動かなくなるというパターンが少なくないと聞いてますが、
大丈夫ですかね？

Linux環境だと安定した過去バージョンで固定するのも意外と
面倒だったりするのかなと思ってたりしますが。

dolphilia

2016/12/27(Tue) 16:48:11|NO.77734

sakuraさん、一覧の追加更新ありがとうございます！

Linux版の命令を分かる範囲で追加させていただきました。

http://hsp.dolphilia.com/tinyhsp/hsp_commnd_20161227_10e.zip

Linux版でマクロ等を使うには、
以下のファイルを明示的にインクルードする必要があるかもしれません。

- hsp3util.as
- hspdef.as
- hspmath.as

----

kikerogaさん、コメントありがとうございます！

LinuxのWineについてはわかりませんが、
Macを使っているHSPユーザーさんによると、

"macOS 用の Wine は ... 現時点での最新の 1.9.23 から遡ること 1.9.9 まで、HSP が利用している API がうまく動いてくれないようなのです。"

http://www.sharkpp.net/blog/2016/12/01/hsp-advent-calendar-2016-1st-day.html

とのことです。

同時に、Wineを使って開発をしていらっしゃるようなので、
Wineの実用性は十分あるように感じています。

以前にMac版HSPを公開した時、
HSPの「Linux版も作って欲しい」という声があったので、
ネイティブで動作するLinux版HSPの需要はあると思います。

---

TinyHSPの命令について、
もう少し詳しく検討したいと思っています。

* 省く方向で考えている命令

- mouse マウスカーソルの表示位置指定
- width ウィンドウの表示サイズ・表示位置の指定
- run 指定したHSPのAXファイルに制御を移す

以上の命令は一覧から省く方向でいこうと思っていますが、いかがでしょうか。

* 再考したい命令

- #cmd 拡張キーワードの登録
- cnvwtos UnicodeからShiftJISに変換
- cnvstow ShiftJISからUnicodeに変換
- mref 特殊なメモリを変数に割り当て
- dupptr ポインタからクローン変数を作成
- palette, palcolor パレット設定
- onclick, oncmd, onerror, onexit, onkey 割り込み

以上の命令は特殊な命令・移植の難しそうな命令なので、
TinyHSPに加えるか再検討していただきたいのですが、いかがでしょう。

on...系命令は、hsp3dishには一部含まれていないようですが、
とても便利な命令なので、悩むところです。

* 加えても良いような気のする命令

- setease, getease, geteasef

これらの命令は移植が容易だと思われるので、
念のため、再検討をお願いしたいと思っています。

----

これはWeb版HSPに詳しい方にお伺いしたい点なのですが、
emscriptenはOS固有のAPI、例えばWin32APIなどは動くのでしょうか。

OpenHSPからJSに移植する上でのポイントや難所はあるでしょうか。

WebAssemblyは実用的でしょうか。

教えていただけると、とても助けになります。

kikeroga

2016/12/29(Thu) 12:26:55|NO.77751

dolphiliaさん、誠にありがとうございます。

今にも開発に取り掛かってくれそうな勢いを感じます(^_^)

実はTiny BASICの精神を受け継ぎたいという多少懐古な想いもあって
RUN命令はあまり明確な理由もなく残したい気持ちがあったりするんですが、
この命令を省きたい理由って何でしょうか？

各環境でネイティブ動作するユーザ実行ファイルを作るわけではないので
RUN命令の実装が難しい印象はないのですが、ご教示いただけると幸いです。

また、すべての変数を初期化して、制御を完全に別のプログラムに移すという
RUNを代用できる命令って他にはなかったと思いますが、必要性はないでしょうか？

省くことに反対しているわけではないです、念の為(^_^)

それ以外は個人的には異論なしです。

mouse, width 他、特殊な命令・移植の難しそうな（環境依存するような）命令は
そもそもTinyHSPの方針にそぐわないので省いちゃってよかろうと思います。
"Tiny"の目的からいえば命令数が減るのは美点でもあると思いますし、、、
ちなみに palette, palcolor って、あまり必要性ないんですかね？

setease, getease, geteasef については各環境で動かすのが容易なのでしたら
あったほうがもちろん良いと考えます。

on...系命令など、なかなか決めかねる要検討の命令があれば、
開発の妨げにならないよう、さしあたりは仕様上"保留"として実装せずに
進めていってもよいのでは？と思っています。

他の皆さんはどうお考えでしょうか？

以上、よろしくお願い致します。

sakura

2016/12/30(Fri) 13:13:59|NO.77762

資料を更新しました。
ダウンロード
↓
http://hspnext.com/download/hsp_commnd_20161230_11.zip

dolphiliaさん、Linux版の○付更新、ありがとうございます。
kikerogaさん、10年ぶりぐらいお久しぶりです。

資料を整理していて思ったのですが、HSP3Dishやコンパクト版(hsp3c)と変わらなく
なっていくのではないと思うのは、私だけでしょうか?

環境依存が少なく、移植性に優れ、ソースコードレベルで完全互換・・・・
何かもっとインパクトのあるメリットやアイデアが必要のような気がします。
命令中心に絞っていくと既存のものと変わらなく、帯に短したすきに長しのように感じます。

また、WindowsAPI呼び出しがあると互換性維持の面での検討が必要と思います。

dolphilia

2016/12/30(Fri) 16:34:37|NO.77765

kikerogaさん、ご回答ありがとうございます！

RUN命令の件、
思い出があって良いなぁと思います。羨ましいです。
そのような思いは大切にしたいと思っているので、
残す方向に転換したいと思います。

省きたいと思った理由は、私の気まぐれです。^^

palette系命令は、個人的には好きな命令です。

---

sakuraさん、資料の更新ありがとうございます！

> 何かもっとインパクトのあるメリットやアイデアが必要のような気がします。

３つほど案を考えてみました。

1. スマホでゲームが作れる（タブレットPCを含む）

今はパソコンを持たない人もたくさんいます。これが実現すれば、プログラミングを体験していただく良いきっかけになり得ると思います。プログラミングの敷居がぐんと下がるかもしれません。

2. Arduino上で動作する

タイニーさを突き詰める方向性です。フロッピーブートのゲームを作るようなチープな体験ができると思います。これを実現するには今の仕様では大きすぎるので、構文や命令などを大幅に削減することが必要になると思います。

3. モダンな構文にする

これは逆にHSPをモダンな構文にして、オブジェクト指向などの仕様を取り入れる方向性です。需要は少なからずあると思います。とはいえBASIC風の文法やタイニーさは諦める必要があるかもしれません。

ご興味のあるものはあったでしょうか。

おにたま(管理人)

2016/12/30(Fri) 18:14:53|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などと同様に汎用的なライブラリをターゲットに作っておけば、将来的に対応はできるのではないかと思います。

kikeroga

2016/12/31(Sat) 08:46:23|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"

とかして作れば各環境で完全互換になるなら、そんな実装でもＯＫだと思ってます。

いずれにしてもその仕様準拠で動く各環境版のコンパイラとランタイムが必要になるわけですが、
あれこれ検討・模索しながらも楽しみながら進めていければ理想でございます。

sakura

2016/12/31(Sat) 11:24:15|NO.77773

dolphiliaさん、コメントありがとうございます。

>1. スマホでゲームが作れる（タブレットPCを含む）
>プログラミングの敷居がぐんと下がるかもしれません。
HSP一式のアーカイブをダウンロードしてインストールして
スクリプトエディタを起動し、適当なサンプルを読み込んで
少しいじくれば短時間で、それなりのものが作れるという簡便さ
はあります。
でも、少し実用性のある見栄えのするものと作ろうとするとそれなりに
学習コストは高いように思えます。
これは、どの言語にも言えるのですが・・・・
スマホでゲームが簡単に作れるようにする仕様が浮かびません(^^;

>2. Arduino上で動作する
マルチプラットフォーム化は、今後のHSPの活躍の場を広げる意味では良いことと
思います。
HSP3Dishで既に実現しているので、Dishの今後の拡張等に期待したいですね。

>3. モダンな構文にする
構造化等には魅力を感じますが、HSPの開発初期からの言語思想に反するように
思えるのでちょっと賛成しかねます。

個人的にはいずれにしても、Tinyなものにするには、大幅に命令等を削って
超高速化や軽量化した利用用途を限定したものが良いように感じます。
たとえば、ゲーム開発だけに特化するとか、入門用の言語教育に使える簡便なものとか、
可能であれば中間言語方式ではなく本格的なネィテブコードのコンパイラにするとか(^^;

おにたまさん
コメントありがとうございます。
20年以上もサポートして頂いていることにユーザーの一人として感謝致します。
私自身は、今はもうほとんどHSPでプログラミングをすることもないのですが
今後、どのように進化・発展していくのかが楽しみです。

kikerogaさん、コメントありがとうございます。
さて、どんな仕様にまとめられるか・・・・

他の方の意見がほしいところですね。

くちくん

2016/12/31(Sat) 12:19:44|NO.77775

Windows = macOS = Linux = Android/iPhone ( = Web)といった多くのプラットフォームとの
互換性がソースレベルでも保て、難しい命令(?)もけずられていることで
初心者や学生でも学習できる簡単な言語がさらに簡単に学べるようになり、
さらには中・上級者は多プラットフォームへの移行も簡単にできそうな、
ぜひ実現してほしいHSPの形だと思いました。

> 1. スマホでゲームが作れる(タブレットPCを含む)
スマホなどでもゲームなどが作れる。これが実現すれば「簡単に学習・使用」ができるHSPが
さらに簡単に使用できるようになって私はとてもいいと思います。

dolphilia

2017/1/1(Sun) 12:58:41|NO.77791

kikerogaさん、ご意見ありがとうございます。

私も意見交換の場として盛り上がってきて嬉しいです。

TinyHSPという名称についてですが、
このTiny（＝ちっぽけな、とても小さい）という言葉の意味と、
このスレッドで検討されている「クリーンなHSP」とでは、
幾らかイメージが異なってきているように感じます。

また処理系を実装する人たちの習慣に、
遊びで作ったような「とても小さな」処理系に、
Tiny...という名称をつけるという習慣があります。

もし発案者のkikerogaさんのお気持ちが許しましたらですが、
将来的に「TinyHSP」という名称を、
別なものに変えるというのはいかがでしょうか。

---

sakuraさん、ご意見ありがとうございます。

追加していただいた「HSP3言語仕様互換性の検討」、
とても参考にしています。

こうしてみるとHSPの言語仕様は想像以上に大きいのですね。

> Tinyなものにするには、大幅に命令等を削って
> 超高速化や軽量化した利用用途を限定したものが良いように感じます。

私もそのように感じています。
TinyHSPとしては、できるだけ軽量化した処理系を目指すのが良いと思います。

TinyHSPをより軽量化するにあたって、
こうしたらいいんじゃないかというような、
アイデアはおありでしょうか。

---

おにたまさん、ご回答ありがとうございます。

HSPは2.61のころから愛用させていただいています。

> emscriptenなどと同様に汎用的なライブラリをターゲットに作っておけば、将来的に対応はできるのではないかと思います。

ありがとうございます、
それを聞いて安心しました。

> 何らかの成果や技術のフィードバックができれば

フィードバックする方法には、
具体的にどんなものがあるでしょうか。

もしよろしければ、
教えていただけるとたいへん助かります。

---

くちくんさん、ご意見ありがとうございます。

> ぜひ実現してほしいHSPの形だと思いました。

私もこのスレッドで検討されている、
HSPをとても気に入っています。

---

「クリーンなHSP」と「TinyHSP」は、
別々のプロジェクト（仕様）に分けてもいいんじゃないかな、
とも思います。

それで、もし可能でしたら、
まずはより小さい「TinyHSP」の仕様をまとめてから、
「クリーンなHSP」の話し合いに移行できたら良いのかな、
と思っています。

kikeroga

2017/1/1(Sun) 17:19:04|NO.77796

皆様、明けましておめでとうございます！

dolphiliaさん、意欲的なコメントが多くて嬉しく思います(^_^)

> 将来的に「TinyHSP」という名称を、
> 別なものに変えるというのはいかがでしょうか。

それこそまさにArduino上でも動作するような最小限の命令仕様のものが
本来の「TinyHSP」と言えるのでしょうね。

私が提案していたものとは確かにイメージが異なっていると思います。

名称に大きなこだわりはありませんので、より適切な感じの名称があれば
皆さんで色々考えていただけると良いですね。

> より小さい「TinyHSP」の仕様をまとめてから、
> 「クリーンなHSP」の話し合いに移行できたら良いのかな、

上記のような進め方は面白いですね、とても興味深い。

…何となくですが、HSP本家へ何らかの成果や技術のフィードバックが期待できそうです。

私は賛成です(^_^)/

ぜひともよろしくお願いします。

sakura

2017/1/2(Mon) 08:23:32|NO.77805

明けましておめでとうございます！

資料を更新しました。
ダウンロード
↓
http://hspnext.com/download/hsp_commnd_20170101_11a.zip

dolphiliaさん、コメントありがとうございます。
>こうしてみるとHSPの言語仕様は想像以上に大きいのですね。
HSPは、ちょっとスキルがあれば何でも出来てしまう恐ろしい仕様なんですね(笑)

>TinyHSPをより軽量化するにあたって、
>こうしたらいいんじゃないかというような、
>アイデアはおありでしょうか
今は、ちょっとアイデアは思い浮かびません。

本題のテーマである軽量化、クリーンなHSPから外れますが個人的な興味として、
高速に大量のデータ処理ができたり、HSPの優れたグラフィック処理を
利用したデータ分析に応用できたりする強力な専用エンジンがほしいです。
まあ、これはアプリの領域なんですが・・・
現状のHSPでも十分ですけどね。
d3moduleではなくて、d3.jsに匹敵するようなもの、誰か作ってくれませんかね(^^);
余談ですみませんでした。

くちくんさん、ご意見ありがとうございます。
>互換性がソースレベルでも保て、難しい命令(?)もけずられていることで
>初心者や学生でも学習できる簡単な言語がさらに簡単に学べるようになり、
>さらには中・上級者は多プラットフォームへの移行も簡単にできそうな、
>ぜひ実現してほしいHSPの形だと思いました。
HSPの原点回帰という点で目指すべき方向性と思います。

kikeroga

2017/1/2(Mon) 10:35:40|NO.77808

>TinyHSPをより軽量化するにあたって、
>こうしたらいいんじゃないかというような、
>アイデアはおありでしょうか

例えばどの環境でもビルドできそうなC言語の標準命令だけで構築できる命令に絞る
というのも一つの基準になるかと思います。

あるいは最古参であるPalo Alto版TinyBASICの命令仕様に倣うのも一興一案です。
（命令数がとても少ない）

HSPらしい基準にするなら「d3module」が動く！とか、
と…これはあまり軽量化できそうにないですが。

いずれにせよ、TinyHSP→クリーンなHSPという流れに従うなら
TinyHSPはきわめて各環境版をリリースし易いつくりにしたほうがよさそうですね。

Y_repeat

2017/1/3(Tue) 08:08:27|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:18:26|NO.77818

そう言えば　HSPの方針については　あまり議論がされてないみたいだったので
そういう議論もあっていいかもですね
ONITAMAさんも参加されていることから
tinyHSPが実現せずともこの議論にすでにフィードバックしている部分もあるかもしれませんね
dishの仕様とかも未だ流動的かもしれませんし

Y_repeat

2017/1/3(Tue) 08:31:24|NO.77819

自分の黒歴史的に某ゲームの掲示板の常連だった黒歴史がありまして
意見はしても自分で作る訳ではないもどかしさがあったので
プログラミングを再開させたんですが
自分はなくても大丈夫みたいなスタンスで論じてしまうので
ってかそんなんだからあんまり議論の火蓋はきらなかったんですが

たぶん仕様を決める人も大事で
ってか時に作業をする人より上に置かれるくらい
なので貫きたいことがあったら　叩かれても曲がらない釘のごとく
貫いて欲しいですね
自分は結局叩かれると曲がってしまう釘のようなので

おにたま(管理人)

2017/1/3(Tue) 10:59:01|NO.77822

HSPはもともと難しい前準備なしにエディタを起動して、いきなりソースを打ち込んで使える簡便さが大きな魅力でした。
ライブラリが肥大化したことで、できることは増えたのですが、どの機能を使っていいか、どの命令がプラグインに依存しているかなど
混乱する要素も増えてきていると感じています。何とかするべき所だとは思っていますが(^^;
そういった意味では、初心者やちょっとした用途で汎用的に使えるシステムは、制約はあるものの原点に戻ってシンプルさがあって一定の需要があると考えています。

>sakura さん

>20年以上もサポートして頂いていることにユーザーの一人として感謝致します。

ありがとうございます!
素晴らしい資料の作成、相変わらずの良い仕事ですね。
命令を削って軽量化という方向も間違っていないと思います。

>dolphilia さん

>フィードバックする方法には、
>具体的にどんなものがあるでしょうか。

ソースコードが公開されていれば、有用なコードや変更はこちらでOpenHSPに取り込むことが可能です。
また、TinyHSPなど他のランタイムと共用して修正のしやすい形でOpenHSP側のソースコードを変更するなどのフィードバックもできるかと思います。

機能の拡張よりも、最小限に削ってまとめることの方が難しい作業だとは思いますが、
必要なものを見極めた上で大胆に削って、限定した形になることを願っています(^^
ちなみに、私もpalette系の命令は愛着がありますが、最近のビデオカードやマルチプラットフォーム化を考えると余計なものになっていると思います。

dolphilia

2017/1/5(Thu) 12:40:16|NO.77847

kikerogaさん、ご回答ありがとうございます。

> 名称に大きなこだわりはありませんので、より適切な感じの名称があれば
> 皆さんで色々考えていただけると良いですね。

賛同していただけて嬉しいです。
早速いくつか案を考えてみました。（末尾に記載します）

> 例えばどの環境でもビルドできそうなC言語の標準命令だけで構築できる命令に絞るというのも一つの基準になるかと思います。
> あるいは最古参であるPalo Alto版TinyBASICの命令仕様に倣うのも一興一案です。

とても面白そうです！　参考にさせていただきます。

---

sakuraさん、素晴らしい資料をありがとうございます。

とても参考にさせていただいています。

「HSP本体機能を含めた周辺機能」などは、
まだこのスレッドではほとんど検討されていないので、
そういった点も追々検討していてければいいな、
と思っています。

> 高速に大量のデータ処理ができたり、HSPの優れたグラフィック処理を
> 利用したデータ分析に応用できたりする強力な専用エンジンがほしいです。

私もHSPに正規表現が標準で搭載されたら良いなとか、
深層学習やVR・AR技術を実行できるようなエンジンがあれば良いな、
なんて考えたりします。

なんとなくですが、このスレッドではそういったことも、
自由に発言して良い雰囲気があるような気がしています。

---

Y_repeatさん、ご意見ありがとうございます。

> 自分は仕様を決めるにしてもWEBに決めたことを載せちゃうと実行しないので

すごくよく分かります。私も「これこれをやります」と言ってしまうと、実現できなくなるジレンマによく陥ります。

> 全部で１万行くらいのプログラム言語作成学習用であったらなあ。と思います

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（未来の）

この中に適切だと思う名称はあるでしょうか。

kikeroga

2017/1/5(Thu) 18:35:19|NO.77849

個人的な印象ですが、SmallやLightだと派生の一つに過ぎないイメージ。
Commonは意味合いがぴったりですが地味な感じがします。
NextやFutureは大胆でいいですねー！

CommonとFutureは捨てがたく、決めかねるのですが、
やっぱり最初から言われてた「Clean HSP」が良いかも…(^_^)

「不要なものを取り除く」「よごれのない」という意味合いから
ふさわしいような気がします。

名称はイメージが大事だと思いますので、他の方の意見も欲しいところです。

kikeroga

2017/1/5(Thu) 18:41:05|NO.77850

「Clean HSP」が良いと言っときながら
私もいくつか挙げさせていただきたいと思います。

AnyHSP(どこでも・誰でも)
HSP Multi(マルチプラットフォーム)
Cross HSP(クロスプラットフォーム)
Pure HSP(まじりけのない・純粋な)
Basis HSP(基本の)

思いつくと書かずにいられない…どうもすみません(^^;

Y_repeat

2017/1/6(Fri) 01:21:40|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もちょこちょこ写経とか書写とかしてます

sakura

2017/1/6(Fri) 21:03:10|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が世界に羽ばたけるような実務に密着した実用性の高いものになると良いですね(笑)

おにたまさん、コメントありがとうございます。
まあ、どれだけサポートが出来ているのかわかりませんが、資料は整理しておくと
誰かの役に立つのかもしれません。
このスレッドを楽しんでやっています。

2017/1/7(Sat) 19:19:40|NO.77857

現在の名称を仮称とすれば良いのでは？

色々議論するのも良いのですが、取りあえず土台とし
て極簡単な物を作るのが最優先だと思います。

仕様を固めた上で作るのは当然重要ですが、ある程度
作り込んでテスト公開したら動作不良ばかりで、修正
を繰り返したらソースがスパゲティーになって訳が分
からない状態になったり、もしかしたら開発環境自体
を考え直す必要になるかも知れません。

互換性を担保出来る最小限の命令や関数だけなら、ま
ず不具合も無いだろうし問題が有ってもキズは浅くて
済みます。あとは段階的に命令を増やして最終目的に
持って行きます。

それと人間の欲求に限りは有りません、特に多数の意
見を求める場合は、目標を高く設定することになりが
ちです。暫定仕様として一旦線引きするのも重要です。

暫定目標としてはＨＳＰ２相当の命令・関数から、マ
クロ定義されている物や、特殊な使い方が必要なもの
（極端に言えばプリプロセッサ全て）を消せば、相当
シンプルな物しか残らないでしょう。この辺りを暫定
目標として話を進めた方がスムーズに行きそうな気が
します。

sakura

2017/1/7(Sat) 22:10:13|NO.77860

KAさん
>色々議論するのも良いのですが、取りあえず土台とし
>て極簡単な物を作るのが最優先だと思います。
進め方としての、ご意見に賛成ですが、実現の可能性は別として
色々議論する過程を楽しんでいる人も多いのではないかと思います。

>暫定目標としてはＨＳＰ２相当の命令・関数から、マ
>クロ定義されている物や、特殊な使い方が必要なもの
>（極端に言えばプリプロセッサ全て）を消せば、相当
>シンプルな物しか残らないでしょう。この辺りを暫定
>目標として話を進めた方がスムーズに行きそうな気が
>します。
同感です。今回のTinyHSPの目標実現としてはHSP2相当が良いと考えます。

しかし、極端に命令が少ないと作れるものも制限されるし、
少し、いいものを作ろうとするとかなりのスキルが要求されるように
思えます。HSP2時代の初期の頃も、拡張プラグインに頼っていましたね。

資料更新しました。(ほぼ、最終更新版となります。しばらく、更新しません。)
↓
http://hspnext.com/download/hsp_commnd_20170107_11c.zip

2017/1/8(Sun) 00:43:54|NO.77862

>>sakuraさん
その「楽しむ」が、それで終わりに成らないと良いんですが・・。

過去、方向性は異なりますが、似たような考えで立ち上げたサイト
が殆ど機能していない現実問題として、「なぜ機能していないのか」
を分析してみる必要はあると思います。

ＨＳＰ２相当と言ったのは、あくまで開発者側の立場で「暫定」とし
ています、当然利用者側から不満は出てくるでしょう。その不満を元
に適時バージョンアップし、不具合を修正していくという意味合いで
す。

話の途中で水を差したくは無かったのですが、似たような過去の失敗
を教訓として今後に生かす姿勢はほしいです。

毎回文句（イチャモン）ばかり言っていますが、今回のプロジェクト
に否定的な訳ではありません。議論をまとめるのなら閑古鳥の鳴いて
いるサイトを再利用したり、論点が多肢に渡るのなら論点毎にＷＩＫ
Ｉ形式にするなど、やりやすい方法はあると思います。

この読みやすいとは言えない掲示板で、あれやこれや議論が飛び回っ
ていては、読みにくくて仕方がありません。

辛辣（かな？）な書き方ですが、何かの参考になれば幸いです。

sakura

2017/1/8(Sun) 08:24:20|NO.77863

KAさん
コメントありがとうございます。
>その「楽しむ」が、それで終わりに成らないと良いんですが・・。
終わりになる可能性は否定しません。
私も、過去このようなブロジェクト的なものを多く見てきましたが
うまくいったものは、ほとんど知りません。

>毎回文句（イチャモン）ばかり言っていますが、今回のプロジェクト
>に否定的な訳ではありません。
危惧されていることや、HSPに対する気持は発言から十分読み取れます。
貴重なご意見、ありがとうございます。

まあ、たまには今回のようなスレッドでの議論も良いのではないでしょうか?
議論の成り行きにイライラする人もいるのかもしれませんが・・・・

KAさんの見識で力を貸して頂ければ、ここに参加している皆さんも力強いと
思うのですが・・・・

Y_repeat

2017/1/8(Sun) 22:38:34|NO.77867

とりあえずCで使うライブラリの開発は始まってどうでしょうか
ってやる人いないのかな？

とりあえず
言語としてはＣ言語まんま（開発後回し）で　クリーンＨＳＰのライブラリを使用
ってかんじでどうでしょうか？
それでもある程度ＨＳＰ感覚で開発できるでしょうし

自分の中間言語もまったくライブラリ書いてないので
そういうのがあると非情にありがたいです

自分の中間言語はそろそろＣに移植かな？って思ってるとこです
gosub的サブルーチンを実装すれば　中間言語としてはある程度完成です
配列もまだ実装してないか

>>その「楽しむ」が、それで終わりに成らないと良いんですが・・。
>終わりになる可能性は否定しません。
>私も、過去このようなブロジェクト的なものを多く見てきましたが
>うまくいったものは、ほとんど知りません。
面白そうな企画なのですが
この書き込みを見て心配にはなりました

Y_repeat

2017/1/8(Sun) 22:53:18|NO.77869

Ｃで開発するならＣで開発するとして
新しい言語を開発するのではなく
Ｃスクリプトを生成するかんじだとどうでしょうか
ってＨＳＰＣもそんなかんじでしたっけ？
動けばいいってんじゃなくて
生成後のスクリプトも人間が読みやすいかんじでお願いします
自分の中間言語も親言語記述をそのまま受け入れようと思っているのですが
仕様がなかなか固定しないですね
現状、自分しか使えない。みたいなｗ
自分でも上手く動かし方がよくわかってない。みたいなｗ
機械的に決まってる仕様をエデイタ的ツールでカバーしようとは思っているのですが

2017/1/8(Sun) 23:45:31|NO.77871

sakuraさん

言いたくは無いけどつい言ってしまう性分で、自覚は
していますが中々直らない物です。

私の見識など何の役にも立たないと思いますが、書く
と長くなるので、しばらくは静観します。

kikeroga

2017/1/9(Mon) 12:25:49|NO.77877

sakuraさん、本当にありがとうございます！

Y_repeatさん、
多様なご意見、ありがとうございます。
「Academic HSP」もなかなかいい発想だと思います。
名称は成るようになるでしょう！(^o^)

KAさん、
強い興味を抱いていただいていることに感謝します。
sakuraさんもおっしゃってるように進め方に関するご意見に異論はありません。

このスレッドは"TinyHSPの提案"として立てましたが、

・おのたま氏がコメントし、そのプロットと意義を認めてくれたこと
・sakuraさんが大変素晴らしいベースドキュメントを作成してくれたこと
・dolphiliaさんがtiniyhspのプロジェクトを開設してくれたこと

と十二分な成果を果たしており、その役割を終えているように思います。

今以上に論議を発展させる場所としては、ご指摘の通りWikiやその他の仕組みで
進めるほうが適切だとは思いますが、これから先のことも、私自身も含めて
何がどうなろうと、誰かができることをやるだけです。

少なくともこのスレッドを立てた意義は想定以上に大きかったようで
良かったと思っています。

あとはもう成るようになるでしょう！(^o^)

sakura

2017/1/9(Mon) 14:23:34|NO.77885

Y_repeatさん

>言語としてはＣ言語まんま（開発後回し）で　クリーンＨＳＰのライブラリを使用
>ってかんじでどうでしょうか？
>それでもある程度ＨＳＰ感覚で開発できるでしょうし

>自分の中間言語もまったくライブラリ書いてないので
>そういうのがあると非情にありがたいです
私は、C言語は昔、HSPの拡張プラグインを作成する時に少しだけ
かじった程度の素人同然ですが、2004年当時、似たようなことができないかと
試行錯誤したことがあります。
過去のフォルダを探してみたら、ゴミみたいのものですが、
参考になるかどうかわかりませんが、ソースがありました。
必要な部分を部品として活用して頂けたら、ありがたいです。
あまりに幼稚な書き方でみなさんに笑われるかもしれませんが、アップ
しておきます。
http://hspnext.com/download/HSP参考程度のゴミソース.zip

>面白そうな企画なのですが
>この書き込みを見て心配にはなりました
すみません。何か心配させるようなことを書いて・・・・
KAさんと同様、このプロジェクトがうまくいってほしいという
思いを理解して下さい。

KAさん
コメント、ありがとうございます。
>言いたくは無いけどつい言ってしまう性分で、自覚は
>していますが中々直らない物です。
私の個人的な見解ですが、物事の本質を見極めての発言と理解しています。
なかなか、本質や本音を言える人が少なくなっているので、・・・・

kikerogaさん
>少なくともこのスレッドを立てた意義は想定以上に大きかったようで
>良かったと思っています。

>あとはもう成るようになるでしょう！(^o^)
もう少し、がんばってみますか(^^;

kikeroga

2017/1/9(Mon) 16:57:09|NO.77891

下記、大変失礼しましたm(_ _)m

誤）おのたま氏
正）おにたま氏

> もう少し、がんばってみますか(^^;

sakuraさん、

貴重なソースを公開して頂き、ありがとうございます。
勉強させて頂きます。

私も何か心配させるようなことを書きましたかね(^^;
ネットの発言は温度感が難しいですが
「もうヤメましょう」という意味合いではないので
今後ともよろしくお願いします。

Y_repeat

2017/1/10(Tue) 07:30:29|NO.77899

kikerogaさんへ

>このスレッドは"TinyHSPの提案"として立てましたが、
>・おのたま氏がコメントし、そのプロットと意義を認めてくれたこと
>・sakuraさんが大変素晴らしいベースドキュメントを作成してくれたこと
>・dolphiliaさんがtiniyhspのプロジェクトを開設してくれたこと
>と十二分な成果を果たしており、その役割を終えているように思います。
>今以上に論議を発展させる場所としては、ご指摘の通りWikiやその他の仕組みで
>進めるほうが適切だとは思いますが、これから先のことも、私自身も含めて
>何がどうなろうと、誰かができることをやるだけです。
>少なくともこのスレッドを立てた意義は想定以上に大きかったようで
>良かったと思っています。

そうでしたね。ここのスレッドは"TinyHSPの提案"というタイトルでしたね
そういうタイトル的には結構役目を果たせたかもしれません
ではこのスレッドを受け次のスレッドを立てて欲しいなあとも思います
僕もwikiを立てましたが僕のwikiなんてたいして訪問者いないでしょう
なので引き続き公式BBSで議論をするなら続けて欲しくあります

自分もプログラム言語作成を目標としてやってる身としては実りありましたので

僕の今年は10年計画の3年目くらいとしての目標は
ドラゴンブックを購入して読破する！ですｗ
言語開発者としてこの書籍を読破していない人はモグリと某書籍に書いてあったので
いつか読まなきゃなあと思っていたところです
RHGも2014に購入して読破していない僕ですが
せめて購入して一か月につき一章づつ読む。を今年の抱負にします

HIJIKI

2017/1/10(Tue) 13:17:09|NO.77902

この企画には大変肯定的です。
だからこそ言わずにはいられないのですが、すでに話にも出ているように、
ここでこのまま議論を続けるのはよい選択ではないように思います。

口の悪い言い方になってしまいますが、
現状はこの企画とは直接関係のない話題が飛び交いすぎていて
(それが悪いことだと言うつもりはありませんが)、
このままでは雑談スレッドに成り果ててしまう気がしてなりません。

専用のフォーラム等を設け、問題点をピックアップして
個別に解決してゆくような形になれば、
もっと議論の内容が把握しやすい状態で話が進むのではないでしょうか。

現状どういう問題について決め兼ねているのかを把握しやすくなれば
それぞれの問題の解決手段について意見する人ももっと増えるはずです。

HIJIKI

2017/1/10(Tue) 13:35:57|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を利用してきたユーザーも(追加学習も必要なく)案件によって
使い分けることができて良いのではないでしょうか。

----

長くなりましたが、何かの参考になれば幸いです。
この企画の成就を心よりお祈り申しあげます。

Y_repeat

2017/1/10(Tue) 14:13:47|NO.77904

こんにちわ

自分のとこのmediawikiですが
デフォルトでもハイライトしてくれて頼もしいんですが
自分が利用しているロリポップの鯖は
データベースが一人一つしか運営出来ないみたく書いてるとこがあって
mediawikiは一つしか運営できないっぽいです
という訳でせっかくのmediawikiですので　もっと活用したいですね

というところで
次のスレッドを立てるとしたら　どういう趣旨のスレッドにすべきか
そういう話もした方がいいのではないか？と思います

このスレッドは　TinyHSPの提案　ということで「提案・要望」スレッドとなっています

>このままでは雑談スレッドに成り果ててしまう気がしてなりません。
という懸念をHIJIKIさんが持たれているようなので
逆に最初から「雑談」スレッドとして立ててみてはどうでしょうか
とはいえあまり重要ではない雑談は自分のとこのwikiでってことでお願いします

dolphiliaさんのtinyHSPも開発の途中経過とか
更新履歴削除って書いてましたが
せっかくなので更新履歴はUPし続けて欲しいですね
開発の提案だけして　梯子を外すみたいなのは悪いなあ。と思いませんか？

後はさくらさんがドキュメントをもう少し加筆するようなので
それも期待出来ます

自分も言語作成をテーマにプログラミングしてる身としては
モチベーションの上がる小論文（＝エッセイ）の執筆お待ちしています

このスレッドと連携して今年の抱負とか書いてもいいですし
今後半年の抱負でも４半期の抱負でも今月の抱負でも
展望によって抱負の期間はお任せします

自分のとこのwikiに関する意見もありましたら
そういう話も出ていいと思います

他にも次のスレッドで　議論したいテーマがありましたら
書き込みましょう

という訳で　次のスレッドお待ちしてまーす
２、３日くらい間をあけて　誰も次のスレッドを立てないようでしたら
僕が「雑談」スレッドを立てます

Y_repeat

2017/1/10(Tue) 17:07:15|NO.77905

KAさんの助言に従い　ここのとことかの　まとめサイトなwikiを開設しました

http://zuzazann.boy.jp/media_wiki_120/index.php?title=メインページ

・運営方針　ちょいちょい変更してますｗ

kikeroga

2017/1/11(Wed) 11:44:34|NO.77908

HIJIKIさん、ご賛同ありがとうございます。

欲しいですよね、こんなHSP(^_^)

名称に関しては色々候補を出しておいて、実際には
開発する方が気に入ったものを付けてくれればよいかと
私は思っております。

Y_repeatさん、色々ありがとうございます(^_^)

TinyHSPの話題が継続されるのは良いことだと思います。
次のスレッド、お任せいたします。

Y_repeat

2017/1/12(Thu) 01:31:28|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さん
ほめてただいたりして　こっぱずかしいですｗ