秀丸マクロへの「ヒアドキュメント」の実No.08136
あきくん さん 16/07/20 14:39
 
■ごあいさつ
いつもお世話になっております。

普段は「天翔記.jp」などの名で秀丸マクロライブラリに登録させていただいており
ます。

こちらに投稿するのが相応しいのか、β版に要望するのが適切なのか
迷いましたがこちらに投稿させて頂きます。


■ヒアドキュメントの要望
さて、今回お願いしたいのは、秀丸マクロに「ヒアドキュメント」の機能を
実装して頂きたいというものです。

Ruby/Perl/PHPなどに「ヒアドキュメント」という機能がありますが、
中でも特に実装して頂きたいのが、シングルクォーテーションタイプのヒアドキュメ
ントです。


■シングルヒアドキュメントとは
例えば

-------------------------------------------
$my変数 = <<<'MYLABEL'
あああ\n
いいい
    "いう'おおお"
MYLABEL
-------------------------------------------

といた記述の場合、
'MYLABEL'の「次の行」〜MYLABELの「前の行」までの文字列は、

あたかもそれら文字列は
・元々別のファイルに記述してあって
・それを読み込んで、$my変数へと文字列を代入した
かのように振る舞うというものです。

上記の場合、\nはあくまで「\n」という文字列となり、改行相当に内部コンパイルさ
れたりはしません。
(\nと記述ががる別ファイルを読み込んだ場合、「\n」という文字列になるのが普通
だからです)


■より理想的には

さらにいいますと、(取り扱うシンボルの組み合わせを工夫して)
変数への代入が不要なタイプが実装可能であれば、その方がかなり便利になるはずです
┌ (一時的に変数へと代入しなくても、そのまま文字列引数として扱える)
#_ = dllfunc(#dllref, "ReqStrFunc", <<<'MYLABEL'
あああ\n
いいい
    "いう'おおお"
MYLABEL );


■この機能実装によるメリット

この機能1点の実装により以下のメリットがあり、秀丸マクロの可能性拡大に大いに
役立つと考えております。

@秀丸マクロの中に他の言語を直接書けるようになる
A秀丸マクロの中に他のデータを直接埋め込めるようになる
といったモノとなります。

特に@のメリットは計り知れないと考えています。

@により、事実上、
・秀丸マクロ内に記述する言語は、秀丸マクロでなくても良い。
 一般的な強力なる汎用プログラミング言語、あるいは独自言語にて、大部分の処理
を記述してよい
 (ちょうどHTML内にそのままJavaScriptやVBScriptやRubyScriptが書ける感覚です)
A内部に記述することにより、秀丸マクロ上の変数と、
該当言語上のグローバル環境変数とのやりとりが簡単になる。

以上となります、ご検討くださいますよう、よろしくお願いします。

[ ]
RE:08136 秀丸マクロへの「ヒアドキュメンNo.08137
秀丸担当 さん 16/07/21 16:33
 

ヒアドキュメントのような記述方法ができたら、いろいろ用途があると思います。
ただマクロの読み込みや変数の出し入れはそれほど効率が良くは無く、DLLを呼
び出すのであればテキストファイルのパスを渡した方がいいかもしれません。
また、秀丸マクロの変数や文字列は、バージョンを重ねるごとに上限を増やして
きてはいますが、無制限というわけにはいかず、上限はあります。
現状は変数用のメモリは約1MBです。
複数のプロセスをまたがって共有しているメモリの関係上、どうしても上限は必
要になってきます。

言語を問わずできるような手法を考えるとしたら、秀丸ファイラーClassicで
採用しているような、Windows Script Hostを使う方法が考えられます。
本体側の実装は1つで、JScriptやVBScriptが使えたりします。
ただ秀丸エディタでこれをやる予定は無いです。
複数のプロセスをまたぐことが難しいということと、幾つもサポートすべきもの
が増えると大変になるということで、いまのところする予定は無いです。

[ ]
RE:08137 秀丸マクロへの「ヒアドキュメンNo.08138
あきくん さん 16/07/21 18:53
 
お返事ありがとうございます。
ヒアドキュメントの件、ぜひともご検討下さい。


