#defmacro～#endmacroディレクティブ(下のような物)を導入する事で、
新しい文法を比較的たやすく定義できる。
ただしディレクティブ名及び#defmacro～#endmacro内の構文についてはまだ未完成。(とりあえず使えそうな構文を作った。)
主旨
#defmacro.src～#defmacro.dstで記述される表現に当てはまるような塊が発見された時、
#defmacro.dst～#endmacroで記述された文章を展開して置き換える。
コード例 [ここをクリックすると内容が表示されます]
書式例1書式例2用例1用例2用例3
コード: 全て選択
#defmacro.src
( For ) &symbol ( = ) &formula ( To ) &symbol [ ( Step ) &symbol:(defval:1) ]
&body
( Next ) [ &symbol:(defval:"") ]
#defmacro.dst
%1 = %2
"Do"
"If" %1 ">=" %3 "then Exit Do"
%5:(("Exit For" to "Exit Do"))
%1 "=" %1 "+" %4
"Loop"
#endmacroコード: 全て選択
#defmacro.source
( For ) &symbol:(name:iloop) ( = ) &formula:(name:start) ( To ) &symbol:(name:end) [ ( Step ) &symbol:(name:step,defaultvalue:1) ]
&body:(name:body)
( Next ) [ &symbol:(defaultvalue:"") ]
#defmacro.destination LocalLabel:(For,Next)
%iloop = %start
%For
"If" %iloop ">=" %end "then goto" %Next
%body:(("Exit For" to "goto" %Next),("Continue" to "goto" %For))
%iloop "=" %iloop "+" %step
"goto" %For
%Next
#endmacroコード: 全て選択
#defmacro.src
( MyFunc ) + &number:(name:Number) \( &symbol:(name:src) \)
#defmacro.dst
%src "^" %Number
#endmacro
#console
Dim a As Long,b As Long
a=2
b=3
Print MyFunc5(a)'32と表示
Print MyFunc4(b)'81と表示コード: 全て選択
#defmacro.src
( GetType ) \( &symbol:(name:src) \)
#defmacro.dst
%src.type
#endmacro
#console
Dim a As Long,b As Double
Print MakeStr(GetType(a))'longと表示
Print MakeStr(GetType(b))'doubleと表示コード: 全て選択
#defmacro.src
( #console )
#defmacro.dst
"#include " $dq "basic\dos_console.sbp" $dq
#endmacro
#defmacro.src
( #prompt )
#defmacro.dst
"#include " $dq "basic\prompt.sbp" $dq
#endmacro
考えられたメリットとデメリット、及びリスク [ここをクリックすると内容が表示されます]
メリット1:新しい文法を、コンパイラの再構成抜きにして定義できる。
すなわち、コンパイラの更新がなくてもソースコードのみで新しい文法を定義できる。
メリット2:コンパイラが単純化される。
これは、For、TypeDef、Print等多くの制御文やその識別子を組み込む必要性がなくなるためによる。
この事により、配布時のファイルサイズを削減することができる可能性がある。
(圧縮された上で配布しているため、文法規則定義用のソースコードの量はあまり問題にならないと仮定した。)
メリット3:現状のソースコードを、ほとんどそのまま引き継げる可能性が高い。
コンパイラを再構成した後で、コンパイラに組み込まなくなったものを全部定義してやる必要があるんですが。
メリット4:ライブラリのソースコード量が短くなる可能性がある。
しばしば使われる表現をより短く記述するためのマクロが定義されたとすると、
マクロを各所で使用することで全体的なソースコード量は減る。
メリット5:可読性を高めやすい言語になる可能性がある。
解読する時に読むべきソースコードの定型的な部分は短いマクロに取って代わるため、
上手に用いれば見通しのいい、つまり可読性の高いソースを作成しやすくなる。
メリット6:コンパイル時に展開されるため、関数化した時に比べ実行時のオーバーヘッドが少ない。
コンパイルの速度を犠牲にしているんですが。
リスク1:マクロの多用によって、コンパイル速度が落ちる可能性がある。
マクロを全て把握し、一致する単語列を探すのに時間が掛かるかもしれない ということである。
リスク2:マクロの乱用によって、AB初心者にとって分かりにくい表現が生まれる可能性が高い。
例えば、個人用のマクロには極端な簡略表現や長いローマ字が多いかもしれない。
そのような言語体は、しばしば他人にとって読みにくくなる。
リスク3:マクロの書き間違いで、妙なバグが産まれるかもしれない。
上の書式例1で言うと、%1 "=" %1 "+" %4を%1 "=" %1 "-" %4と記述した時、言語側のバグとして扱われかねない。
又、引数の番号を誤記するかもしれない。（これは書式2のように回避可能。）
リスク4:妙な「コンパイラの解釈」が生まれる可能性がある。
例えば、上の書式例1中のFor～Next制御文の中で"Exit Do"を使用してもうまく動くかもしれない。
この時、多重に抜けるためにDoとWhileを同時使用しているようなソースコードがあるとすれば、
そのコードは書きなおす必要があるかもしれない。
又、書式例2の場合はForの入れ子が生じた場合に、外側から展開されてはならないことを念頭に置いておくべきかもしれない。
リスク5:マクロの多重定義
人によって、同じ名前で全く別のマクロを作成する可能性がある。
この事は、二人の書いたソースコードを結合する時に、大きなバグが産まれるか、
あるいは結合できないかのどちらかの結果が生まれる可能性があるということである。
これはNameSpaceの応用でも回避可能であり、
固有名詞_マクロ名 等の記法を要求することによっても回避できる。
デメリット1:現状のコンパイラを再構成する必要がある。
現状のコンパイラにこの文法規則は無いため、コンパイラを再構成するか、
新しい文法規則としてコンパイラに追加するかする必要がある。
注：リスクの2,3,5については関数でも同じ事が起こり得るので、あまり問題ではないかもしれない。
すなわち、コンパイラの更新がなくてもソースコードのみで新しい文法を定義できる。
メリット2:コンパイラが単純化される。
これは、For、TypeDef、Print等多くの制御文やその識別子を組み込む必要性がなくなるためによる。
この事により、配布時のファイルサイズを削減することができる可能性がある。
(圧縮された上で配布しているため、文法規則定義用のソースコードの量はあまり問題にならないと仮定した。)
メリット3:現状のソースコードを、ほとんどそのまま引き継げる可能性が高い。
コンパイラを再構成した後で、コンパイラに組み込まなくなったものを全部定義してやる必要があるんですが。
メリット4:ライブラリのソースコード量が短くなる可能性がある。
しばしば使われる表現をより短く記述するためのマクロが定義されたとすると、
マクロを各所で使用することで全体的なソースコード量は減る。
メリット5:可読性を高めやすい言語になる可能性がある。
解読する時に読むべきソースコードの定型的な部分は短いマクロに取って代わるため、
上手に用いれば見通しのいい、つまり可読性の高いソースを作成しやすくなる。
メリット6:コンパイル時に展開されるため、関数化した時に比べ実行時のオーバーヘッドが少ない。
コンパイルの速度を犠牲にしているんですが。
リスク1:マクロの多用によって、コンパイル速度が落ちる可能性がある。
マクロを全て把握し、一致する単語列を探すのに時間が掛かるかもしれない ということである。
リスク2:マクロの乱用によって、AB初心者にとって分かりにくい表現が生まれる可能性が高い。
例えば、個人用のマクロには極端な簡略表現や長いローマ字が多いかもしれない。
そのような言語体は、しばしば他人にとって読みにくくなる。
リスク3:マクロの書き間違いで、妙なバグが産まれるかもしれない。
上の書式例1で言うと、%1 "=" %1 "+" %4を%1 "=" %1 "-" %4と記述した時、言語側のバグとして扱われかねない。
又、引数の番号を誤記するかもしれない。（これは書式2のように回避可能。）
リスク4:妙な「コンパイラの解釈」が生まれる可能性がある。
例えば、上の書式例1中のFor～Next制御文の中で"Exit Do"を使用してもうまく動くかもしれない。
この時、多重に抜けるためにDoとWhileを同時使用しているようなソースコードがあるとすれば、
そのコードは書きなおす必要があるかもしれない。
又、書式例2の場合はForの入れ子が生じた場合に、外側から展開されてはならないことを念頭に置いておくべきかもしれない。
リスク5:マクロの多重定義
人によって、同じ名前で全く別のマクロを作成する可能性がある。
この事は、二人の書いたソースコードを結合する時に、大きなバグが産まれるか、
あるいは結合できないかのどちらかの結果が生まれる可能性があるということである。
これはNameSpaceの応用でも回避可能であり、
固有名詞_マクロ名 等の記法を要求することによっても回避できる。
デメリット1:現状のコンパイラを再構成する必要がある。
現状のコンパイラにこの文法規則は無いため、コンパイラを再構成するか、
新しい文法規則としてコンパイラに追加するかする必要がある。
注：リスクの2,3,5については関数でも同じ事が起こり得るので、あまり問題ではないかもしれない。