www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - declare-and-init operator := (decls in expressions)

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
I don't know if this has been proposed before but I was thinking how nice it 
is to work in MATLAB (where you don't have to declare a variable's type) and 
the following operator came to mind
  var := init;
is the same as
  typeof(init) var = init;

That means, for example, if ReallyLongClass is a class that

  ReallyLongClass f = new ReallyLongClass;

can be replaced with

  f := new ReallyLongClass;

It even will come in handy with lots of little variables like
  for (i:=0; i<10; i++) {...}

If := appears inside an expression (say, expr) in a statement (say, stmt) 
like
  if ((p := strchar(q,'a')) != null) {
     ... use p ...
  }
then the rewritten code is
  { typeof(init) var; stmt' }
where stmt' is stmt with := replaced with = in expr.

Another example using if-else statement (from 
digitalmars.D/27542)
 if ((line := ReadLine()) != null) {
      printf("We got a line, Chief!");
      line = EscapeLine(line);
      DeployLine(line);
 } else {
      printf("We are out of lines, Chief!");
      line = "Emergency Line";
      DeployLine(line);
 }
is equivalent to
 {
   char[] line;
   if ((line = ReadLine()) != null) {
      printf("We got a line, Chief!");
      line = EscapeLine(line);
      DeployLine(line);
   } else {
      printf("We are out of lines, Chief!");
      line = "Emergency Line";
      DeployLine(line);
   }
 }

An example that wouldn't work (from 
http://www.digitalmars.com/d/archives/digitalmars/D/20481.html)

  do {
    x := getchar();
  } while (x != 'x');

since x:=getchar(); is the deepest statement enclosing the := so the 
declaration wouldn't be visible to the while condition.

This proposal avoids the parsing ambiguity that Stewart found with
  if ((a*b = c) != 0) {...}
since the a*b would continue to be parsed as it is today - as 
multiplication.


A "real-life" example is a modified std.string.find from phobos. Notice that 
it only needs declarations where some unsigned size_t array lengths are 
assigned to ints.
int find(char[] s, char[] sub)
{
  int sublength = sub.length;

  if (sublength == 0)
    return 0;

  c := sub[0];
  if (sublength == 1)
  {
      p := memchr(s, c, s.length);
      if (p)
         return p - &s[0];
  }
  else
  {
      int imax = s.length - sublength + 1;

      // Remainder of sub[]
      q := &sub[1];
      sublength--;

      for (i := 0; i < imax; i++)
      {
        p := memchr(&s[i], c, imax - i);
        if (!p)
          break;
        i = p - &s[0];
        if (memcmp(p + 1, q, sublength) == 0)
          return i;
      }
  }
  return -1;
}
Aug 28 2005
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Seems like a handy syntactic sugar, but I'm of the opinion that too much 
sugar is a kind of bloat; yes, it's convenient, but it adds unnecessary 
complication to the syntax.
Plus, I hated that := operator from pacal.

However, maybe we could use something more consistent with the current 
design, like:

#typeof var = init;

Where typeof is not followed by an opening parenthesis, so a default 
(init) is assumed.
This is similar to the behaviour of 'extern' for example, where if it's 
not followed by a parenthesis, a default (D) is assumed. Same for align.

However,
#typeof var = init;
maybe misleading, as it /can/ read: "var is a variable whose tyoe is the 
same type as var", so maybe another keyword should be introduced:
#auto_type var = init;

or just
#type var = init;

Ben Hinkle wrote:
 I don't know if this has been proposed before but I was thinking how nice it 
 is to work in MATLAB (where you don't have to declare a variable's type) and 
 the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;
 
 That means, for example, if ReallyLongClass is a class that
 
   ReallyLongClass f = new ReallyLongClass;
 
 can be replaced with
 
   f := new ReallyLongClass;
 
 It even will come in handy with lots of little variables like
   for (i:=0; i<10; i++) {...}
 
 If := appears inside an expression (say, expr) in a statement (say, stmt) 
 like
   if ((p := strchar(q,'a')) != null) {
      ... use p ...
   }
 then the rewritten code is
   { typeof(init) var; stmt' }
 where stmt' is stmt with := replaced with = in expr.
 
 Another example using if-else statement (from 
 digitalmars.D/27542)
  if ((line := ReadLine()) != null) {
       printf("We got a line, Chief!");
       line = EscapeLine(line);
       DeployLine(line);
  } else {
       printf("We are out of lines, Chief!");
       line = "Emergency Line";
       DeployLine(line);
  }
 is equivalent to
  {
    char[] line;
    if ((line = ReadLine()) != null) {
       printf("We got a line, Chief!");
       line = EscapeLine(line);
       DeployLine(line);
    } else {
       printf("We are out of lines, Chief!");
       line = "Emergency Line";
       DeployLine(line);
    }
  }
 
 An example that wouldn't work (from 
 http://www.digitalmars.com/d/archives/digitalmars/D/20481.html)
 
   do {
     x := getchar();
   } while (x != 'x');
 
 since x:=getchar(); is the deepest statement enclosing the := so the 
 declaration wouldn't be visible to the while condition.
 
 This proposal avoids the parsing ambiguity that Stewart found with
   if ((a*b = c) != 0) {...}
 since the a*b would continue to be parsed as it is today - as 
 multiplication.
 
 
 A "real-life" example is a modified std.string.find from phobos. Notice that 
 it only needs declarations where some unsigned size_t array lengths are 
 assigned to ints.
 int find(char[] s, char[] sub)
 {
   int sublength = sub.length;
 
   if (sublength == 0)
     return 0;
 
   c := sub[0];
   if (sublength == 1)
   {
       p := memchr(s, c, s.length);
       if (p)
          return p - &s[0];
   }
   else
   {
       int imax = s.length - sublength + 1;
 
       // Remainder of sub[]
       q := &sub[1];
       sublength--;
 
       for (i := 0; i < imax; i++)
       {
         p := memchr(&s[i], c, imax - i);
         if (!p)
           break;
         i = p - &s[0];
         if (memcmp(p + 1, q, sublength) == 0)
           return i;
       }
   }
   return -1;
 }
 
 
 

Aug 28 2005
next sibling parent Dejan Lekic <leka entropy.tmok.com> writes:
IMHO 
var := init;
is much cleaner than
#typeof var = init;
whether you like Pascal or not, You must admit that. :)

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
Aug 28 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:det1o2$1403$1 digitaldaemon.com...
 Seems like a handy syntactic sugar, but I'm of the opinion that too much 
 sugar is a kind of bloat; yes, it's convenient, but it adds unnecessary 
 complication to the syntax.
 Plus, I hated that := operator from pacal.

 However, maybe we could use something more consistent with the current 
 design, like:

 #typeof var = init;

 Where typeof is not followed by an opening parenthesis, so a default 
 (init) is assumed.
 This is similar to the behaviour of 'extern' for example, where if it's 
 not followed by a parenthesis, a default (D) is assumed. Same for align.

 However,
 #typeof var = init;
 maybe misleading, as it /can/ read: "var is a variable whose tyoe is the 
 same type as var", so maybe another keyword should be introduced:
 #auto_type var = init;

 or just
 #type var = init;

There's a proposed C++ extension that uses 'auto' (or maybe 'decl' I can't remember). I prefer the operator because 1) it's less typing (one of the goals of the idea is to cut down verbosity) 2) it is used to declare variables in expressions, too.
Aug 28 2005
parent reply Oskar <Oskar_member pathlink.com> writes:
In article <det4pk$16si$1 digitaldaemon.com>, Ben Hinkle says...
"Hasan Aljudy" <hasan.aljudy gmail.com> wrote in message 
news:det1o2$1403$1 digitaldaemon.com...
 Seems like a handy syntactic sugar, but I'm of the opinion that too much 
 sugar is a kind of bloat; yes, it's convenient, but it adds unnecessary 
 complication to the syntax.
 Plus, I hated that := operator from pacal.

 However, maybe we could use something more consistent with the current 
 design, like:

 #typeof var = init;

 Where typeof is not followed by an opening parenthesis, so a default 
 (init) is assumed.
 This is similar to the behaviour of 'extern' for example, where if it's 
 not followed by a parenthesis, a default (D) is assumed. Same for align.

 However,
 #typeof var = init;
 maybe misleading, as it /can/ read: "var is a variable whose tyoe is the 
 same type as var", so maybe another keyword should be introduced:
 #auto_type var = init;

 or just
 #type var = init;