メモリの問題ですが、ヒアドキュメントとして秀丸内部にプログラムをそのまま記述
したとしても
記述した文字列の分のメモリは
秀丸マクロが担うことになりますが、
その先の処理やメモリ確保は、秀丸マクロが担うわけではないので
あまり問題とはならないのではないでしょうか。
(もちろんずらずらと5000行、10000行と.macファイルに詰め込めば別ですがw)

今回作成した、hmPyでも秀丸マクロ内のインプロセスとして、
.NETを使って、いろいろ表示等おこなっていますが、
使用メモリ自体は、数十メガいってるでしょうが、問題ありません。

むしろ大部分の変数を秀丸マクロ内→インプロセスの外部言語
へと出せるので、秀丸マクロ自体が保持する必要がある変数は減る傾向がでると思い
ます。


■Windows Script Host
IActiveScript系IFを持つCOMコンポーネント、
関連のテクノロジーや実装方法はもちろん存じ上げておりますが、
現代ではすでに 「deprecated」に近いような扱いだと思っています。

私自身が秀丸用にhmPyを作ったのはこの大いなる制限事項から脱却し、、
現在主流となるマネージドdllに秀丸を対応させたいという願いからでした


■追加要望となるloaddllのマネージド版「loaddotnetdll」
hmPyを作る際に、少し躓いたところでもあったのですが
Microsoft/Apple/Googleの戦略を見るに、C/C++を使える人・使う人は
今後ますます少なくなってくるのは確実な路線のように思われます。

Windowsにおいても、少なくとも個人ユースやツールユースではC#が
中心となるでしょう(すでになっていますが)

その観点から考えて、loaddll関数を拡張し、マネージドアdllとしても読み込めるよ
うにした、
「loaddotnetdll」関数の追加などが遠からず求められるのではないかと思います。

以上、ご検討ください、よろしくお願い致します。

[ ]
RE:08138 秀丸マクロへの「ヒアドキュメンNo.08139
でるもんたいいじま さん 16/07/21 23:50
 
でるもんた・いいじまです。

本件、個人的には(あくまで個人的にですが)ちょっと違和感を感じる
ところがあります。

> Microsoft/Apple/Googleの戦略を見るに、C/C++を使える人・使う人は
> 今後ますます少なくなってくるのは確実な路線のように思われます。
> Windowsにおいても、少なくとも個人ユースやツールユースではC#が
> 中心となるでしょう(すでになっていますが)

AppleとGoogleを持ち出してくるあたり、いかにも「最新版の環境を
常に追いかけよう」という発想だと思います。

確かに、そういった「不特定多数に配布して、みんなで同じものを
使ってもらうタイプのソフトウェア」は、ベンダーのサポート対象に
なっているバージョンのOS(今ならVista以降)だけで動けばいいので、
確かにC#なりVB.NETなりで開発するのが合理的でしょう。

でも世の中はそれだけではなくて、「世界に一台しかない機械を制御
するためのコンピュータと、その機械のために自前で専用開発した
ソフトウェア」というものも多々動いています。

そちらのOS事情は今どうなっているかというと、PC-9821+MS-DOSの
環境がそろそろ物理的に寿命を迎えて、やっとWindows98やWindowsXP
への移行を終えたところ」でしょう。そういう環境にも「メモ帳じゃ
話にならん、何かいいエディタはないか?」という需要はあるわけで、
秀丸は今のところ、そういう需要にも何とか応えようという方針で
動いています。

なので、「CPUとメモリを馬鹿喰いしてもイマドキ問題にならないから、
sophisticatedな設計でプログラムを書こう」という方向性からは、
今のところ秀丸は距離を置いているように思います。

ただし、

> loaddll関数を拡張し、マネージドアdllとしても読み込めるようにした、
> 「loaddotnetdll」関数の追加などが遠からず求められるのではないかと
> 思います。

という点に限ると、確かに.NETのDLLを呼び出せる機能はあってもいいと
思います。C/C++でDLLを書くのは骨だけど、VB.NETでなら書ける、という
人はご指摘のようにこれから増えていくでしょうから。

