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 ~= "}"
}

}

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 ~= "}"
> }
>
> }

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 ~= "}"
> > }
> >
> > }
> 

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 design

>
> 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 ~= "}"
>> > }
>> >
>> > }
>>
>

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 design
> 
> >
> > 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 ~= "}"
> >> > }
> >> >
> >> > }
> >>
> >
>