digitalmars.D - New Macro Syntax Proposal
Obviously the one I posted yesterday is not easy for IDE to highlight = sub-language set and also it lacks the power of parse different sub-language expressions.= I = think the goal of macro should be powerful enough to introduce a new sub language.= = Then the macro itself could be called mature. Consider the following macro MyPowerfulMacro =3D CODEGEN //indicate the backend gen code output= = string { KeyWordList(CASE_INSENSITIVE) // this is for IDE highlight //the design here doesn't pollute keyword we have now, KeyWordList, = Expression Backend all only take effect in macro expression { object, TOKEN.object, end, TOKEN.end, } Expression { expdeclare ::=3D EXP.expdeclare(objid, objattr[]) TOKEN.object {( TOKEN.identifier:objid TOKEN.identifier:~objattr = TOKEN.colon TOKEN.object) | (EXP.expdeclare:objexp) } TOKEN.end } Backend EXP.expdeclare(objid, objattr[]) { CODEGEN ~=3D class "~objid.strinof)~"{; foreach(k;objattr) { CODEGEN ~=3D "class "~k.stringof~"{}" } CODEGEN ~=3D "}" } }
Apr 25 2007
and my idea is eventually get the compiler's associate array out not = built-in by using a macro Language INI file instead. In the ini file, the macro is the = language feature.Obviously the one I posted yesterday is not easy for IDE to highlight ==sub-language set and also it lacks the power of parse different sub-language expression=s. =I think the goal of macro should be powerful enough to introduce a new sub languag=e. =Then the macro itself could be called mature. Consider the following macro MyPowerfulMacro =3D CODEGEN //indicate the backend gen code outp=ut =string { KeyWordList(CASE_INSENSITIVE) // this is for IDE highlight //the design here doesn't pollute keyword we have now, KeyWordList, =Expression Backend all only take effect in macro expression { object, TOKEN.object, end, TOKEN.end, } Expression { expdeclare ::=3D EXP.expdeclare(objid, objattr[]) TOKEN.object {( TOKEN.identifier:objid TOKEN.identifier:~objattr =TOKEN.colon TOKEN.object) | (EXP.expdeclare:objexp) } TOKEN.end } Backend EXP.expdeclare(objid, objattr[]) { CODEGEN ~=3D class "~objid.strinof)~"{; foreach(k;objattr) { CODEGEN ~=3D "class "~k.stringof~"{}" } CODEGEN ~=3D "}" } }
Apr 25 2007
Unfortunate then that AA's aren't yet supported at compile time because they use pointers to hash the values from the strings, and pointers aren't established until runtime. The syntax is also a bit rusty, but that's to be expected for a first proposal. My AST Reflection example was probably even weaker. ~~ Davidl Wrote:and my idea is eventually get the compiler's associate array out not built-in by using a macro Language INI file instead. In the ini file, the macro is the language feature.Obviously the one I posted yesterday is not easy for IDE to highlight sub-language set and also it lacks the power of parse different sub-language expressions. I think the goal of macro should be powerful enough to introduce a new sub language. Then the macro itself could be called mature. Consider the following macro MyPowerfulMacro = CODEGEN //indicate the backend gen code output string { KeyWordList(CASE_INSENSITIVE) // this is for IDE highlight //the design here doesn't pollute keyword we have now, KeyWordList, Expression Backend all only take effect in macro expression { object, TOKEN.object, end, TOKEN.end, } Expression { expdeclare ::= EXP.expdeclare(objid, objattr[]) TOKEN.object {( TOKEN.identifier:objid TOKEN.identifier:~objattr TOKEN.colon TOKEN.object) | (EXP.expdeclare:objexp) } TOKEN.end } Backend EXP.expdeclare(objid, objattr[]) { CODEGEN ~= class "~objid.strinof)~"{; foreach(k;objattr) { CODEGEN ~= "class "~k.stringof~"{}" } CODEGEN ~= "}" } }
Apr 25 2007
I hope macro syntax could be discussed on the NG, and I hope the macro = syntax would be designed well. There is no sound design at the moment. So I thi= nk = this is a crucial part of the language. And once macro is out, backward = compatibility and other stuff would need to be considered. We need to do some psuedo = code on the imagine macro syntax for a while then decide where to go. And I hope= = the community could help Walter a bit over this designUnfortunate then that AA's aren't yet supported at compile time becaus=e =they use pointers to hash the values from the strings, and pointers =aren't established until runtime. The syntax is also a bit rusty, but that's to be expected for a first ==proposal. My AST Reflection example was probably even weaker. ~~ Davidl Wrote:htand my idea is eventually get the compiler's associate array out not built-in by using a macro Language INI file instead. In the ini file, the macro is the language feature.Obviously the one I posted yesterday is not easy for IDE to highlig=sub-language set and also it lacks the power of parse different sub-language =expressions.I think the goal of macro should be powerful enough to introduce a new sub =utputlanguage.Then the macro itself could be called mature. Consider the following macro MyPowerfulMacro =3D CODEGEN //indicate the backend gen code o=string { KeyWordList(CASE_INSENSITIVE) // this is for IDE highlight //the design here doesn't pollute keyword we have now, KeyWordList,=Expression Backend all only take effect in macro expression { object, TOKEN.object, end, TOKEN.end, } Expression { expdeclare ::=3D EXP.expdeclare(objid, objattr[]) TOKEN.object {( TOKEN.identifier:objid TOKEN.identifier:~objattr TOKEN.colon TOKEN.object) | (EXP.expdeclare:objexp) } TOKEN.end } Backend EXP.expdeclare(objid, objattr[]) { CODEGEN ~=3D class "~objid.strinof)~"{; foreach(k;objattr) { CODEGEN ~=3D "class "~k.stringof~"{}" } CODEGEN ~=3D "}" } }
Apr 26 2007
Accepting that macros are a subset of mixins, and are just syntactic sugar, they should be as sugary as we can get 'em? Davidl Wrote:I hope macro syntax could be discussed on the NG, and I hope the macro syntax would be designed well. There is no sound design at the moment. So I think this is a crucial part of the language. And once macro is out, backward compatibility and other stuff would need to be considered. We need to do some psuedo code on the imagine macro syntax for a while then decide where to go. And I hope the community could help Walter a bit over this designUnfortunate then that AA's aren't yet supported at compile time because they use pointers to hash the values from the strings, and pointers aren't established until runtime. The syntax is also a bit rusty, but that's to be expected for a first proposal. My AST Reflection example was probably even weaker. ~~ Davidl Wrote:and my idea is eventually get the compiler's associate array out not built-in by using a macro Language INI file instead. In the ini file, the macro is the language feature.Obviously the one I posted yesterday is not easy for IDE to highlight sub-language set and also it lacks the power of parse different sub-languageexpressions.I think the goal of macro should be powerful enough to introduce a new sublanguage.Then the macro itself could be called mature. Consider the following macro MyPowerfulMacro = CODEGEN //indicate the backend gen code output string { KeyWordList(CASE_INSENSITIVE) // this is for IDE highlight //the design here doesn't pollute keyword we have now, KeyWordList, Expression Backend all only take effect in macro expression { object, TOKEN.object, end, TOKEN.end, } Expression { expdeclare ::= EXP.expdeclare(objid, objattr[]) TOKEN.object {( TOKEN.identifier:objid TOKEN.identifier:~objattr TOKEN.colon TOKEN.object) | (EXP.expdeclare:objexp) } TOKEN.end } Backend EXP.expdeclare(objid, objattr[]) { CODEGEN ~= class "~objid.strinof)~"{; foreach(k;objattr) { CODEGEN ~= "class "~k.stringof~"{}" } CODEGEN ~= "}" } }
Apr 26 2007