#それにしても、秀丸のloaddll()をcdecl呼び出しにしてしまったのは、
#今となっては厄介ですね。stdcall呼び出しにしていればWin32 APIを
#呼び出したり、あるいは同じDLLを秀丸マクロとExcelマクロとで共用
#したりということが簡単にできたのですが。

#ちなみに、x64の世界では呼び出し規約はWindows方式とLinux方式の
#2種類しかないので、64bit版の秀丸ならWin64 APIを呼び出せるの
#ではと推測しています。

[ ]
RE:08139 秀丸マクロへの「ヒアドキュメンNo.08140
あきくん さん 16/07/22 00:28
 
>思います。C/C++でDLLを書くのは骨だけど、VB.NETでなら書ける、という
VB.netではなく、C#の人が増えてくると思いますね。

個人的にはC/C++やアセンブラを交えて書くのは趣味ではあっても、
どれほど慣れているC++でも、慣れていないC#の方が開発速度が出るのが実情です。
C++25年 vs C#は数ヵ月に1度しかかかないとかの比較ですら、C#の方が書くのが速
いほどなので
それが許される分野では、当然C#が使われるでしょう。

特にdynamicであることが必須要件に入ってくるとC++はその性質上太刀打ちできない
わけで、
テキスト記述のマクロやスクリプトの世界とは多分にdynamicであることが求められ
る分野です。


また、cdeclもおっしゃるように微妙でしたねぇ。
ただ、これについては、将来秀丸にffiやalien的なものを実装すれば、
対応できるでしょうから、それほど問題視していません。
(自分自身は、テキストで即書きたい場合は、luaffiで対応しています
 大抵すぐにCで置き換えてしまいますが…)

[ ]
RE:08140 秀丸マクロへの「ヒアドキュメンNo.08141
でるもんたいいじま さん 16/07/22 01:01
 
でるもんた・いいじまです。

> >C/C++でDLLを書くのは骨だけど、VB.NETでなら書ける、という
> VB.netではなく、C#の人が増えてくると思いますね。

そういうものなんですか。
当方、.NETの開発事情はまったく存じ上げません。

> C++25年 vs C#は数ヵ月に1度しかかかないとかの比較ですら、
> C#の方が書くのが速いほどなので
> それが許される分野では、当然C#が使われるでしょう。
>
> 特にdynamicであることが必須要件に入ってくるとC++は
> その性質上太刀打ちできないわけで、
> テキスト記述のマクロやスクリプトの世界とは多分に
> dynamicであることが求められる分野です。

まあ、C++の場合、そのへんが全体的に貧弱ですよね。

ただ個人的には、秀丸マクロ単体では記述が困難だけどC#を使えば
劇的に楽になる、しかも秀丸とC#との間でデータのやり取りが頻繁に
発生する、というケースがなかなか思い当たりません。

#データのやりとりの頻度が少なければ、単純に標準入出力なり
#中間ファイルなりでやりとりすればいいだけの話です。
#あるいは、辞書検索の類ならC++でもそんなに難しくはありません。

もしそういうことが発生するのであれば、秀丸に頼らずに、すべての
処理をC#上で完結させてしまったほうが効率がいいように思います。

[ ]
RE:08141 秀丸マクロへの「ヒアドキュメンNo.08142
秀丸担当 さん 16/07/22 10:24
 

ヒアドキュメントについては、それを他言語用に使うかどうかはともかく、制約
はあるものの、あったらあったでいいと思います。
ちなみにC++11の文字列リテラルには、"文字列"を、
R"(文字列)"
または
R"MYLABEL(文字列)MYLABEL"
といったように書く方法があるようです。
これに倣うと、現状で正規表現で\をエスケープするのが面倒ですが、単純にそ
れを取り除く一行だけのためにも利用できそうな気がします。
ヒアドキュメントに近い使い方もできそうです。

.netの呼び出しは、現状でCOM(component object model)を使って呼び出すこと
ができると思います。
例えばHidemarnet Explorer with FTPSは.netですが、COMでアクセスできるよう
にもしてあります。
たまに使われる手法として、URLエンコードでHidemarnet Explorerのメソッドを
呼び出す方法があり、COMを介していますが実際は.netです。