There's a proposed C++ extension that uses 'auto' (or maybe 'decl' I can't remember). I prefer the operator because 1) it's less typing (one of the goals of the idea is to cut down verbosity) 2) it is used to declare variables in expressions, too.

There could be some advantages to 'auto' too. It could be used to make simple templates: auto f(auto x) { return x+1;} This would be most useful when defining function literals. Like: LongTypeName[] all = whatever(...); auto good = filter(all, function auto(auto x) { return x.isGood(); }); One alternative is to add type declarations implicitly when missing in function literals... Just remove the auto above: filter(all, function(x) { return x.isGood(); }); This is not incompatible with your := suggestion (which I really like!) /Oskar
Aug 30 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 There could be some advantages to 'auto' too. It could be used to make 
 simple
 templates:

 auto f(auto x) { return x+1;}

 This would be most useful when defining function literals.
 Like:

 LongTypeName[] all = whatever(...);
 auto good = filter(all, function auto(auto x) { return x.isGood(); });

 One alternative is to add type declarations implicitly when missing in 
 function
 literals... Just remove the auto above:

 filter(all, function(x) { return x.isGood(); });

Interesting. I hadn't thought of auto in function parameter lists and return values. Do you know if the C++ auto can do that? I don't even have a reference for what C++ auto proposal actually is so any links would be appreciated.
Aug 31 2005
parent reply "Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> writes:
"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:df4uko$28pd$1 digitaldaemon.com...
 Interesting. I hadn't thought of auto in function parameter lists and 
 return values. Do you know if the C++ auto can do that? I don't even have 
 a reference for what C++ auto proposal actually is so any links would be 
 appreciated.

This might help: http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=219 The proposal is available here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf
Aug 31 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Pablo Aguilar" <pablo.dot.aguilar gmail.dot.com> wrote in message 
news:df57fq$2ibf$1 digitaldaemon.com...
 "Ben Hinkle" <bhinkle mathworks.com> wrote in message 
 news:df4uko$28pd$1 digitaldaemon.com...
 Interesting. I hadn't thought of auto in function parameter lists and 
 return values. Do you know if the C++ auto can do that? I don't even have 
 a reference for what C++ auto proposal actually is so any links would be 
 appreciated.

This might help: http://www.informit.com/guides/content.asp?g=cplusplus&seqNum=219 The proposal is available here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf

Cool, thanks. That's an interesting read. The approach there, for those who don't want to bother reading it, is that 'auto' is a keyword that can appear in declarations that gets resolved like a template argument deduction. So things like "const auto& x = y" or "std::vector<auto> a = b" are allowed. Given that D doesn't have const or references (eg int&) and that template instantiation is explicit I don't think the C++ proposal really is worth it - if indeed it even really applies to D. Anyway, it's definitely interesting stuff.
Sep 01 2005
prev sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Oskar wrote:
 In article <det4pk$16si$1 digitaldaemon.com>, Ben Hinkle says...
 
There's a proposed C++ extension that uses 'auto' (or maybe 'decl' I can't 
remember). I prefer the operator because
1) it's less typing (one of the goals of the idea is to cut down verbosity)
2) it is used to declare variables in expressions, too.

There could be some advantages to 'auto' too. It could be used to make simple templates: auto f(auto x) { return x+1;} This would be most useful when defining function literals. [...]

Please stop calling that "auto". There is already an auto keyword in D, which does a whole different thing. -- Bruno Medeiros Computer Science/Engineering student
Aug 31 2005
parent Oskar Linde <Oskar_member pathlink.com> writes:
In article <df5a9e$2ltk$1 digitaldaemon.com>, Bruno Medeiros says...
Oskar wrote:
 In article <det4pk$16si$1 digitaldaemon.com>, Ben Hinkle says...
 
There's a proposed C++ extension that uses 'auto' (or maybe 'decl' I can't 
remember). I prefer the operator because
1) it's less typing (one of the goals of the idea is to cut down verbosity)
2) it is used to declare variables in expressions, too.

There could be some advantages to 'auto' too. It could be used to make simple templates: auto f(auto x) { return x+1;} This would be most useful when defining function literals. [...]

Please stop calling that "auto". There is already an auto keyword in D, which does a whole different thing.

I know that very well. This is not a suggestion to change its behaviour in D, just a discussion about the possibilities of automatic type inference and how auto is proposed to work in C++. Feel free to replace auto by something else before reading my post. :) /Oskar
Sep 01 2005
prev sibling next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
A variation on the idea is to treat ExpressionStatements as adding the 
declaration to the current scope instead of just those ExpressionStatements 
of the form "a:=b;". That would make a difference for statements like 
"a:=b:=10;" and such. I actually like this version better than the more 
restrictive one, I think. 
Aug 28 2005
prev sibling next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote in news:dessc7$v3n$1 digitaldaemon.com

[...]
   var := init;
 is the same as
   typeof(init) var = init;

