D - [Language design] Notational error

Manfred Nowak (23/23) Feb 05 2004 In D it is allowed to call a function like this:

The Lone Haranguer (5/5) Feb 05 2004 C learned from the problems of Fortrash.

Manfred Nowak (29/33) Feb 05 2004 Double entry bookkeeping? In the example replace the two int's with two

Walter (13/19) Feb 12 2004 languages

davepermen (14/37) Feb 06 2004 1) no problems here in typing the wrong of two.. its a different place.

Manfred Nowak (9/13) Feb 06 2004 [...]

davepermen (10/23) Feb 06 2004 i don't accidentally type the wrong one as the keys are placed in a way ...

Manfred Nowak (13/16) Feb 06 2004 [...]

davepermen (28/37) Feb 06 2004 Switzerland. The keys are near, but accessed by different fingers (damn,...

Scott Wood (6/8) Feb 06 2004 You do now. :-)

davepermen (8/16) Feb 07 2004 well, then its your own choise..

C (4/24) Feb 07 2004 crazy europeans :P.

davepermen (15/45) Feb 07 2004 nah.. it's just me and some of my friends.

davepermen (11/60) Feb 07 2004 http://davepermen.homeip.net/Pictures/Escape/24Jan2004/Pict0034.jpg

Matthias Becker (1/3) Feb 08 2004 hu? I live in germany ...

Mark T (4/16) Feb 06 2004 1) that's what code reviews are for, if the app is safety or "mission"

Manfred Nowak (6/7) Mar 09 2004 Reviews cannot remedy weaknesses of languages. Have you herd of the erro...

Manfred Nowak <svv1999 hotmail.com> writes:

In D it is allowed to call a function like this:

| fori(0, 0)

and like this

| fori(0.0)

provided, that `f' is overloaded for example like this:

| void fori(real v){someglobalrealvariable=v;...}
| void fori(int start, int end){for(i=start;i<=end;i++){...}}


However, if the programmer wants to type `f(0.0)' but instead types
`f(0,0)' the catastrophe might be unavoidable:

| Here is a very real example of catastrophic system failure due to a
| simple syntactical problem in a programming language:
|
| The USSR Mars probe, released from the Earth's atmosphere on November
| 27,1971, crash landed on the surface of Mars because its booster rockets
| failed. The failure was due to a single character mistake in the landing
| algorithm, which was written in Fortran. There was a breaking routine
| with a waiting loop of the style "FOR I=1,1000", which didn't perform
| properly, because the comma was replaced with a period, which was
| compiled as "FORI=1.1", variable "FORI" was assigned the value "1.1".
http://www.amadeus-3.com/main_files/oberon2vsCPP.php, [cited 06.02.04]

How does this agree with D's design goal:
| for practical programmers who need to get the job done quickly, reliably

So long.

Feb 05 2004

The Lone Haranguer <The_member pathlink.com> writes:

C learned from the problems of Fortrash.

But I suppose that this kind of problem can crop up in D if the recent
suggestion of auto-declared variables (or whatever the term was) is allowed.

These examples are the reason why modern (as opposed to 50s-era) languages
require double entry bookkeeping.

Feb 05 2004

Manfred Nowak <svv1999 hotmail.com> writes:

The Lone Haranguer wrote:

 But I suppose that this kind of problem can crop up in D if the recent
 suggestion of auto-declared variables (or whatever the term was) is allowed.

I am with you.

 These examples are the reason why modern (as opposed to 50s-era) languages
 require double entry bookkeeping.

Double entry bookkeeping? In the example replace the two int's with two
real's, then there is no double bookkeeping for a call with two int's, but
dmd still does not evoke an error because of the automatic type casting.

Moreover, as D is supposed to be used in programming teams, the two
functions might be public and included in a module used by another team
member. Have you ever read through a whole interface description? I
usually stopped, when I found the function I need. So I would not be even
aware of the fact, that the needed function might be overloaded.

If double bookkeeping would be followed to the end, then it would mean for
a distributed development team, that every used function from a "foreign"
module has to be introduced explicitely into the current scope and that no
tool is allowed to help with this introducing.

As you surely know this is not the case with D.

However, to avoid the accidentically call of an overloaded function
containing one number, respectively two numbers in comparable position, D
should
- turn off automatic type casting, or if this is not enough
- require double bookkeeping in the importing module.

I.e. in the example when the overload `fori(int, int)' is declared the
call `fori(0,0)' should generate something like:
| ... : ambiguous overloads for 'fori', introduce overload into scope

when the overload `fori(real, real)' is declared the call `fori(0,0)'
should generate something like:
| ... : ambiguous overloads for 'fori', no implicit type cast

in either case the call `fori(0.0)' should generate something like:
| ... : ambiguous overloads for 'fori', introduce overload into scope

So long.

Feb 05 2004

"Walter" <walter digitalmars.com> writes:

"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:bvv8at$2ben$1 digitaldaemon.com...
 These examples are the reason why modern (as opposed to 50s-era)


languages
 require double entry bookkeeping.

 Double entry bookkeeping?

I think what Lone is saying is that there should be redundancy in the syntax
of the language. Such redundancy will help pick up errors. If a language had
no redundancy in it, then any string of random characters would be a valid
program. Good language design balances the need for redundancy with
orthogonality.

 In the example replace the two int's with two
 real's, then there is no double bookkeeping for a call with two int's, but
 dmd still does not evoke an error because of the automatic type casting.

The problem is mitigated, as compared with C++, with D's much more
restrictive notion of overloading. D doesn't have C++'s large number of
levels of overloading. It has only 3: exact match, match with implict
conversions, and no match. This makes such overloading errors far less
likely in D.

Feb 12 2004