On 1/9/2013 12:03 PM, Philippe Sigaud wrote:
> That's not what I'm talking about, sorry for not being clear. I don't
> care for the origin of the data, obviously. I meant a D module, not a
> file specifically. My question was if the data is a D module (code +
> comments), should it just expand macros? Or should it generate a
> documentation?

The current ddoc macro system does recognize D code. This should be removed from a generic macro system.

On 1/9/13 12:13 PM, Walter Bright wrote:
> On 1/9/2013 12:03 PM, Philippe Sigaud wrote:
>> That's not what I'm talking about, sorry for not being clear. I don't
>> care for the origin of the data, obviously. I meant a D module, not a
>> file specifically. My question was if the data is a D module (code +
>> comments), should it just expand macros? Or should it generate a
>> documentation?
>
> The current ddoc macro system does recognize D code. This should be
> removed from a generic macro system.

Yah, the "----" etc. I was thinking it would be nice to have some of that functionality, too.

Andrei

On Wed, Jan 09, 2013 at 12:12:02PM -0800, Walter Bright wrote:
> On 1/9/2013 11:31 AM, H. S. Teoh wrote:
> >I think it would be nice to have a separate function for parsing macro definitions.
> 
> No. Where the macro definitions come from is a completely separate problem, and the two should not be conflated.

I disagree. The macro definitions does not need to (and probably should not) be in the same place as the input file, but they do have to be defined somewhere.  Yes you can just construct your own string[string] and hand that over to the macro expander, but it would be nice to also have a uniform syntax for defining macros in an external source, which can be parsed by a standard library function.

It would be kinda disappointing to have a marvellous system for macro expansion, yet no standard way to define said macros, but everyone cooks their own syntax and parser for it.


T

-- 
Why have vacation when you can work?? -- EC

On Wed, Jan 09, 2013 at 12:16:56PM -0800, Andrei Alexandrescu wrote:
> On 1/9/13 12:13 PM, Walter Bright wrote:
> >On 1/9/2013 12:03 PM, Philippe Sigaud wrote:
> >>That's not what I'm talking about, sorry for not being clear. I don't care for the origin of the data, obviously. I meant a D module, not a file specifically. My question was if the data is a D module (code + comments), should it just expand macros? Or should it generate a documentation?
> >
> >The current ddoc macro system does recognize D code. This should be removed from a generic macro system.
> 
> Yah, the "----" etc. I was thinking it would be nice to have some of that functionality, too.
[...]

I think the D-specific parts (or even documentation-specific parts, like the syntax for sections) should be done separately.  Maybe something like this:

	// In the generic macro module
	R expandMacros(I,R)(I inputRange, string[string] macroDefs) { ...}

	// In a doc-specific module
	R extractDocComments(I,R)(I inputRange) { ... }
	R processDocSections(I,R)(I inputRange) { ... }

	// In main app
	R generateDdoc(I,R)(I inputRange, string[string] macroDefs) {
		// UFCS FTW!
		return inputRange.extractDocComments()
				.expandMacros(macroDefs)
				.processDocSections();
	}


T

-- 
Your inconsistency is the only consistent thing about you! -- KD

On 1/9/2013 12:34 PM, H. S. Teoh wrote:
> It would be kinda disappointing to have a marvellous system for macro
> expansion, yet no standard way to define said macros, but everyone cooks
> their own syntax and parser for it.

I've developed multiple macro systems. There is no standard way of getting the macro defs, nor should there be.