Before you start with such, please explain why declarations were introduced to some languages and then why D can get rid of them. -manfred
Aug 29 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:deuk7j$2dhn$1 digitaldaemon.com...
 Ben Hinkle wrote in news:dessc7$v3n$1 digitaldaemon.com

 [...]
   var := init;
 is the same as
   typeof(init) var = init;

Before you start with such, please explain why declarations were introduced to some languages and then why D can get rid of them. -manfred

It's funny you should ask that since I googled about a bit before posting. Here's a nice little summary at artima.com about why C added types to B http://www.artima.com/cppsource/spiritofc.html It had nothing to do with safety at first - it was about performance apparently. Note - I wouldn't say the proposal is to "get rid" of declarations. The proposal is to infer the type of the declaration from the initialization expression. The user still has to write := instead of = which indicates "declare and assign".
Aug 29 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote in news:dev34h$2ppd$1 digitaldaemon.com

[...]
 why C added types to B 

 it was about performance apparently.

1. One can very well have types, but no declarations at all. Therefore this article throws no light on my request. 2. Performance in that way, says the author, that B wasnt able to handle floats and the downsizing of the byte which were introduced by the upcoming hardware. No reason is given for the introduction of user defined types.
 Note - I wouldn't say the proposal is to "get rid" of
 declarations. The proposal is to infer the type of the
 declaration from the initialization expression. The user still
 has to write := instead of = which indicates "declare and
 assign". 

In fact you are proposing some sort of micro template, because you need not know anything of the type of the RHS. Or from another point of view, you are giving names to the otherweise unnamed intermediate results of the actual parameters of function calls. f( index:= g( h( 1))); Whenever this is usefull: why do you need the redundance of the ":=" and the fact, that the name on the LHS is undefined? Why doesn't it suffice to simply write index= g( h( 1)); and if `index' is not defined yet, then the "=" tranforms into your ":=" implicitely? Do you fear, that someone makes a typo and therefore indx= g( h( 1)); goes undetected? But if someone makes this typo and gets an error message wouldnt she/he mechanically insert the ":" to make the message go away? And if you want to prevent typos at all, what other schemes do you propose to secure that the programmer knows what she/he types? -manfred
Aug 29 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:devgi7$3mg$1 digitaldaemon.com...
 Ben Hinkle wrote in news:dev34h$2ppd$1 digitaldaemon.com

 [...]
 why C added types to B

 it was about performance apparently.

1. One can very well have types, but no declarations at all. Therefore this article throws no light on my request. 2. Performance in that way, says the author, that B wasnt able to handle floats and the downsizing of the byte which were introduced by the upcoming hardware. No reason is given for the introduction of user defined types.

If you want more motivation see previous D posts requesting tings like this and google for anything involving words and phrases like "type inference in C/C++", "dynamic types", "static type" etc etc. The holy grail of computer languages is to get the ease-of-use of a scripting language and that scales to large high-performance projects. I think the impact on ease-of-use is obvious. To me the only downside of the idea is any impact on large-scale development and clearly I believe it doesn't hurt large-scale development.
 Note - I wouldn't say the proposal is to "get rid" of
 declarations. The proposal is to infer the type of the
 declaration from the initialization expression. The user still
 has to write := instead of = which indicates "declare and
 assign".

In fact you are proposing some sort of micro template, because you need not know anything of the type of the RHS. Or from another point of view, you are giving names to the otherweise unnamed intermediate results of the actual parameters of function calls. f( index:= g( h( 1))); Whenever this is usefull: why do you need the redundance of the ":=" and the fact, that the name on the LHS is undefined? Why doesn't it suffice to simply write index= g( h( 1)); and if `index' is not defined yet, then the "=" tranforms into your ":=" implicitely? Do you fear, that someone makes a typo and therefore indx= g( h( 1)); goes undetected?

yes
 But if someone makes this typo and gets an error message wouldnt
 she/he mechanically insert the ":" to make the message go away?

no
 And if you want to prevent typos at all, what other schemes do you
 propose to secure that the programmer knows what she/he types?

huh?
 -manfred 

Aug 29 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote in news:devhba$4bh$1 digitaldaemon.com

[...]
 If you want more motivation see previous D posts requesting
 tings like this

I already have posted some of these myself, but nobody seems to catch the sarcasm. The comunity starts to nit pick on syntactic saccharin by declaring it as syntactic sugar while weighty points of D remain undefined or ambiguous and nobody cares. In the forum attached to the article you cited, Walter has given the astonishing statement, that D goes into the direction the comunity wants D to go. So stop these talks on saccharin: move D! [...]
 Do you fear, that someone makes a typo and therefore
  indx= g( h( 1));
 goes undetected?


 And if you want to prevent typos at all, what other schemes do
 you propose to secure that the programmer knows what she/he
 types? 


