www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Look like C --> act like C ... really?

reply Manfred Nowak <svv1999 hotmail.com> writes:
Look like C --> act like C ... really?

<code>
int i= 5;
float m=5.0;
void main()
{
  void f(){
    void i( float j){ m= j;}
    void g(){
      i= 1;
    }
    g();
  }
  f();
  printf( "%d %f\n", i, m);
  
}
</code>
 
-manfred
Feb 25 2005
parent reply "Walter" <newshound digitalmars.com> writes:
What do you mean? That will never work with C - no nested functions!

"Manfred Nowak" <svv1999 hotmail.com> wrote in message
news:cvogrn$1uq3$1 digitaldaemon.com...
 Look like C --> act like C ... really?

 <code>
 int i= 5;
 float m=5.0;
 void main()
 {
   void f(){
     void i( float j){ m= j;}
     void g(){
       i= 1;
     }
     g();
   }
   f();
   printf( "%d %f\n", i, m);

 }
 </code>

 -manfred
Feb 26 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Walter" <newshound digitalmars.com> wrote:

 What do you mean? That will never work with C - no nested
 functions! 
I mean that the code nearly looks like C-Code except that the functions are nested. But that if nested function would be allowd in C the semantic still would be different than the semantic of this D- Code. However, if you want to say that every little deviance from the C- look-alike destroys the act-alike-promise the example stated above is of no problem. But then <code> int m; void i( int j){ m= j;} void main(){ i= 1; } </code> has no deviance from C --- but is compiled under D, and therefore acts, and stays uncompiled under C, and therefore does not act. -manfred
Feb 26 2005
next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:cvqh3d$13bb$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> wrote:

 What do you mean? That will never work with C - no nested
 functions!
I mean that the code nearly looks like C-Code except that the functions are nested. But that if nested function would be allowd in C the semantic still would be different than the semantic of this D- Code. However, if you want to say that every little deviance from the C- look-alike destroys the act-alike-promise the example stated above is of no problem. But then <code> int m; void i( int j){ m= j;} void main(){ i= 1; } </code> has no deviance from C --- but is compiled under D, and therefore acts, and stays uncompiled under C, and therefore does not act. -manfred
Using property setter syntax (i=1) without a property is probably a compiler bug. A property should only be struct and class member functions.
Feb 26 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Ben Hinkle" <ben.hinkle gmail.com> wrote:

[...]
 A property should only be struct and class member functions. 
Then transpose the example into one using a `struct' and the same statement holds. I know, that this might be interpreted as nitpicking, but I am sure, that for every known pitfall in a language for which a warner has raised a finger early, there exist a person in charge who secretly called the warner a nitpicker. So, I raise the question: when does Code look like C-Code and therefore the act-alike-promise holds? Is it true, that a single C-cast `(int)' converted to the D-cast `cast(int)' in a program consisting of 1000 lines renders the program to no more looking like C? If the program just mentioned is stated to look like C, is a single `with' that opens the scope of a `struct' or `class' and thereby introduces properties with their dangerous effects, although I like them, into the code again to be stated as breaking the look-alike- act-alike-promise? -manfred
Feb 26 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I am having a lot of trouble understanding what you mean, but I think 
you're simply trying to say that D is not C.  This is true.

But, sometimes, things are better the other way.  You seem to be arguing 
that (int) is not more C-like than C, because it *is* C.  Maybe so, but 
it's more C-like than VB.


reverence to every little tidbit of C syntax... D isn't C, and I don't 
want it to be, personally, either.

But it still looks like C, as compared to PHP, Perl, Python, Bash, 
BASIC, Assembly, etc.

-[Unknown]


 Is it true, that a single C-cast `(int)' converted to the D-cast 
 `cast(int)' in a program consisting of 1000 lines renders the program 
 to no more looking like C?
 
 If the program just mentioned is stated to look like C, is a single 
 `with' that opens the scope of a `struct' or `class' and thereby 
 introduces properties with their dangerous effects, although I like 
 them, into the code again to be stated as breaking the look-alike-
 act-alike-promise?
 
 -manfred
Feb 26 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote:

[...]
 you're simply trying to say that D is not C.  This is
 true. 
[...] Right. I am stating that D-code that looks like C-code must not act like C-Code and therefore the promise look-alike--->act-alike is wrong in general. The other way is right. D has to say: although I look like C and often act like C I am not C. So be careful --- or you risk bugs because you think I am C. <example> int i; // code omitted. And omitted code does not contain another // declaration of a variable `i' array[ i]= 0; </example> Here `int i; ... array[i]= 0;' looks like C-code where the cell `i' of `array' is set to zero. But it is D-code ... and `i' might in fact be a property that replaced the value of `int i' ... and `array' might in fact be declared as an associative array ... and ėn fact `array' might not be an array at all, because its type is a class which has an `opIndex'-overload. -manfred
Feb 26 2005
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Of course... so the moral of the story is to know what language you're 
speaking, right?

Yo no hablo espaņol.  Ich spreche Englisch.

Dankjewel,
-[Unknown]
Feb 26 2005
prev sibling parent Sebastian Beschke <s.beschke gmx.de> writes:
Ben Hinkle schrieb:
 Using property setter syntax (i=1) without a property is probably a compiler 
 bug. A property should only be struct and class member functions. 
I don't know... I think it would be interesting for functions inside modules to have this syntax, too. :) -Sebastian
Mar 07 2005
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Manfred Nowak wrote:
 has no deviance from C --- but is compiled under D, and therefore 
 acts, and stays uncompiled under C, and therefore does not act.
This argument is "good" enough to prevent introducing *any* feature into D. -eye
Feb 27 2005