Walter wrote:
> One major design goal of D was to eliminate the text preprocessor.
> This involved figuring out what people were using the preprocessor
> for, and then finding a way to do that symbolically. I believe that D
> covers this well, having symbolic capability for generics, asserts,
> imports, constants, debug compiles, conditional compilation, etc.

I know. What i am going to write, is to be a tool to replace more
complex processing, like lex, yacc, adding *new* constructs, and so on,
without making the language into garbage. It will not replace C
preprocessor in any way. Well, except if some maliscious operator writes
that kind of script for it. ;) I bet the use of such a complex,
sophisticated instrument will remain very limited and will not take such
scale as C preprocessor which is crude and easy to (mis)use. I don't need a tool for the features of the C preprocessor i was using it for in C, since D is (or is to be) powerful enough.

>> Examples of useful uses for such a preprocesor in D: - implement
>> some syntactic features which don't make it into the language,
>> either because Walter doesn'tlike them, or because he lacks of
>> time. Maybe they just shouldn't pollute the language itself. Like:
>> patternmatching, base#value digital constants and so on... -
>> implement other languages. Like to compile Delphi or Ada programs
>> :)
> What D doesn't support are things like:
> 
> #define BEGIN { #define END }
> 
> which are used to make C look like another language
implement, not mimic :)

> 
> Using D doesn't mean you can't preprocess the source text - any
> general purpose macro text processor can be used to preprocess text
> before feeding it to the D compiler. The C preprocessor is so

I know.

> wretchedly primitive anyway, the only reason it is in wide use is
> because people are so familiar with it.

I'm afraid I was somehow short of a time and didn't explain it to the
extent. It is not going to be a macro processor, not at all. It is gonna
become a plugin- (or script-) steered *partial parse tree generator*,
and originally the tree would be output back into a D file to be
compiled. If it finds use, you may later integrate it into the compiler,
but i doubt it would make sense, since it is not for widespread use,
since D doesn't seem to have real gaps or misfeatures. And the features of functional programming which I would like to implement using such tool, can not be implemented with a text-based tool. I don't even want the tool to become too widespread, because:
 - foreign utilities would have to integrate it to make any kind of parsing of the code, using its features;
 - all other facts you pointed put already here or in the manual, which i *have* read.