You fear, that a typo like `indx= g( h( 1));' goes undetected if one wants to write `index= g( h( 1));' and index is a declared variable. Therefore if `index' is not a name of a declared variable you want the type of `index' to be inferred from the acompanying assignment by changing the `=' to a `:='. You want this redundancy. But in the RHS there might be a typo also `index:= g( g( 1));' contains also only one typo and might change the type of `index' to something completely different which may go undetected, because the function(s) receiving `index' as a parameter has(ve) overload(s) for this type. If the variable declared this way is public it may very well have severe consequences in a large scale project. So, please explain, why you need redundancy in order to have irredundancy. -manfred
Aug 29 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 You fear, that a typo like `indx= g( h( 1));' goes undetected if
 one wants to write `index= g( h( 1));' and index is a declared
 variable.

 Therefore if `index' is not a name of a declared variable you want
 the type of `index' to be inferred from the acompanying assignment
 by changing the `=' to a `:='.

 You want this redundancy. But in the RHS there might be a typo also
 `index:= g( g( 1));' contains also only one typo and might change
 the type of `index' to something completely different which may go
 undetected, because the function(s) receiving `index' as a
 parameter has(ve) overload(s) for this type.

I agree that is a risk when the user relies on := instead of explicit declarations.
 If the variable declared this way is public it may very well have
 severe consequences in a large scale project.

I don't believe the risk is severe. I've been coding in MATLAB for years and frankly typos are a small source of bugs. In code of significant complexity the user can be as strict as they want by only using explicit declarations and stict to implicit declarations for when they feel comfortable. In any case if the user had an explicit declaration like int index = g(g(1)) and g(x) computed something like 2*x while h(x) computed 3*x then obviously the code is still hosed and contains a bug. With or without implicit declarations there is no bullet-proof way to prevent people from typing the wrong symbol.
 So, please explain, why you need redundancy in order to have
 irredundancy.

 -manfred 

Aug 29 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote in news:devrpp$e1m$1 digitaldaemon.com

[...]
 With
 or without implicit declarations there is no bullet-proof way to
 prevent people from typing the wrong symbol.
 
 So, please explain, why you need redundancy in order to have
 irredundancy.


Therefore the request keeps valid. -manfred
Aug 30 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 29 Aug 2005 20:16:54 +0000 (UTC), Manfred Nowak wrote:

 The comunity starts to nit pick on syntactic 
 saccharin by declaring it as syntactic sugar while weighty points 
 of D remain undefined or ambiguous and nobody cares.

I did note that 'standardized documentation' comes out at 38 of 41 wishlist items ;-) http://all-technology.com/eigenpolls/dwishlist/index.php -- Derek Parnell Melbourne, Australia 30/08/2005 10:23:01 AM
Aug 29 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Derek Parnell wrote:

[...]
 I did note that 'standardized documentation' comes out at 38 of
 41 wishlist items ;-)
 
   http://all-technology.com/eigenpolls/dwishlist/index.php

Oh wow. Had my first look into that list and I must say. -manfred
Aug 30 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
 Do you fear, that someone makes a typo and therefore
  indx= g( h( 1));
 goes undetected?

I should add to my previous posts that the main reason for not changing = to implicitly declare is to allow coders to "opt-in" to the new semantics. People porting C/C++/Java code don't have to worry about suddenly all their = operators implicitly declaring stuff. Users can safely ignore := if they want to and always write "traditional" C with explicit declarations.
Aug 29 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote:

[...]
 People porting C/C++/Java code don't have
 to worry about suddenly all their = operators implicitly
 declaring stuff.

Running code rarely has assignments to undefined names. Therefore porting running code causes no worries. Paranoids can be served with a pragma switching implicit declarations off. -manfred
Aug 30 2005
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
 Note - I wouldn't say the proposal is to "get rid" of
 declarations. The proposal is to infer the type of the
 declaration from the initialization expression. The user still
 has to write := instead of = which indicates "declare and
 assign". 

In fact you are proposing some sort of micro template, because you need not know anything of the type of the RHS.

Type inference was there long before the word 'template' was used in programming languages. Anyway I don't get wat typeinference has to do with templates.
Or from another point of view, you are giving names to the 
otherweise unnamed intermediate results of the actual parameters of 
function calls.
  f( index:= g( h( 1)));

Whenever this is usefull: why do you need the redundance of the 
":="  and the fact, that the name on the LHS is undefined?

Why doesn't it suffice to simply write
  index= g( h( 1));
and if `index' is not defined yet, then the "=" tranforms into your 
":=" implicitely?

Do you fear, that someone makes a typo and therefore
  indx= g( h( 1));
goes undetected?

Yes. I used BASICs and the like and this is an error that often occures.
But if someone makes this typo and gets an error message wouldnt 
she/he mechanically insert the ":" to make the message go away?

No. I have used languages with type inference.
And if you want to prevent typos at all, what other schemes do you 
propose to secure that the programmer knows what she/he types?

This proposal has nothing to do with typos at all.
Aug 31 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Matthias Becker wrote in news:df47ja$1i7b$1 digitaldaemon.com

[...]
 Anyway I don't get wat typeinference has to do with templates. 

Maybe there is nothing to get. [...]
 Yes. I used BASICs and the like and this is an error that often
 occures. 

