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