• Russ Lewis (12/12) Nov 15 2001 While pointer arithmetic is a necessary part of a general purpose
• Pavel Minayev (15/20) Nov 15 2001 Could be useful. With dynamic arrays used as strings is D,
• Russ Lewis (6/6) Nov 15 2001 Good idea.
• Rajiv Bhagwat (6/17) Nov 16 2001 THIS ought to be there. How about it, Walter?
• Walter (4/22) Nov 17 2001 It is a good idea. -Walter
• Sean L. Palmer (42/60) Nov 19 2001 Seems that the way Walter has set up the semantic processing separate fr...
• Pavel Minayev (17/26) Nov 19 2001 No!
• Sean L. Palmer (7/25) Nov 20 2001 I'm looking at the @$% syntax BNF for D... not some sample buried down
• Pavel Minayev (11/19) Nov 20 2001 There are quite many mistakes there. It just seems
• Walter (26/52) Nov 28 2001 of
• Walter (4/11) Nov 15 2001 It's a good idea and I've thought a lot about it. For the moment, I deci...

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

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))) ]

"Pavel Minayev" <evilone omen.ru> writes:

"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
    ...

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

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))) ]

"Rajiv Bhagwat" <dataflow vsnl.com> writes:

<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!)

"Walter" <walter digitalmars.com> writes:

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!)

"Sean L. Palmer" <spalmer iname.com> writes:

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!)

"Pavel Minayev" <evilone omen.ru> writes:

"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.

"Sean L. Palmer" <spalmer iname.com> writes:

"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

"Pavel Minayev" <evilone omen.ru> writes:

"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 =)

"Walter" <walter digitalmars.com> writes:

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:9tael0$1dbn$1 digitaldaemon.com...
 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.

The version statement needs a little more work in the specification
department.


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

Module level functions are possible. No need to create dummy classes for
them 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?

You're right, it needs 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?

You can have stuff at module scope, but not at a scope more global than
that. Imports are required.


 Is it possible to use version to give two separate declarations for a
 function parameter list without duplicating the body of the function?

No. You can probably work around this by writing a couple wrapper functions
and version them.

 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.

The version statement can enclose declarations or statements. It can't
enclose parts of statements or declarations that would be ill-formed by
themselves.


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

__ keywords are for vendor specific extensions.

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

import stdio;

int main(char[][] args)
{
    printf("hello world! My arguments are:\n);
    for (uint i = 0; i < args.length; i++)
        printf("arg[%d] = '%.*s'\n", i, args[i]);
    return 0;
}

"Walter" <walter digitalmars.com> writes:

"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.