I used especially `awk' and I had several bugs which turned out to be caused by a typo in the name of a variable, thereby destroying the intended control flow.
But if someone makes this typo and gets an error message wouldnt
she/he mechanically insert the ":" to make the message go away?


I do not get what you want to say with this.
And if you want to prevent typos at all, what other schemes do
you propose to secure that the programmer knows what she/he
types? 

This proposal has nothing to do with typos at all.

Nice try. But please formally define the conditions under which a proposal has something to do with typos. ... Can it be, that you are a super programmer or a bot, capable of switching off the causes of human mistakes at will and getting everything right the first time. I wonder how many years ago the last syntactical or semantical error in one of your programs was detected by a compiler or by testing---or weren't there any ever? -manfred
Aug 31 2005
parent reply Matthias Becker <Matthias_member pathlink.com> writes:
But if someone makes this typo and gets an error message wouldnt
she/he mechanically insert the ":" to make the message go away?


I do not get what you want to say with this.

I have used languages with type inference and I never automatically inserted the needed synthax to define a new variable. Instead I've searched for a typo in the variable-name. So I wouldn't mechanically insert the ":" to make the message fo away. And I doubt many others would do that.
And if you want to prevent typos at all, what other schemes do
you propose to secure that the programmer knows what she/he
types? 

This proposal has nothing to do with typos at all.

Nice try. But please formally define the conditions under which a proposal has something to do with typos. ... Can it be, that you are a super programmer or a bot, capable of switching off the causes of human mistakes at will and getting everything right the first time. I wonder how many years ago the last syntactical or semantical error in one of your programs was detected by a compiler or by testing---or weren't there any ever?

I don't have a formal definition of the conditions under which a proposal has something to do with typos. But Ben Hinkle proposed to add more type inference to the language. Than you asked "And if you want to prevent typos ...". He didn't. He just wanted to have more type inference.
Sep 03 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Matthias Becker wrote in news:dfcddp$6mf$1 digitaldaemon.com

[...]
 I have used languages with type inference and I never
 automatically inserted the needed synthax to define a new
 variable. Instead I've searched for a typo in the variable-name.
 So I wouldn't mechanically insert the ":" to make the message fo
 away.

 Than you asked "And if you want to prevent typos ...".
 He didn't. He just wanted to have more type inference.

Now we are at the critical point. The intended type of a variable can be deduced from either - an explicit declaration of the intended type of the variable, or - an implicit inference from the value assigned to the variable. Explicit declarations are currently of the form <defined type> <undefined name> [ '=' <initialization> ] and assignments are of the form <defined name> '=' <expression> Therefore it would be natural to define as an implicit inference of a type the form <undefined name> '=' <expression> But that is not the proposal. The proposal is of the form <undefined name> ':=' <expression> A reason must be given for this syntactical salt, this deviation from the natural extension of the language. Bringing compatibility to C, Java and the like as an argument is useless, because this were never design goals for D on the language level. And the design goal of "looks like C, acts like C" has been given up long ago. If the reason are not typos, what is it then? -manfred
Sep 03 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
In article <dfd3dv$mm2$1 digitaldaemon.com>, Manfred Nowak says...
Matthias Becker wrote in news:dfcddp$6mf$1 digitaldaemon.com

[...]
 I have used languages with type inference and I never
 automatically inserted the needed synthax to define a new
 variable. Instead I've searched for a typo in the variable-name.
 So I wouldn't mechanically insert the ":" to make the message fo
 away.

 Than you asked "And if you want to prevent typos ...".
 He didn't. He just wanted to have more type inference.

Now we are at the critical point. The intended type of a variable can be deduced from either - an explicit declaration of the intended type of the variable, or - an implicit inference from the value assigned to the variable. Explicit declarations are currently of the form <defined type> <undefined name> [ '=' <initialization> ] and assignments are of the form <defined name> '=' <expression> Therefore it would be natural to define as an implicit inference of a type the form <undefined name> '=' <expression> But that is not the proposal. The proposal is of the form <undefined name> ':=' <expression> A reason must be given for this syntactical salt, this deviation from the natural extension of the language. Bringing compatibility to C, Java and the like as an argument is useless, because this were never design goals for D on the language level. And the design goal of "looks like C, acts like C" has been given up long ago. If the reason are not typos, what is it then? -manfred

The = operator already has a well-established meaning in C/C++/Java and I think D should keep that meaning (which you say is a useless argument but I disagree). The := introduces extra semantics to = and so it is natural to use a different symbol. Another point to keep in mind is that I didn't actually say the left-hand-side must be an undefined symbol. For example # int x = 2; # { x = 1; } // refers to x in outer scope # { int x = 3; } // defines a local x in scope is well-defined in D today. With my proposal one could code up the above as # x := 2; # { x = 1; } # { x := 3; } whereas with your proposal of reusing = the last statement would have to use the explicit declaration (presumably - I don't actually know exactly what you propose and it isn't clear what you mean by "undefined name").
Sep 03 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote in news:dfd5r0$o63$1 digitaldaemon.com

[...]
 The = operator already has a well-established meaning in
 C/C++/Java and I think D should keep that meaning (which you say
 is a useless argument but I disagree).

I do not disagree, that you think this way; we only disagree on the the validity of the content of your argument. In the same style I could say, '=' and ':=' have well-established meanings in pascal, etc... or directly attack your argument by stating that in C++ and Java the '=' operator is overloadable and therefore does not have any standard meaning.
 The := introduces extra
 semantics to = and so it is natural to use a different symbol.

This argument does hold either, because the '=' has already also the extra semantics of separating a function name from its parameter. If your argument is valid you also have to say that natrurally a different symbol has to be used. By the way: what is natural in a technical environment? I think we should use canonical instead of natural.
 Another point to keep in mind is that I didn't actually say the
 left-hand-side must be an undefined symbol. For example
 #  int x = 2;
 #  { x = 1; }  // refers to x in outer scope
 #  { int x = 3; } // defines a local x in scope
 is well-defined in D today. With my proposal one could code up
 the above as #  x := 2;
 #  { x = 1; }
 #  { x := 3; }
 whereas with your proposal of reusing = the last statement would
 have to use the explicit declaration (presumably - I don't
 actually know exactly what you propose and it isn't clear what
 you mean by "undefined name"). 

In fact I am not proposing something. I only emphasize the need to mention the rationales behind any proposal. And I agree, that my informal dividing of the cases into "forms" may have failed. May be I should have better choosen <undefinable name> instead of <defined name> and <definable name> instead of <undefined name>. But to me this is marginal. Your example seems also to fall short in the same sense, because hiding declared variables in the same scope is illegal in D. But I agree, that you finally came up with a rational for having an additional token in the language. -manfred
Sep 04 2005
parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Manfred Nowak" <svv1999 hotmail.com> wrote in message 
news:dffb5m$2j6b$1 digitaldaemon.com...
 Ben Hinkle wrote in news:dfd5r0$o63$1 digitaldaemon.com

 [...]
 The = operator already has a well-established meaning in
 C/C++/Java and I think D should keep that meaning (which you say
 is a useless argument but I disagree).

I do not disagree, that you think this way; we only disagree on the the validity of the content of your argument. In the same style I could say, '=' and ':=' have well-established meanings in pascal,

D doesn't try to maintain compatibility with Pascal. We shouldn't feel held back by non-C-family languages.
 etc... or directly attack your argument by stating that in C++ and
 Java the '=' operator is overloadable and therefore does not have
 any standard meaning.

Java doesn't have operator overloading. In terms of C++ overloading I have been referring to the buitin = as having standard behavior across C/C++/Java. And even with overloads one can't overload it to also declare.
 The := introduces extra
 semantics to = and so it is natural to use a different symbol.

This argument does hold either, because the '=' has already also the extra semantics of separating a function name from its parameter. If your argument is valid you also have to say that natrurally a different symbol has to be used.

I'm talking about = inside expressions where it already has a meaning. The = symbol is used for different purposes elsewhere in the language but that has nothing to do with = inside expressions.
 By the way: what is natural in a technical environment? I think we
 should use canonical instead of natural.


 Another point to keep in mind is that I didn't actually say the
 left-hand-side must be an undefined symbol. For example
 #  int x = 2;
 #  { x = 1; }  // refers to x in outer scope
 #  { int x = 3; } // defines a local x in scope
 is well-defined in D today. With my proposal one could code up
 the above as #  x := 2;
 #  { x = 1; }
 #  { x := 3; }
 whereas with your proposal of reusing = the last statement would
 have to use the explicit declaration (presumably - I don't
 actually know exactly what you propose and it isn't clear what
 you mean by "undefined name").

In fact I am not proposing something. I only emphasize the need to mention the rationales behind any proposal.

OK - but to me the whole thing seems pretty clear and the trade-offs are clear. Given the previous threads about both of the proposed behaviors I thought there was ample justification for the proposal. I can't read people's minds to know what level of detail of the rationale they want. Asking questions or proposing alternatives (or "attacking" as you say above) is I think a good way to go.
 And I agree, that my informal dividing of the cases into "forms"
 may have failed. May be I should have better choosen <undefinable
 name> instead of <defined name> and <definable name> instead of
 <undefined name>. But to me this is marginal.

 Your example seems also to fall short in the same sense, because
 hiding declared variables in the same scope is illegal in D.

I'm not sure what you mean by "hiding declared variables in the same scope is illegal". Are you referring to that section in the doc about local variable rules which is currently unenforced (and I have serious doubts it will ever be enforced)? In any case I was hoping you'd realize the code snippet I gave applies to many other situations when a local declaration hides another variable. For example int x; void foo() { int x = 1; } or module foo1; int x; module foo2; import foo1; void foo() { int x = 1; } In both cases the x in foo is hiding another x.
 But I agree, that you finally came up with a rational for having an
 additional token in the language.

I finally decided I had to spell it out.
 -manfred 

Sep 06 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote:

[several more or less useful remarks]

My statements on the above would mainly consist of thanks for your 
kindness and remarks on my opinion how disputes should be held to 
come to an agreement from different positions. But especially the 
latter would go to far OT. 


 But I agree, that you finally came up with a rational for
 having an additional token in the language.


Ooops. If there were posts on this before, then I missed them. Sorry for that. -manfred
Sep 06 2005
prev sibling next sibling parent reply "Charles" <noone nowhere.com> writes:
I love it.  However ,

for (i:=0; i<10; i++) {...}

how does the compiler know to make i an int , as opposed to a uint / real / other compatible type? A cast there would make it worse then explictly defining the type IMO. Charlie "Ben Hinkle" <ben.hinkle gmail.com> wrote in message news:dessc7$v3n$1 digitaldaemon.com...
 I don't know if this has been proposed before but I was thinking how nice

 is to work in MATLAB (where you don't have to declare a variable's type)

 the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;

 That means, for example, if ReallyLongClass is a class that

   ReallyLongClass f = new ReallyLongClass;

 can be replaced with

   f := new ReallyLongClass;

 It even will come in handy with lots of little variables like
   for (i:=0; i<10; i++) {...}

 If := appears inside an expression (say, expr) in a statement (say, stmt)
 like
   if ((p := strchar(q,'a')) != null) {
      ... use p ...
   }
 then the rewritten code is
   { typeof(init) var; stmt' }
 where stmt' is stmt with := replaced with = in expr.

 Another example using if-else statement (from
 digitalmars.D/27542)
  if ((line := ReadLine()) != null) {
       printf("We got a line, Chief!");
       line = EscapeLine(line);
       DeployLine(line);
  } else {
       printf("We are out of lines, Chief!");
       line = "Emergency Line";
       DeployLine(line);
  }
 is equivalent to
  {
    char[] line;
    if ((line = ReadLine()) != null) {
       printf("We got a line, Chief!");
       line = EscapeLine(line);
       DeployLine(line);
    } else {
       printf("We are out of lines, Chief!");
       line = "Emergency Line";
       DeployLine(line);
    }
  }

 An example that wouldn't work (from
 http://www.digitalmars.com/d/archives/digitalmars/D/20481.html)

   do {
     x := getchar();
   } while (x != 'x');

 since x:=getchar(); is the deepest statement enclosing the := so the
 declaration wouldn't be visible to the while condition.

 This proposal avoids the parsing ambiguity that Stewart found with
   if ((a*b = c) != 0) {...}
 since the a*b would continue to be parsed as it is today - as
 multiplication.


 A "real-life" example is a modified std.string.find from phobos. Notice

 it only needs declarations where some unsigned size_t array lengths are
 assigned to ints.
 int find(char[] s, char[] sub)
 {
   int sublength = sub.length;

   if (sublength == 0)
     return 0;

   c := sub[0];
   if (sublength == 1)
   {
       p := memchr(s, c, s.length);
       if (p)
          return p - &s[0];
   }
   else
   {
       int imax = s.length - sublength + 1;

       // Remainder of sub[]
       q := &sub[1];
       sublength--;

       for (i := 0; i < imax; i++)
       {
         p := memchr(&s[i], c, imax - i);
         if (!p)
           break;
         i = p - &s[0];
         if (memcmp(p + 1, q, sublength) == 0)
           return i;
       }
   }
   return -1;
 }

Aug 29 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Charles" <noone nowhere.com> wrote in message 
news:devlr0$8gp$1 digitaldaemon.com...
I love it.  However ,

for (i:=0; i<10; i++) {...}

how does the compiler know to make i an int , as opposed to a uint / real / other compatible type? A cast there would make it worse then explictly defining the type IMO.

The type of 0 is int. To get uint write 0U or 0u. To get real write 0.0L or 0.0l (since a lower-case l looks like a 1, however, I recommend using L). I agree writing short x = 0; is better than x := cast(short)0; No-one is saying good-ol' declarations will go away so obviously the preferred way is to use a standard declaration rather than casting and using implicit declarations.
Aug 29 2005
prev sibling next sibling parent AJG <AJG_member pathlink.com> writes:
In article <dessc7$v3n$1 digitaldaemon.com>, Ben Hinkle says...
I don't know if this has been proposed before but I was thinking how nice it 
is to work in MATLAB (where you don't have to declare a variable's type) and 
the following operator came to mind
  var := init;

Sorry for the delay. Having some trouble with Katrina. At any rate, I love it. This would come quite handy in a large number of situations. Moreover, it includes the benefits of ExpressionStatements, without the parsing ambiguities. You have my vote. Cheers, --AJG.
is the same as
  typeof(init) var = init;

That means, for example, if ReallyLongClass is a class that

  ReallyLongClass f = new ReallyLongClass;

can be replaced with

  f := new ReallyLongClass;

It even will come in handy with lots of little variables like
  for (i:=0; i<10; i++) {...}

If := appears inside an expression (say, expr) in a statement (say, stmt) 
like
  if ((p := strchar(q,'a')) != null) {
     ... use p ...
  }
then the rewritten code is
  { typeof(init) var; stmt' }
where stmt' is stmt with := replaced with = in expr.

Another example using if-else statement (from 
digitalmars.D/27542)
 if ((line := ReadLine()) != null) {
      printf("We got a line, Chief!");
      line = EscapeLine(line);
      DeployLine(line);
 } else {
      printf("We are out of lines, Chief!");
      line = "Emergency Line";
      DeployLine(line);
 }
is equivalent to
 {
   char[] line;
   if ((line = ReadLine()) != null) {
      printf("We got a line, Chief!");
      line = EscapeLine(line);
      DeployLine(line);
   } else {
      printf("We are out of lines, Chief!");
      line = "Emergency Line";
      DeployLine(line);
   }
 }

An example that wouldn't work (from 
http://www.digitalmars.com/d/archives/digitalmars/D/20481.html)

  do {
    x := getchar();
  } while (x != 'x');

since x:=getchar(); is the deepest statement enclosing the := so the 
declaration wouldn't be visible to the while condition.

This proposal avoids the parsing ambiguity that Stewart found with
  if ((a*b = c) != 0) {...}
since the a*b would continue to be parsed as it is today - as 
multiplication.


A "real-life" example is a modified std.string.find from phobos. Notice that 
it only needs declarations where some unsigned size_t array lengths are 
assigned to ints.
int find(char[] s, char[] sub)
{
  int sublength = sub.length;

  if (sublength == 0)
    return 0;

  c := sub[0];
  if (sublength == 1)
  {
      p := memchr(s, c, s.length);
      if (p)
         return p - &s[0];
  }
  else
  {
      int imax = s.length - sublength + 1;

      // Remainder of sub[]
      q := &sub[1];
      sublength--;

      for (i := 0; i < imax; i++)
      {
        p := memchr(&s[i], c, imax - i);
        if (!p)
          break;
        i = p - &s[0];
        if (memcmp(p + 1, q, sublength) == 0)
          return i;
      }
  }
  return -1;
}

Aug 29 2005
prev sibling next sibling parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Ben Hinkle wrote:
 I don't know if this has been proposed before but I was thinking how nice it 
 is to work in MATLAB (where you don't have to declare a variable's type) and 
 the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;
 

be mentioned at least once. -- Bruno Medeiros Computer Science/Engineering student
Aug 30 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:df2r7u$2c6$3 digitaldaemon.com...
 Ben Hinkle wrote:
 I don't know if this has been proposed before but I was thinking how nice 
 it is to work in MATLAB (where you don't have to declare a variable's 
 type) and the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;

mentioned at least once.

Two points to consider: 1) the use of := is optional so if one wants to see types one can code them in 2) temporary values hide types all the time already. Expressions like foo(bar()) don't indicate the type of the temporary result from bar passed to foo. In the same way tmp := bar(); foo(tmp); doesn't show the type. It might be worthwhile to see another sample. I've pasted below the before-and-after use of := for the dmd sample sieve.d (I hope Walter doesn't mind!) bit flags[8191]; int main() { int i, prime, k, count, iter; printf("10 iterations\n"); for (iter = 1; iter <= 10; iter++) { count = 0; flags[] = true; for (i = 0; i < flags.length; i++) { if (flags[i]) { prime = i + i + 3; k = i + prime; while (k < flags.length) { flags[k] = false; k += prime; } count += 1; } } } printf ("\n%d primes\n", count); return 0; } and after substituting := where appropriate bit flags[8191]; int main() { int count; printf("10 iterations\n"); for (iter := 1; iter <= 10; iter++) { count = 0; flags[] = true; for (i := 0; i < flags.length; i++) { if (flags[i]) { prime := i + i + 3; k := i + prime; while (k < flags.length) { flags[k] = false; k += prime; } count += 1; } } } printf ("\n%d primes\n", count); return 0; } Notice the net effect is removing those pesky (and pretty much meaningless) int declarations just inside main().
Aug 31 2005
parent reply James Dunne <james.jdunne gmail.com> writes:
In article <df4clp$1ng3$1 digitaldaemon.com>, Ben Hinkle says...
"Bruno Medeiros" <daiphoenixNO SPAMlycos.com> wrote in message 
news:df2r7u$2c6$3 digitaldaemon.com...
 Ben Hinkle wrote:
 I don't know if this has been proposed before but I was thinking how nice 
 it is to work in MATLAB (where you don't have to declare a variable's 
 type) and the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;

mentioned at least once.

Two points to consider: 1) the use of := is optional so if one wants to see types one can code them in 2) temporary values hide types all the time already. Expressions like foo(bar()) don't indicate the type of the temporary result from bar passed to foo. In the same way tmp := bar(); foo(tmp); doesn't show the type. It might be worthwhile to see another sample. I've pasted below the before-and-after use of := for the dmd sample sieve.d (I hope Walter doesn't mind!) bit flags[8191]; int main() { int i, prime, k, count, iter; printf("10 iterations\n"); for (iter = 1; iter <= 10; iter++) { count = 0; flags[] = true; for (i = 0; i < flags.length; i++) { if (flags[i]) { prime = i + i + 3; k = i + prime; while (k < flags.length) { flags[k] = false; k += prime; } count += 1; } } } printf ("\n%d primes\n", count); return 0; } and after substituting := where appropriate bit flags[8191]; int main() { int count; printf("10 iterations\n"); for (iter := 1; iter <= 10; iter++) { count = 0; flags[] = true; for (i := 0; i < flags.length; i++) { if (flags[i]) { prime := i + i + 3; k := i + prime; while (k < flags.length) { flags[k] = false; k += prime; } count += 1; } } } printf ("\n%d primes\n", count); return 0; } Notice the net effect is removing those pesky (and pretty much meaningless) int declarations just inside main().

Whoa now... red flag going up. What scope are those new variables in? If assuming the local scope of the := assignment expression, then your translation is not direct. Regards, James Dunne
Aug 31 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
and after substituting := where appropriate

bit flags[8191];
int main()
{   int     count;

    printf("10 iterations\n");
    for (iter := 1; iter <= 10; iter++)
    {   count = 0;
        flags[] = true;
        for (i := 0; i < flags.length; i++)
        {   if (flags[i])
            {   prime := i + i + 3;
                k := i + prime;
                while (k < flags.length)
                {
                    flags[k] = false;
                    k += prime;
                }
                count += 1;
            }
        }
    }
    printf ("\n%d primes\n", count);
    return 0;
}

Notice the net effect is removing those pesky (and pretty much 
meaningless)
int declarations just inside main().

Whoa now... red flag going up. What scope are those new variables in? If assuming the local scope of the := assignment expression, then your translation is not direct.

Yup - I didn't bother pointing out that the := version also narrowed the scopes. That's why "count" needed to remain at the main() scope since it is used outside of the iter for loop. Otherwise I would have made that a := also. I think using the narrow scopes is a benefit over the original just as modern C++ coding standards recommend declaring variables in the smallest scope just before usage. We don't live in K&R C anymore.
Aug 31 2005
parent reply Bruno Medeiros <daiphoenixNO SPAMlycos.com> writes:
Ben Hinkle wrote:
Notice the net effect is removing those pesky (and pretty much 
meaningless)
int declarations just inside main().

Whoa now... red flag going up. What scope are those new variables in? If assuming the local scope of the := assignment expression, then your translation is not direct.

Yup - I didn't bother pointing out that the := version also narrowed the scopes. That's why "count" needed to remain at the main() scope since it is used outside of the iter for loop. Otherwise I would have made that a := also. I think using the narrow scopes is a benefit over the original just as modern C++ coding standards recommend declaring variables in the smallest scope just before usage. We don't live in K&R C anymore.

The narrow(er?) scope is indeed a benefit, but that could be done without ":=". -- Bruno Medeiros Computer Science/Engineering student
Aug 31 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
 The narrow(er?) scope is indeed a benefit, but that could be done without 
 ":=".

Yup. I didn't mean to imply otherwise. An example like if (focus := GetFocus()) { ... do something with focus HWND ... } would be more interesting than the one I posted. The sieve example was a short "real-world" example of possible uses of := that wasn't intended to imply it's the only way to code up sieve or that := is only useful for that kind of code.
Sep 01 2005
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Bruno Medeiros wrote in news:df2r7u$2c6$3 digitaldaemon.com

[...]
 I'm on the opinion that the var type is important and worthy
 enough to be mentioned at least once.

To serve your opinion with an argument: <code> f:= &module1.g; v:= module2.v; w:= f( v); // error </code> where the error reported is: | function f () does not match argument types (T) Now ask those of other opnions, who does not believe, that such implicit declarations may lead to problems in large scale projects, how they would debug this. And if they want to tell, that you can forbid the use of the `:=' if you think it leads to problems, just say them that your boss bought such a big project with those `:=' in it. -manfred
Aug 31 2005
parent reply Oskar <Oskar_member pathlink.com> writes:
In article <df65lj$h02$1 digitaldaemon.com>, Manfred Nowak says...
Bruno Medeiros wrote in news:df2r7u$2c6$3 digitaldaemon.com

