The latest printf() discussion gave me an idea: the compiler should probably throw warnings if it can determine that certain functions (or function calls) will definitely throw exceptions.  Basically, the idea is that if you call foo() with certain arguments and the compiler looks ahead enough to figure out that this will certainly throw an exception, then it should alert the programmer at compile time.  Ofc, the compiler isn't responsible for what it didn't detect, so there's no guarantee that it will give warnings in all cases.

This should not be a feature of the first version, but a wizbang of later ones, imho.

--
The Villagers are Online! http://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 wrote:

> The latest printf() discussion gave me an idea: the compiler should probably throw warnings if it can determine that certain functions (or function calls) will definitely throw exceptions.  Basically, the idea is that if you call foo() with certain arguments and the compiler looks ahead enough to figure out that this will certainly throw an exception, then it should alert the programmer at compile time.  Ofc, the compiler isn't responsible for what it didn't detect, so there's no guarantee that it will give warnings in all cases.
> 
> This should not be a feature of the first version, but a wizbang of later ones, imho.

You code it okay? :o)

Ala Linus Torvalds: "Talk is cheap, show me the code." :]

LOL

What I mean is a feature similar to "not all control paths return a value."  That seems doable, from my perspective.  Not that I'm a compiler coder, ofc...

Axel Kittenberger wrote:
> 
> Russ Lewis wrote:
> 
> > The latest printf() discussion gave me an idea: the compiler should
> > probably throw warnings if it can determine that certain functions (or
> > function calls) will definitely throw exceptions.
> >
> > This should not be a feature of the first version, but a wizbang of later ones, imho.
> 
> You code it okay? :o)
> 
> Ala Linus Torvalds: "Talk is cheap, show me the code." :]

   It's not a stupid idea, but it's way beyond ordinary compiler
technology.  I headed a team that built a proof-of-correctness system
for Pascal (see "Practical Program Verification" in POPL 83), and
it's quite possible to do far more checking at compile time than
is usually done.  Back then, verification of a 1000 line program
took about 45 minutes on a 1 MIPS machine.  Today, with 1000x as
much CPU power on the desktop, it would be useful.

   This goes with what's now called "design by contract": entry
conditions, exit conditions, and class invariants.  Think of this
as the next step beyond type checking.  The basic idea is that if
a function makes some assumption about its arguments, that assumption
must be expressed as an entry condition, which looks like an "assert".
It's the job of the caller to make sure the entry conditions are true.
It's the job of the function called to work right for all cases where
the entry conditions are true.

   So things like "p cannot be NULL", or "the input and output arrays
must be different" have to be expressed as entry conditions, not as
comments or undocumented.  This makes for better-specified APIs.

   Of course, vendors who export APIs hate the idea of design by
contract.  It makes it possible to unambiguously define what it means
for a library to have a defect.  It tells you whose fault it is.
It's common in DoD contracts to enforce interface standards
contractually, with financial penalties.  Commercial vendors hate
that.

						John Nagle

Since contract errors are defined to be errors, if the compiler can deduce a contract error at compile time, then it is encouraged to do so (a fatal compilation error, not a warning). This applies to array bounds errors, etc.

Russ Lewis wrote in message <3BC31E6F.E987F138@deming-os.org>...
>The latest printf() discussion gave me an idea: the compiler should probably throw warnings if it can determine that certain functions (or function calls) will definitely throw exceptions.  Basically, the idea is that if you call foo() with certain arguments and the compiler looks ahead enough to figure out that this will certainly throw an exception, then it should alert the programmer at compile time.  Ofc, the compiler isn't responsible for what it didn't detect, so there's no guarantee that it will give warnings in all cases.
>
>This should not be a feature of the first version, but a wizbang of later ones, imho.
>
>--
>The Villagers are Online! http://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))) ]
>
>

John Nagle wrote in message <3BC5ED4C.87398FAA@animats.com>...
>   This goes with what's now called "design by contract": entry
>conditions, exit conditions, and class invariants.  Think of this
>as the next step beyond type checking.  The basic idea is that if
>a function makes some assumption about its arguments, that assumption
>must be expressed as an entry condition, which looks like an "assert".
>It's the job of the caller to make sure the entry conditions are true.
>It's the job of the function called to work right for all cases where
>the entry conditions are true.
>
>   So things like "p cannot be NULL", or "the input and output arrays
>must be different" have to be expressed as entry conditions, not as comments or undocumented.  This makes for better-specified APIs.
>
>   Of course, vendors who export APIs hate the idea of design by
>contract.  It makes it possible to unambiguously define what it means for a library to have a defect.  It tells you whose fault it is. It's common in DoD contracts to enforce interface standards contractually, with financial penalties.  Commercial vendors hate that.


