Richard Krehbiel wrote:
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:3CC6DFC0.F01424E6@deming-os.org...
> 
>>Richard Krehbiel wrote:
>>
>>
>>>Um... why is this important?
>>>
>>
>>[ ... ]
>>Similarly, it allows people to write tools to view, debug, or perhaps even
>>rearrange D code without having to parse all of the import files to find
> 
> odd
> 
>>macros. [snip]
> 
> Oh, I think I get it.  The simpler a language is to parse, the more IDE-able
> it is.

Among other things. Walter did say tools to "view, debug,
or ... rearrange" code. This includes, say, putting it
through a Perl script that looks for certain constructs
and replaces them with other constructs. I've tried to
do this in C++ and been stymied by its syntactical
insanities, and usually wound up with "well, it works
mostly, but I'll have to manually fix about 100 lines
of code... or spend another day improving my script."

-Russell B

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CC8325C.8090607@estarcion.com...
> Among other things. Walter did say tools to "view, debug,
> or ... rearrange" code. This includes, say, putting it
> through a Perl script that looks for certain constructs
> and replaces them with other constructs. I've tried to
> do this in C++ and been stymied by its syntactical
> insanities, and usually wound up with "well, it works
> mostly, but I'll have to manually fix about 100 lines
> of code... or spend another day improving my script."

The existence of the preprocessor in C++ essentially prevents syntax directed editors, pretty printers, formatters, and various simple parsers (such as wizards) from working 100% reliably. You cannot know what anything is unless you know exactly what the compiler predefined symbols are, what the arguments to the compiler are, what the include path is, what all the include files are, etc.

What those simple parsers do is make assumptions about the way most programmers use macros. That will work 98% of the time, but they cannot work 100% of the time. Struggling with that last 2% consumes endless time and frustration.

With D, a simple parser can be made that will work reliably 100% of the time. The compiler even comes with the source to the lexer and parser you can use as a guide to how to do it right.

Walter a écrit :

> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3CC8325C.8090607@estarcion.com...
> > Among other things. Walter did say tools to "view, debug,
> > or ... rearrange" code. This includes, say, putting it
> > through a Perl script that looks for certain constructs
> > and replaces them with other constructs. I've tried to
> > do this in C++ and been stymied by its syntactical
> > insanities, and usually wound up with "well, it works
> > mostly, but I'll have to manually fix about 100 lines
> > of code... or spend another day improving my script."
>
> The existence of the preprocessor in C++ essentially prevents syntax directed editors, pretty printers, formatters, and various simple parsers (such as wizards) from working 100% reliably. You cannot know what anything is unless you know exactly what the compiler predefined symbols are, what the arguments to the compiler are, what the include path is, what all the include files are, etc.
>
> What those simple parsers do is make assumptions about the way most programmers use macros. That will work 98% of the time, but they cannot work 100% of the time. Struggling with that last 2% consumes endless time and frustration.
>
> With D, a simple parser can be made that will work reliably 100% of the time. The compiler even comes with the source to the lexer and parser you can use as a guide to how to do it right.

It seems D is made for an external and optional macro preprocessor, and/or a
idde
that help the programmer in function parameter passing or struct field choice
like in vba.
If i understand well, you can't have both fonctionality at the same time.
In the prévision of a future macro preprocessor, it's good to keep some
keyword/keychar reserved like
@, #, $, "macro" or else.

roland

Maybe we should consider the roles macros play separately?

As I see, preprocessor macros are used to

 - save typing
 - compensate for language (or compiler) deficiecies
 - create new constructs or try new languages or syntaxes
 - facilitate making different versions of output
 - easy creation of debugging runtimes from same source
 - facilitate compiling in different environments


What else? Should we refactor this list so everyone first agrees on it, and then examine the issues in separate news-threads?

Save typing here includes faster writing, less errors,
and at times clearer code. Language deficiencies here
means also the need for gathering and ordering input
from files (#includes). The other categories are
self explanatory.

D seems to already take care of the last three of
them. Formidably, I might add.

Suppose you regularly end up in a situation where
writing a macro saves more time coding than writing
the macro takes, can we take that prima facie meaning
that the language has deficiencies? (Unless, of course,
you are doing something where you should use another
language to begin with!)

Georg

"Georg Wrede" <georg@iki.fi> wrote in message news:3CC91DE8.35E415AF@iki.fi...
> Suppose you regularly end up in a situation where
> writing a macro saves more time coding than writing
> the macro takes, can we take that prima facie meaning
> that the language has deficiencies?

There will always be a place for text generation. Interestingly, I find the C preprocessor quite inadequate for generating text. Look at impcnvgen.c and idgen.c in the compiler source - both are programs that write source which is then compiled into the compiler.

I think such things, however, are properly not part of the language. Use any text processing macro program to generate D source you like.