[...]
 I'm on the opinion that the var type is important and worthy
 enough to be mentioned at least once.

To serve your opinion with an argument: <code> f:= &module1.g; v:= module2.v; w:= f( v); // error </code>

How is this any different from SomeType w = module1.g(module2.v);?
where the error reported is:

| function f () does not match argument types (T)

Why wouldn't the error message be: | function TypeA f(TypeB) does not match argument types (TypeC) where it is obvious what the types are.
Now ask those of other opnions, who does not believe, that such 
implicit declarations may lead to problems in large scale projects, 
how they would debug this.

In the same way as I would debug: TypeD f = &module1.g; // error TypeC v = module2.v; TypeA w = f( v); or SomeType w = module1.g(module2.v); /Oskar
Sep 01 2005
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Oskar wrote

[something]

Obey the rules of the netiquette, i.e. supply full name and a valid 
email address, then you may get further hints.

-manfred
Sep 01 2005
parent reply Oskar Linde <Oskar_member pathlink.com> writes:
In article <df74n2$r85$1 digitaldaemon.com>, Manfred Nowak says...
Oskar wrote

[something]

Obey the rules of the netiquette, i.e. supply full name and a valid 
email address, then you may get further hints.

That, I can certainly do, as my only excuse is laziness when using the web interface. /Oskar
Sep 01 2005
next sibling parent Oskar Linde <oskar.linde gmail.com> writes:
In article <df78mk$11d5$1 digitaldaemon.com>, Oskar Linde says...
In article <df74n2$r85$1 digitaldaemon.com>, Manfred Nowak says...
Oskar wrote