You're absolutely right. What also becomes possible is that since assert()'s
are known to the compiler rather than being a preprocessor hack, if you
code:
    assert(p != null);
then the optimizer/code generator is free to take advantage of that fact if
it can to generate better code. In effect, contracts can become more than
just error checking, they also become hints to the optimizer.

Walter wrote:

> You're absolutely right. What also becomes possible is that since assert()'s
> are known to the compiler rather than being a preprocessor hack, if you
> code:
>     assert(p != null);
> then the optimizer/code generator is free to take advantage of that fact if
> it can to generate better code. In effect, contracts can become more than
> just error checking, they also become hints to the optimizer.

It's always nice when a feature that encourages better design also leads to faster runtime speeds :)

Asserts will also be nice as a inline way of documentation:

if(clase)
  ....
else if(clause)
   ...
else if(clause)
   ...
else
{
    assert(foo == NULL);
    ....
};

--
The Villagers are Online! http://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))) ]

> You're absolutely right. What also becomes possible is that since
> assert()'s are known to the compiler rather than being a preprocessor
> hack, if you code:
>     assert(p != null);
> then the optimizer/code generator is free to take advantage of that fact
> if it can to generate better code. In effect, contracts can become more
> than just error checking, they also become hints to the optimizer.

Again to my original statement, if you can code all this then okay. But I would flinc to do the C++ way, in my eyes C++ is a very very huge and complicated language, not only for the user but also for the compiler writer. Honestly how many compilers today manage to fullfill the C++ ANSI standard 100%ly. (None?)

Ideas can be all supreme cool, but somebody has to code them. I like the extereme case that a compiler could also use be probrammed to use artificial intelligence to transform functional project specifications directly to binary code, well then all programmers will have to search new jobs :o) . Actually this kind of "compiler" is called "programmer", and he uses tools like a machine C compiler and assembler etc. to do this high-level compilation task. (.spec -> .bin).

Just don't loose the scope what you're able to do :o)
I for my project must admit that lately because of business reasons I've
latetly found rather limited time/energy to work on my hobby programming
language project.

- Axel.

--
|D> http://www.dtone.org

Axel Kittenberger wrote in message <9qa393$rg3$1@digitaldaemon.com>...
>Honestly how many compilers today manage to fullfill the C++ ANSI
>standard 100%ly. (None?)


None.

As a real-time embedded programmer, I would kill for a compiler smart enough to handle some asserts before generating code.  I need fast, tight code that has a prayer of meeting its spec.  Asserts help do exactly this (as part of an enforcement mechanism for "Program By Contract" and its many ilk), yet there is generally "no room" for them in the ROM (in the runtime code, that is).  So, things often work fine under the debugger with asserts present, yet the code fails when burned to ROM.  Too many times I've seen this happen, and the cost to the project is always significant.

Give me a language that supports "smarter" asserts, and I'll show you a language that's sure to win in the real-time embedded market.


-BobC


Walter wrote:

> Since contract errors are defined to be errors, if the compiler can deduce a contract error at compile time, then it is encouraged to do so (a fatal compilation error, not a warning). This applies to array bounds errors, etc.
>
> Russ Lewis wrote in message <3BC31E6F.E987F138@deming-os.org>...
> >The latest printf() discussion gave me an idea: the compiler should probably throw warnings if it can determine that certain functions (or function calls) will definitely throw exceptions.  Basically, the idea is that if you call foo() with certain arguments and the compiler looks ahead enough to figure out that this will certainly throw an exception, then it should alert the programmer at compile time.  Ofc, the compiler isn't responsible for what it didn't detect, so there's no guarantee that it will give warnings in all cases.
> >
> >This should not be a feature of the first version, but a wizbang of later ones, imho.
> >
> >--
> >The Villagers are Online! http://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))) ]
> >
> >