While pointer arithmetic is a necessary part of a general purpose language, for most programs, we can live without it.  How about a language subset that disallows pointer arithmetic?  This simplifies the garbage collector (I'd assume), and would probably allow some more compiler optimizarions.

I suspect that this is an add-on for later versions of the compiler, though...

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BF41A9C.26E1C85A@deming-os.org...

> While pointer arithmetic is a necessary part of a general purpose language, for most programs, we can live without it.  How about a language subset that disallows pointer arithmetic?  This simplifies the garbage collector (I'd assume), and would probably allow some more compiler optimizarions.

Could be useful. With dynamic arrays used as strings is D, actual need for pointer arithmetic is really low.

BTW, concerning all these options. I hate it when different language features are turned on and off from command-line. What I like in Pascal is that you can set up everything as you want from _inside_ of your program, and then compiling it is as simple as calling the compiler with a single file name as argument. Something like "option" statement in D for this purpose would be fine. Sorta #pragma, but strictly defined in the specs:

    option PointerArith = true;    // no pointer arithmetic
    option RequireBlocks = false;  // don't require {}'s in loops
    ...

Good idea.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3BF41A9C.26E1C85A@deming-os.org...
> While pointer arithmetic is a necessary part of a general purpose language, for most programs, we can live without it.  How about a language subset that disallows pointer arithmetic?  This simplifies the garbage collector (I'd assume), and would probably allow some more compiler optimizarions.
>
> I suspect that this is an add-on for later versions of the compiler, though...


It's a good idea and I've thought a lot about it. For the moment, I decided that it was best not to split D into different variants.

<snip>
> BTW, concerning all these options. I hate it when different language features are turned on and off from command-line. What I like in Pascal is that you can set up everything as you want from _inside_ of your program, and then compiling it is as simple as calling the compiler with a single file name as argument. Something like "option" statement in D for this purpose would be fine. Sorta #pragma, but strictly defined in the specs:
>
>     option PointerArith = true;    // no pointer arithmetic
>     option RequireBlocks = false;  // don't require {}'s in loops
>     ...

THIS ought to be there. How about it, Walter?
Including the '#pragma option Model = n'.

This will certainly simplify projects where different programs in a project
have to be compiled with different options.
(Would love it even for DMC compiler now!)

It is a good idea. -Walter

"Rajiv Bhagwat" <dataflow@vsnl.com> wrote in message news:9t51ml$15ln$1@digitaldaemon.com...
> <snip>
> > BTW, concerning all these options. I hate it when different language features are turned on and off from command-line. What I like in Pascal is that you can set up everything as you want from _inside_ of your program, and then compiling it is as simple as calling the compiler with a single file name as argument. Something like "option" statement in D for this purpose would be fine. Sorta #pragma, but strictly defined in the specs:
> >
> >     option PointerArith = true;    // no pointer arithmetic
> >     option RequireBlocks = false;  // don't require {}'s in loops
> >     ...
>
> THIS ought to be there. How about it, Walter?
> Including the '#pragma option Model = n'.
>
> This will certainly simplify projects where different programs in a
project
> have to be compiled with different options.
> (Would love it even for DMC compiler now!)
>
>
>

Seems that the way Walter has set up the semantic processing separate from parsing, you could achieve the same affect with a constant global bool and an if statement or a version statement.  For each project make some kind of big "version.d" or "globals.d" file.  Seems version can take any constant expression as argument.

This brings up several things.  One, while searching for the version statement in the D Programming Language on the website, I had a real hard time tracking it down since it's considered as a *statement* and listed as such under that category.  However according to the D Syntax Grammar on the same website, it doesn't appear possible to have a statement at module scope.  Would have to use import statements to bring this kind of non-IDE/non-command-line option into scope to use version on it.  If version can be used at module scope and other statements cannot, then version is not a statement and a new syntax class must be defined for it and things like it.  It'd be nice if these kind of global statements were given a heading on the D Programming Language page so they can be quickly located.

It also appears that module-level functions are not possible... do all functions really have to be class members ala Java?

In addition, the declaration entry in the D Syntax Grammar seems to be broken... surely some way must be specified to declare variables or class/struct members.  Has anyone given this syntax a thorough going-over?

I'm pretty sure it's not possible to have anything at all at global scope. Is this good?  Should import be required, or could an IDE group files together that have implicit access to each other?

Is it possible to use version to give two separate declarations for a
function parameter list without duplicating the body of the function?
Since the version statement can only contain statements (does this also
count local variable declarations?) can the version statement contain, say,
just the function signature and not the body?  What about just one parameter
of a function declaration?  What exactly can a version statement do?  What
can it hold in its body?  Where exactly is it legal?  To replace the
preprocessor fully, it'd be necessary to allow it just about anywhere, but
that'll be a nightmare to the language syntax.

What is the proper way for compiler vendors to provide extensions to the D language, such as perhaps providing a __forceinline keyword?

And one final question... what is the entry point to the program?  main()?
What are the details?

Sean

P.S. Not sure why I'm having so many questions all of a sudden...

"Rajiv Bhagwat" <dataflow@vsnl.com> wrote in message news:9t51ml$15ln$1@digitaldaemon.com...
> <snip>
> > BTW, concerning all these options. I hate it when different language features are turned on and off from command-line. What I like in Pascal is that you can set up everything as you want from _inside_ of your program, and then compiling it is as simple as calling the compiler with a single file name as argument. Something like "option" statement in D for this purpose would be fine. Sorta #pragma, but strictly defined in the specs:
> >
> >     option PointerArith = true;    // no pointer arithmetic
> >     option RequireBlocks = false;  // don't require {}'s in loops
> >     ...
>
> THIS ought to be there. How about it, Walter?
> Including the '#pragma option Model = n'.
>
> This will certainly simplify projects where different programs in a
project
> have to be compiled with different options.
> (Would love it even for DMC compiler now!)
>
>
>

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9tael0$1dbn$1@digitaldaemon.com...

> It also appears that module-level functions are not possible... do all functions really have to be class members ala Java?

No!

Just look at the sample D program in the "Overview":

    import stdio;

    bit[8191] flags;

    int main()
    {
        ...
    }


> I'm pretty sure it's not possible to have anything at all at global scope. Is this good?  Should import be required, or could an IDE group files together that have implicit access to each other?
AFAIK, whenever you want to use anything from other module, you must explicitly import it - always. And yes, I think it's good.

> What is the proper way for compiler vendors to provide extensions to the D language, such as perhaps providing a __forceinline keyword?

"Identifiers starting with '__' are reserved"

> And one final question... what is the entry point to the program?  main()?
> What are the details?

    int main(char[][] args);
        - or -
    int main();

At least these two forms are in the specs.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:9tbbmo$1vbk$1@digitaldaemon.com...
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:9tael0$1dbn$1@digitaldaemon.com...
>
> > It also appears that module-level functions are not possible... do all functions really have to be class members ala Java?
>
> No!
>
> Just look at the sample D program in the "Overview":
>
>     import stdio;
>
>     bit[8191] flags;
>
>     int main()
>     {
>         ...
>     }

I'm looking at the @$% syntax BNF for D... not some sample buried down somewhere.

> > And one final question... what is the entry point to the program?
main()?
> > What are the details?
>
>     int main(char[][] args);
>         - or -
>     int main();
>
> At least these two forms are in the specs.

Where?

Sean

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:9tdb5p$6on$1@digitaldaemon.com...

> I'm looking at the @$% syntax BNF for D... not some sample buried down somewhere.

There are quite many mistakes there. It just seems
to be an "approximate" version.

> >     int main(char[][] args);
> >         - or -
> >     int main();
> >
> > At least these two forms are in the specs.
>
> Where?

The first form (with args) is at the very end of "Arrays" section, in a "Word count associative array example" progie. The second, without arguments, is in the overview.

However, they're not mentioned anywhere as correct or only forms. So I believe the question is still open. Only Walter could make this clearer, unless, of course, he haven't yet come to any decision himself =)