[something]

Obey the rules of the netiquette, i.e. supply full name and a valid 
email address, then you may get further hints.

That, I can certainly do, as my only excuse is laziness when using the web interface. /Oskar

And also not understanding how it works... Obviously... /Oskar
Sep 01 2005
prev sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Oskar Linde" <Oskar_member pathlink.com> wrote in message 
news:df78mk$11d5$1 digitaldaemon.com...
 In article <df74n2$r85$1 digitaldaemon.com>, Manfred Nowak says...
Oskar wrote

[something]

Obey the rules of the netiquette, i.e. supply full name and a valid
email address, then you may get further hints.

That, I can certainly do, as my only excuse is laziness when using the web interface. /Oskar

I think Manfred was being evasive :-) I certainly don't mind what name you (or anyone else) use. It helps to be consistent since then tools that parse newsgroups can group all your posts together (eg, sort-by-name and my own code that tracks posting histories based on name) Also I agree with your posted response to Manfred's about how to debug := code. It's a very simple operator that is 99% the same as sprinkling "typeof" and braces around.
Sep 01 2005
parent Manfred Nowak <svv1999 hotmail.com> writes:
Ben Hinkle wrote in news:df7fqc$1add$1 digitaldaemon.com

[...]
 I think Manfred was being evasive :-)