thanks for your efforts,
and good luck.
-i

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:avt5fn$138h$1@digitaldaemon.com...
> Hmmm more builtins and keywords. Somehow I think this can get out of control. Which of these are inherent to source code (IMHO line is, the
other
> I don't think so).

Most of the use of those is for the assert macro. In D, assert is built in to the language. For build versioning, use things like:

BUILDVERSION := $(shell date +%Y%m%d%H)

-DBUILDVERSION=$(BUILDVERSION)

or similar things I've seen, such as a program that all it did was write out:

    char version[] = "date string";

and then that file was part of the make build.

I'm sorry, i'm afraid i've started a redundant off-topic discussion. But what i meant, is not at all a "preprocessor" in the sense understood by most of the C people! I should have chosen other topic. I personally always favor syntax-based solutions over text-based, don't misundersand me.

Walter wrote:
> "Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message
> news:avt5fn$138h$1@digitaldaemon.com...
> 
>>Hmmm more builtins and keywords. Somehow I think this can get out of
>>control. Which of these are inherent to source code (IMHO line is, the
> 
> other
> 
>>I don't think so).
> 
> 
> Most of the use of those is for the assert macro. In D, assert is built in
> to the language. For build versioning, use things like:
> 
> BUILDVERSION := $(shell date +%Y%m%d%H)
> 
> -DBUILDVERSION=$(BUILDVERSION)
> 
> or similar things I've seen, such as a program that all it did was write
> out:
> 
>     char version[] = "date string";
> 
> and then that file was part of the make build.
> 
> 

Ilya Minkov wrote:
> I'm afraid I was somehow short of a time and didn't explain it to the
> extent. It is not going to be a macro processor, not at all. It is gonna
> become a plugin- (or script-) steered *partial parse tree generator*,
> and originally the tree would be output back into a D file to be
> compiled. If it finds use, you may later integrate it into the compiler,
> but i doubt it would make sense, since it is not for widespread use,
> since D doesn't seem to have real gaps or misfeatures. And the features of functional programming which I would like to implement using such tool, can not be implemented with a text-based tool. I don't even want the tool to become too widespread, because:
>  - foreign utilities would have to integrate it to make any kind of parsing of the code, using its features;
>  - all other facts you pointed put already here or in the manual, which i *have* read.

still, rather than tihs I would like to have some sort of robust sytax expansion mechanism built into the compiler, rather than something that happens in a separate step.

Evan

Evan McClanahan wrote:
> still, rather than tihs I would like to have some sort of robust sytax expansion mechanism built into the compiler, rather than something that happens in a separate step.

I somehow think that it doesn't matter for design whether it's a separate programme or a part of a compiler. I shall try to make sure later integration is not too painful. And besides, Walter is probably not interested in such a thing.

Please recall that C++ originally was a separate step which generated C code? It is obviuosly better to integrate such complex things into a compiler, but only after it is shown that they make sense and advantage.

Besides, even C Preprocessor is nowadays often an integral part of the compiler. Even such a simple-minded compiler as LCC integrates it into the lexer. The only exception i'm aware of is GCC, but that's quite another story.

I shall give my best to design it robust, but it might take some trial and error, so that it's likely to change completely. Until it's proven to work well and be safe, under no circumstances should it be stuffed into the compiler.


-i.

PS. I guess someone has figured out already how to write backends for D? Where can this information be found? I might be interested to write a portable fast VM backend based on GNU Lightning or VCode.

"Ilya Minkov" <midiclub@tiscali.de> wrote in message news:b0127n$114f$1@digitaldaemon.com...
> Besides, even C Preprocessor is nowadays often an integral part of the compiler. Even such a simple-minded compiler as LCC integrates it into the lexer. The only exception i'm aware of is GCC, but that's quite another story.
>
> I shall give my best to design it robust, but it might take some trial and error, so that it's likely to change completely. Until it's proven to work well and be safe, under no circumstances should it be stuffed into the compiler.

I agree. I think you are taking the right approach. And there is no reason at all why D would not be suitable as a "back end" for a higher level language.

Walter wrote:
> "Ilya Minkov" <midiclub@tiscali.de> wrote in message
> news:b0127n$114f$1@digitaldaemon.com...
> 
>>Besides, even C Preprocessor is nowadays often an integral part of the
>>compiler. Even such a simple-minded compiler as LCC integrates it into
>>the lexer. The only exception i'm aware of is GCC, but that's quite
>>another story.
>>
>>I shall give my best to design it robust, but it might take some trial
>>and error, so that it's likely to change completely. Until it's proven
>>to work well and be safe, under no circumstances should it be stuffed
>>into the compiler.
> 
> 
> I agree. I think you are taking the right approach. And there is no reason
> at all why D would not be suitable as a "back end" for a higher level
> language.
> 

Talking about that. It requeres language processing tools, such as generating ASTs and such work. I have found an interpreted C-like OO language "Dino" with perfect capabilities of that kind. I thought D deserved similar things implemented as a library.

The severe thing i dislike about it - it has taken your file extention - "*.d".

It appears that it is a "concept test" for a compiler construction toolset.

http://cocom.sourceforge.net/

Pre-init constants come to mind. But *may be* i could write some types/ op-overloading/ wizardry to write recursive-descend parsers directly in D in a rather BNF-like form...
Hm. If i really get that to work, i'm raising my level to a mega-wizard... err... of level (-4). :>
That is, a very powerful wizard. It would be not unusual trickery in C, but in D... Hm.

BUT, if i get it to make a grammar description, than it need not be limited by recursive-descend, it can be anything at all!


-i.

Evan McClanahan wrote:
> I would support something like lisp macros (which aren't
> preprocessed) for sytax expansion, if it could be safely worked into
> D, but I, for one, think that a preprocessor is a needless complication.  If you could come up with a way to do this type of
> stuff in the course of standard compilation, I think that it would be
> better.

I finally came to *actually* read about the way lisp works and lisp macros and such. It is 100% genious, but i don't think it's possible to design it into the language at such a late point... I'll think and read more about it, it's an interesting concept...