例:
#obj = createobject("hmnetast.hmnetex");
if(#obj != 0){
  message getpropstr(#obj, "URLEncode", "abcあいうえお",2);
}
endmacro;


cdeclについては引数の個数の制約を持たせないこともあってそうしていたと思
います。
Win32APIでも、wsprintfだけはcdeclだと思います。
どのみちポインタや構造体のことを考えると、マクロ上で直接Win32APIを呼ぶの
は現実的ではないと思います。
やるとしたら、tkinfo.dllでやっているようなバイパス用の関数を入れたDLLを
作るほうが現実的だと思います。

[ ]
RE:08142 秀丸マクロへの「ヒアドキュメンNo.08143
あきくん さん 16/07/22 15:14
 
■ヒアドキュメント
>ちなみにC++11の文字列リテラルには、"文字列"を、
数年前からC++ではそのように記述しています。
C#の@""の影響も多分にあったことでしょう。

可能であれば、「1行ではなく、多行に対応していただけるとありがたい」です。
(多行であると、ものすごく幅が広がりますので)

■COM
>.netの呼び出しは、現状でCOM(component object model)を使って呼び出すことがで
>きると思います。

ご存知かもしれませんが,COM経由で呼び出し可能な.netクラスは、0.1%もない状況
だと思います。
COMの性能では、.NETの複雑な型が表現できないため、手作業で、COMラッパーを作る
作業が必要です。

COMで.NETのクラスが〜みたいなのが言われた時のサンプルは、
いずれも「ArrayList」か「Math.random」のはずで、
これらはたまたまAPIが簡素なので、COMで表現できる範囲であったに過ぎません。

■cdecl
理由はきっとvaarg系のためだろうなぁ、とは思っていました。
どの道受け口bufferの問題があったハズでしょうから、確かに一長一短だったと思い
ます。
あえて、stdcallも呼べるように作るとすれば、
---------------------------------------------------------------
#dll = loaddll (...)
dllfunctype( #dll, "FuncABC", "stdcall") -- ★★ 「指定のdll」の「指定の関
数」に対して「呼び出し規約」を「設定」するための関数dllfunctype
dllfunc( #dll, "FuncABC", 1,2,3)
みたいな形ですかねぇ。なかなかの後付け感丸出しですが〜w
---------------------------------------------------------------

[ ]
RE:08143 秀丸マクロへの「ヒアドキュメンNo.08144
でるもんたいいじま さん 16/07/22 16:30
 
でるもんた・いいじまです。

別件で少々不機嫌なので、御無礼ご容赦を。

> 可能であれば、「1行ではなく、多行に対応していただけるとありがたい」です。
> (多行であると、ものすごく幅が広がりますので)

これ↓では不満ですか?
$s = "1行目\n";
$s = $s + "2行目\n";
:
$s = $s + "N行目\n";

ヒアドキュメントでなければいけない理由が全く分かりません。
ヒアドキュメント機能のない言語は山ほどあります。


>>.netの呼び出しは、現状でCOM(component object model)を使って
>>呼び出すことができると思います。
>
> ご存知かもしれませんが,COM経由で呼び出し可能な.netクラスは、
> 0.1%もない状況だと思います。
> COMの性能では、.NETの複雑な型が表現できないため、手作業で、
> COMラッパーを作る作業が必要です。

「複雑な型」のデータを秀丸マクロで受け取ってそのまま利用したければ、
秀丸全体を.NETで再実装しなければならなくなります。
そうするとWindows98どころか、Windows2000でも動かなくなります。
Windows XPでの動作も怪しくなります。

> あえて、stdcallも呼べるように作るとすれば、
> #dll = loaddll (...)
> dllfunctype( #dll, "FuncABC", "stdcall") -- ★★ 「指定のdll」の
> 「指定の関数」に対して「呼び出し規約」を「設定」するための関数
> dllfunctype
> dllfunc( #dll, "FuncABC", 1,2,3)
> みたいな形ですかねぇ。なかなかの後付け感丸出しですが〜w

dllfunctype() で設定した内容はどこに保存しておくのでしょう?
強引にやるとしたら、ここはむしろ、
dllfunc2(#dll, "stdcall", "FuncABC", 1, 2, 3)
でしょう。

☆ ☆ ☆

結論として、たったの4000円(+税)しか払わずに、極めて個人的な無茶を
サイトー企画さんにゴリ押ししている時点で、何か間違っていると思い
ませんか?4000円の全額を開発者への賃金に充てるとしても、2-3時間
あるかないかですよ?

どうしても秀丸で.NETの機能を100%使いたいのであれば、まず最低でも
100万円をポーンとサイトー企画さんに寄付して然るべきです。
それだけのオカネを出したくないのなら、.NET版のVisual Studioは
既にお持ちでしょうから、そちらのエディタをご自分でカスタマイズ
してはいかがですか?

[ ]
RE:08143 秀丸マクロへの「ヒアドキュメンNo.08145
秀丸担当 さん 16/07/22 16:45
 

もしR"(文字列)"をやるとしたら、もちろん複数行にも対応することになると思
います。
難しそうであれば見送るかもしれないですが、そういう方法を作ること自体は比
較的簡単ではあります。

遅れましたがhmPyを試させていただきました。
その方法を使うとしたら、hmPyのサンプルを拝借させていただいたところでは、
例えば以下のように書けると思います。

#_ = dllfunc(#PY, "DoString", R"MYLABEL(
import clr
import System
clr.AddReferenceByPartialName("System.Windows.Forms")
System.Windows.Forms.MessageBox.Show( message, title, System.Windows.
Forms.MessageBoxButtons.YesNoCancel )
)MYLABEL");

正規表現の場合にも以下にように書けるようになると思います。

//現状 searchdown "c:\\\\windows\\\\system32",regular;
searchdown R"(c:\\windows\\system32)",regular;

いまさらながらの仕様追加になりますが、これでよければそんなに時間もかけず
できると思います。


COMはユーザーがご自身で作られるモジュールの場合、使えるということで、C++
でDLLを作りたくなくてC#で作るほうがいいのであれば、そういう選択もあるか
とは思います。
.net Frameworkの標準で備わっているフル機能を直接使うことは秀丸マクロから
は多くは無理だと思うので、既にhmPyで実践されているような手法は良いと思い
ます。

[ ]
RE:08144 秀丸マクロへの「ヒアドキュメンNo.08146
あきくん さん 16/07/24 06:49
 
>結論として、たったの4000円(+税)しか払わずに、極めて個人的な無茶を
>サイトー企画さんにゴリ押ししている時点で、何か間違っていると思い
>ませんか?4000円の全額を開発者への賃金に充てるとしても、2-3時間
>あるかないかですよ?

あなたは他者の要望をそのような論法で封じているのですか。
常識を疑います。
少なくとも、秀丸をよくしようとしていこうとする人物であるハズがない。

[ ]
RE:08146 秀丸マクロへの「ヒアドキュメンNo.08147
でるもんたいいじま さん 16/07/24 06:55
 
でるもんた・いいじまです。

> 少なくとも、秀丸をよくしようとしていこうとする人物であるハズがない。

「良い」の定義は?
私は、今の秀丸が非常に良いものだからこそ、ごく一部の人の無茶な要望
(悪く言えばタカリ)で変な方向に改悪されてほしくないと望んでいるのです。

> あなたは他者の要望をそのような論法で封じているのですか。
> 常識を疑います。

もうこれ以上、ここで話すのは他の皆さんに迷惑ですね。
反論があれば直接メールで
"delmonta@dennougedougakkai-ndd.org"
までお願いします。

※ここの掲示板はメールアドレスをそのまま書くと伏字にされる
 仕掛けになっているので、本当にメールアドレスを書きたいときは
 "" で囲んでください。

[ ]
RE:08145 秀丸マクロへの「ヒアドキュメンNo.08148
あきくん さん 16/07/24 07:09
 
>その方法を使うとしたら、hmPyのサンプルを拝借させていただいたところでは、
>例えば以下のように書けると思います。
-----------------------------------------------------
#_ = dllfunc(#PY, "DoString", R"MYLABEL(
import clr
import System
clr.AddReferenceByPartialName("System.Windows.Forms")
System.Windows.Forms.MessageBox.Show( message, title, ystem.Windows.
Forms.MessageBoxButtons.YesNoCancel )
)MYLABEL");
-----------------------------------------------------


>正規表現の場合にも以下にように書けるようになると思います。
>
>//現状 searchdown "c:\\\\windows\\\\system32",regular;
-----------------------------------------------------
searchdown R"(c:\\windows\\system32)",regular;
-----------------------------------------------------
>
>いまさらながらの仕様追加になりますが、これでよければそんなに時間もかけず
>できると思います。

そうです!
まさに、こういうことが狙いになります。

全体的に可読性が向上するメリットがあります。

そして、単に内側に書けるというだけではありません。
MYLABELを法則性を決めておけば(PYTHONにするなど)
PYTHONのヒアドキュメントの内側にあるものは、
pythonの文法にするための強調表示定義を各人が作成することも
ちゃんと出来ます。

長い目で見れば、比較的小さな改変で、大きな効果と拡張性が
期待できると思っています。

ご検討のほど、よろしくお願いします。



[ ]
RE:08148 秀丸マクロへの「ヒアドキュメンNo.08149
でるもんたいいじま さん 16/07/24 09:28
 
でるもんた・いいじまです。

> 全体的に可読性が向上するメリットがあります。
> そして、単に内側に書けるというだけではありません。
> MYLABELを法則性を決めておけば(PYTHONにするなど)
> PYTHONのヒアドキュメントの内側にあるものは、
> pythonの文法にするための強調表示定義を各人が作成することも
> ちゃんと出来ます。

なるほど、そういう意図でしたか。
そういう使い方を前提にするならば、ヒアドキュメントが使えるように
するのは悪くないなと思います。

私自身が使う範囲では、複数の言語が一つのテキスト中に共存するのは
1.CGI…Perl、csh、etc.の中にHTML
2.WSH…XMLの体裁の中にVBScriptとJScript
3.PHP…HTMLの中にPHP言語(滅多に書かないのですが)
くらいしかないので、強調表示まで視野に入れているとは恥ずかしながら
気付きませんでした。

1.はふだんサーバ上のEmacsで書いているので標準機能に入っておらず
半ばあきらめていますし、2.と3.は今でも秀丸がデフォルトでHTML/XML
タグを解析してくれるので、新しい仕掛けまで視野に入れているとは
予想していませんでした。

こういう具体例を最初から提示していただければもっといろんな人から
反響が集まったかも、と思うとちょっと残念です。
(こちらとしても喧嘩腰になってしまい、申し訳ありませんでした。)

> 長い目で見れば、比較的小さな改変で、大きな効果と拡張性が
> 期待できると思っています。

そうですね。

ただ、まだもう少し細かいところを詰めないといけませんね。
たとえば、秀丸マクロの変数の値をヒアドキュメントの中に埋め込む
ときにはどうするのか、文字列型の場合は、秀丸マクロの変数の中に
入っている特殊文字("とか\とか)をどうエスケープするのかです。

#特に後者は、最悪の場合には code injection の温床になります。

[ ]
RE:08149 秀丸マクロへの「ヒアドキュメンNo.08150
あきくん さん 16/07/24 10:49
 
>ただ、まだもう少し細かいところを詰めないといけませんね。
>たとえば、秀丸マクロの変数の値をヒアドキュメントの中に埋め込む
>ときにはどうするのか、文字列型の場合は、秀丸マクロの変数の中に
>入っている特殊文字("とか\とか)をどうエスケープするのかです。
ヒアドキュメント内の変数展開は「実装コスト」「実行コスト」の両面で高いので、
要望にはあえて入れませんでした。
(あと秀丸の変数には#が使われてるので、
 書き手が秀丸マクロ側の変数名を変えた際に、
 プログラム側がコメントになってしまい、エラー発生の理由に気づきにくい、など)


まぁ、とりあえずは、現行の秀丸にはsprintfが存在しますので、
非常に多数の変数埋め込みなどでない限りは、
sprintfで、ある程度はカバーできるかと。

$str_formated = sprintf(
    R"AAA(あああああ%sいい実際には何行かの文字列いい%d%s)AAA",
    "abc", 33, "\n");

みたいな。

[ ]
RE:08150 秀丸マクロへの「ヒアドキュメンNo.08151
秀丸担当 さん 16/07/25 17:16
 

できるだけシンプルなほうがいいと思うので、変数の展開はなしのほうがやりや
すいです。
エスケープについては、変数の展開など特殊なことを何も考えなくていいのであ
れば、任意のラベル名が現れるまでのシンプルなものになるので、「"」も「\」
もそのまま記述できることになると思います。

ヒアドキュメントとの違いとしては、複数行で書く場合、最初の行に改行が入る
ことになるので、改行したくない場合はちょっと格好がよくないくらいだと思い
ます。

例:
$a =
R"MYLABEL(1行目
2行目
最終行)MYLABEL");

[ ]
RE:08151 秀丸マクロへの「ヒアドキュメンNo.08152
あきくん さん 16/07/26 20:32
 
それで問題ありません。

@全体で考えれば、今回の実装は厳密にはヒアドキュメントではなく、
 ロー文字列となりますので、それが正しい処理だと思われます。

A又、スクリプト等を内部に記述する、という使用観点においては、
 「coding指定が必要な言語は、最初の2行目までにあればよい」、
 というのがメジャースクリプトの慣例ですので、
 「シェバン自体不要なマクロ内記述」においては、
 1行目がまるまる空行であっても特に問題はないでしょう。

 (秀丸内の記述と、寄生プログラムレクサー及びパーサーとの辻褄が合わせやすい
ハズです)




 

[ ]
RE:08140 秀丸マクロへの「ヒアドキュメンNo.08225
でるもんたいいじま さん 16/08/16 20:24
 
でるもんた・いいじまです。

雑談です。

> どれほど慣れているC++でも、慣れていないC#の方が開発速度が
> 出るのが実情です。
> C++25年 vs C#は数ヵ月に1度しかかかないとかの比較ですら、
> C#の方が書くのが速いほどなので
> それが許される分野では、当然C#が使われるでしょう。

それはGUIとかデータ構造の操作とか、そういうライブラリの面に
おいてC#のほうがラインナップが豊富だからではありませんか?
GUIはどうしようもないとして、データ構造関係は最新のSTLを
使えばC++でもそれなりに迅速に開発できると思いますが。

現状、C#はWindows以外のプラットフォームで実用的に動かすことに
成功していませんので、クロスプラットフォームのコンソールアプリは
C++で書くのがいちばん無難ということになります。もちろん、自分で
使うだけなら慣れたスクリプト言語(PerlでもPythonでも)で書くのが
ベストですけど、そのプログラムを他所に持っていく際には、持って
いく先に当該スクリプト言語の処理系と所要のライブラリをインス
トールする、処理系のセキュリティホールに気を配る、という手間が
馬鹿になりません。FreeBSDあたりを使っているとこれは強く感じます。

> 特にdynamicであることが必須要件に入ってくるとC++はその性質上
> 太刀打ちできないわけで、テキスト記述のマクロやスクリプトの
> 世界とは多分にdynamicであることが求められる分野です。

この「dynamic」という単語の意味がつかめずにいます。
hidesoft.4:08194でも「入力補完単語のダイナミックな追加」という
言い回しができますが、何か .NET 関係の専門用語ですか?
うまい検索キーワードか解説サイトを教えていただければと思います。

[ ]
RE:08225 秀丸マクロへの「ヒアドキュメンNo.08228
天翔記jp さん 16/08/16 21:19
 
■ダイナミックとは「あとで決まる」ぐらいの広く緩い感じで使っているでしょうか。
 自分がプログラム書いている時点では、
 正体がよくわからないが後で決まるそうな、ということですね。

 ・よくわからないが、  aaa() と ()で評価できる形になる
 ・よくわからないが、  bbb[ix] と[ix]添字的な表記が可能になるそうな
 ・よくわからないが、 ccc.bbb とbbbという何かにアクセスできるそうな

 ・aaaは関数なのか、クラスのコンストラクタなのか、インスタンスの()operate評
価なのか、すらわかっていません。
 ・bbbはリストなのかディクショナリなのか、インスタンスで配列演算子をオー
バーロードしたのか、すらわかっていません。
 ・bbbはプロパティなのか、単純なフィールドなのか、実はメソッドで評価してい
ないだけなのかもわかりません。

しかし、例えばC#側にそのように記述しておくのです。
----------------------
A言語
void fund(x) {
   dynamic v = GetVariable("bbb");
   v[ix] = x;
}


----------------------
Bスクリプト 2012/3/10
bbb = {1,2,3} 今回スクリプトでは配列だった。


----------------------
Bスクリプト 2014/3/10 処理が不足した。
class B:
    __index__(self, x):
        self.y = ほげほげほげ処理(x)
    return self.y
bbb = B()  いつの間にか、bbbはクラスになっていた。配列でアクセス可能(__index__)
----------------------


 大抵の場合は、プログラム開始時にも定義はまだ決まっておらず、
 「さぁ、いよいよそこの部分が実行される」といった時に定義が決定され結び付け
られます。

 遅延バインドが一番近いでしょうが、ダイナミックという言葉はもっとゆるいです
かね。

 C++はこういったことを取り扱うことは苦手で、
 長々と超絶テンプレートを駆使するような、すごい準備が必要です。
  (それでも型を問わないわけにはいかないのでdynamicにはほど遠いですが、速度が
保てることが重要です)
 

[ ]
RE:08228 秀丸マクロへの「ヒアドキュメンNo.08230
天翔記jp さん 16/08/16 21:30
 
ダイナミックであることで、正体が何かなど気にせず、
「とにかくそうらしい」で記述していくことになります。
---------------------------------
スクリプト側
class Foo() :
  def __init__( self ) :
    print "初期化"
 
  def __call__( self ) :
    print "()付でインスタンス呼び出し"
 
  def method( self ) :
    print self.名前
    return self.政治 + self.戦闘 + self.智謀

---------------------------------
C#側
dynamic foo = scope.Foo(); // 何かしらんが、スクリプトのFooがそのままC#側でf
ooとして扱う
foo();     // __call__
foo.政治 = 97;
foo.戦闘 = 92;
foo.智謀 = 95;
foo.名前 = "武田信玄";
foo.method()

[ ]
RE:08228 秀丸マクロへの「ヒアドキュメンNo.08231
でるもんたいいじま さん 16/08/16 21:48
 
でるもんた・いいじまです。

> ■ダイナミックとは「あとで決まる」ぐらいの広く緩い感じで
> 使っているでしょうか。
>  自分がプログラム書いている時点では、
>  正体がよくわからないが後で決まるそうな、ということですね。
>
>  ・よくわからないが、  aaa() と ()で評価できる形になる
>  ・よくわからないが、  bbb[ix] と[ix]添字的な表記が可能になるそうな
>  ・よくわからないが、 ccc.bbb とbbbという何かにアクセスできるそうな
>
>  ・aaaは関数なのか、クラスのコンストラクタなのか、インスタンスの
>     ()operate評価なのか、すらわかっていません。
>  ・bbbはリストなのかディクショナリなのか、インスタンスで配列演算子を
>     オーバーロードしたのか、すらわかっていません。
>  ・bbbはプロパティなのか、単純なフィールドなのか、実はメソッドで
>     評価していないだけなのかもわかりません。
>
> しかし、例えばC#側にそのように記述しておくのです。
> ----------------------
> A言語
> void fund(x) {
>   dynamic v = GetVariable("bbb");
>   v[ix] = x;
> }
>
> ----------------------
> Bスクリプト 2012/3/10
> bbb = {1,2,3} 今回スクリプトでは配列だった。
>
> ----------------------
> Bスクリプト 2014/3/10 処理が不足した。
> class B:
>    __index__(self, x):
>        self.y = ほげほげほげ処理(x)
>     return self.y
> bbb = B()  いつの間にか、bbbはクラスになっていた。配列でアクセス可能(__ind
>ex__)
> ----------------------

なるほど、そこまで柔軟な機構があるわけですね。それでいて、
インタプリタではなくJITだから機械語と遜色ないスピードが出ると。

> C++はこういったことを取り扱うことは苦手で、
> 長々と超絶テンプレートを駆使するような、すごい準備が必要です。
>  (それでも型を問わないわけにはいかないのでdynamicにはほど遠いですが、
> 速度が保てることが重要です)

ですね。GetVariable("bbb") が何でも返せるというのが大きいですね。

[ ]