No. I was angry as one can conclude from the missing "please" in front of the "obeye". Sorry for that. [...]
 Also I agree with your posted response to Manfred's about how to
 debug := code. It's a very simple operator that is 99% the same
 as sprinkling "typeof" and braces around. 

When I started with D, in http://www.digitalmars.com/d/archives/21537.html you Ben, gave the argument of the difficulties accompanied by having to dive deeply into a module heterarchy. But as I meanwhile concluded its _not_ your proposal that establishes the same sort of difficulties again. The `typeof' construct itself is responsible for that. So, feeling that something is wrong and wrongly attacking your proposal I finally tracked it down to `typeof'. To clear this I start a new thread. -manfred
Sep 01 2005
prev sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
Ben Hinkle escribió:
 I don't know if this has been proposed before but I was thinking how nice it 
 is to work in MATLAB (where you don't have to declare a variable's type) and 
 the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;
 

What about the other syntax with this same purpose proposed... mmm... a long time ago? var foo = <expr>; //or autotype foo = <expr>; -- Carlos Santander Bernal
Sep 07 2005
next sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:dfnsj5$19ci$1 digitaldaemon.com...
 Ben Hinkle escribió:
 I don't know if this has been proposed before but I was thinking how nice 
 it is to work in MATLAB (where you don't have to declare a variable's 
 type) and the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;

What about the other syntax with this same purpose proposed... mmm... a long time ago? var foo = <expr>; //or autotype foo = <expr>;

That still doesn't cover the declaration-in-expressions that makes up the second half of the proposal. Plus IMHO foo := <expr> is shorter and doesn't take up a keyword.
 -- 
 Carlos Santander Bernal 

Sep 07 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message 
news:dfnsj5$19ci$1 digitaldaemon.com...
 Ben Hinkle escribió:
 I don't know if this has been proposed before but I was thinking how nice 
 it
 is to work in MATLAB (where you don't have to declare a variable's type) 
 and
 the following operator came to mind
   var := init;
 is the same as
   typeof(init) var = init;

What about the other syntax with this same purpose proposed... mmm... a long time ago? var foo = <expr>; //or autotype foo = <expr>; -- Carlos Santander Bernal

Since I can't sleep :-( I tried converting another example from dmd/samples. I've attached four versions. The first is the original htmlget.d. The others are htmlget_autotype.d, htmlget_colon_eq.d and htmlget_cpp.d. The changes from the orginal have BVH in a comment in order to make it easier to pick out the changes. The autotype file replaces 7 declarations with autotype. The colon_eq version replaces 9 declarations and = uses with :=. The cpp version replaces 2 class instantiations with one of the proposed shortcut forms of using C++-like style ClassName var(arg1, arg2, ...); to mean ClassName var = new ClassName(arg1, arg2, ...); There isn't anything deep about the example chosen. It was another randomly opened file from dmd/samples meant to illustrate how these different proposals would look in (presumably typical) existing code.
Sep 08 2005