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 
http://www.digitalmars.com/drn-bin/wwwnews?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 
 http://www.digitalmars.com/drn-bin/wwwnews?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?


 yes


[...]

 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?


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?


 No. I have used languages with type inference.


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?


 No. I have used languages with type inference.


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



is well-defined in D today. With my proposal one could code up the above as



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



 is well-defined in D today. With my proposal one could code up



 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



 is well-defined in D today. With my proposal one could code up



 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.


 I finally decided I had to spell it out.


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


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
 http://www.digitalmars.com/drn-bin/wwwnews?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
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 
http://www.digitalmars.com/drn-bin/wwwnews?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;
 


I'm on the opinion that the var type is important and worthy enough to 
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;


 I'm on the opinion that the var type is important and worthy enough to be 
 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;


 I'm on the opinion that the var type is important and worthy enough to be 
 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. 


begin 666 htmlget.d
M+RH-" E(5$U,9V5T('=R:71T96X 8GD 0VAR:7-T;W!H97( 12X 36EL;&5R

M:70 9F]R(&%N>2!P=7)P;W-E+ T*"51H:7, 8V]D92!H87, ;F\ =V%R<F%N


M<W1D+G-T<F5A;3L-"FEM<&]R="!S=&0N<V]C:V5T+"!S=&0N<V]C:V5T<W1R

M<RYL96YG=&  /" R*0T*"7L-" D)<')I;G1F*")5<V%G93I<;B  (&AT;6QG

M=7)L(#T 87)G<ULQ73L-" EI;G0 :3L-" D-" EI(#T <W1D+G-T<FEN9RYF

M*'5R;%LP("XN(&E=+" B:'1T<"(I*0T*"0D)=&AR;W< ;F5W($5X8V5P=&EO
M;B B:'1T<#HO+R!E>'!E8W1E9"(I.PT*"7T-" D-" EI(#T <W1D+G-T<FEN
M9RYF:6YD*'5R;"P )R,G*3L-" EI9BAI("$]("TQ*2 O+R!296UO=F4 86YC
M:&]R(')E9BX-" D)=7)L(#T

M(#T]("TQ*0T*"7L-" D)9&]M86EN(#T


M"6D /2!S=&0N<W1R:6YG+F9I;F0H9&]M86EN+" G.B<I.PT*"6EF*&D /3T 


M86EN6VD *R Q("XN(&1O;6%I;BYL96YG=&A=*3L-" D)9&]M86EN(#T 9&]M

M9B B0V]N;F5C=&EN9R!T;R B('X 9&]M86EN('X (B!O;B!P;W)T("( ?B!S

M;R!3;V-K970 <V]C:R ](&YE=R!48W!3;V-K970H;F5W($EN=&5R;F5T061D
M<F5S<RAD;VUA:6XL('!O<G0I*3L-" E3=')E86T <W, /2!N97< 4V]C:V5T

M0V]N;F5C=&5D(5QN4F5Q=65S=&EN9R!54DP 7"(B('X =7)L('X (EPB+BXN

M?B B.B( ?B!S=&0N<W1R:6YG+G1O4W1R:6YG*'!O<G0I.PT*"7-S+G=R:71E
M4W1R:6YG*")'150 (B!^('5R;"!^("( 2%144"\Q+C%<<EQN( T*"0DB2&]S
M=#H (B!^(&1O;6%I;B!^(")<<EQN( T*"0DB7')<;B(I.PT*"0T*"2\O(%-K


M" D)"6)R96%K.PT*"0D-" D)8V]N<W0 8VAA<EM=($-/3E1%3E1?5%E015].
M04U%(#T
M3TY414Y47U194$5?3D%-12YL96YG=&  )B8-" D)"2%I8VUP*$-/3E1%3E1?
M5%E015].04U%+"!L:6YE6S  +BX 0T].5$5.5%]465!%7TY!344N;&5N9W1H

M5$5.5%]465!%7TY!344N;&5N9W1H("XN(&QI;F4N;&5N9W1H73L-" D)"6EF
M*'1Y<&4N;&5N9W1H(#P
M-5TI*0T*"0D)"71H<F]W(&YE=R!%>&-E<'1I;VXH(E523"!I<R!N;W0 =&5X


M(B4N*G-<;B(L(&QI;F4I.PT*"0D-" D)+R]I9BAS=&0N<W1R:6YG+FEF:6YD



M92YL96YG=&A=*2D-" D)"0EB<F5A:R!P<FEN=%]L:6YE<SL-" D)?0T*"7T-
5" D-" ER971U<FX ,#L-"GT-" T*
`
end

begin 666 htmlget_autotype.d
M+RH-" E(5$U,9V5T('=R:71T96X 8GD 0VAR:7-T;W!H97( 12X 36EL;&5R

M:70 9F]R(&%N>2!P=7)P;W-E+ T*"51H:7, 8V]D92!H87, ;F\ =V%R<F%N


M<W1D+G-T<F5A;3L-"FEM<&]R="!S=&0N<V]C:V5T+"!S=&0N<V]C:V5T<W1R

M<RYL96YG=&  /" R*0T*"7L-" D)<')I;G1F*")5<V%G93I<;B  (&AT;6QG


M9"YS=')I;F<N9FEN9"AU<FPL("(Z+R\B*3L +R]"5D -" EI9BAI("$]("TQ
M*0T*"7L-" D):68H:6-M<"AU<FQ;," N+B!I72P (FAT=' B*2D-" D)"71H



M.PT*"0T*"6D /2!S=&0N<W1R:6YG+F9I;F0H=7)L+" G+R<I.PT*"6-H87);

M" D)=7)L(#T
M," N+B!I73L-" D)=7)L(#T
M"0T*"75I;G0 <&]R=#L-" EI(#T <W1D+G-T<FEN9RYF:6YD*&1O;6%I;BP 
M)SHG*3L-" EI9BAI(#T

M;VYV+G1O57-H;W)T*&1O;6%I;EMI("L ,2 N+B!D;VUA:6XN;&5N9W1H72D[

M5$U,1T54*0T*"0EP<FEN=&8H(D-O;FYE8W1I;F< =&\ (B!^(&1O;6%I;B!^
M("( ;VX <&]R=" B('X <W1D+G-T<FEN9RYT;U-T<FEN9RAP;W)T*2!^("(N
M+BY<;B(I.PT*"0T*"2 O+T)62 T*"6%U=&\ 875T;W1Y<&4 <V]C:R ](&YE
M=R!48W!3;V-K970H;F5W($EN=&5R;F5T061D<F5S<RAD;VUA:6XL('!O<G0I


M97-T:6YG(%523"!<(B( ?B!U<FP ?B B7"(N+BY<;B(I.PT*"0T*"6EF*'!O






M"0EC;VYS="!C:&%R6UT 0T].5$5.5%]465!%7TY!344 /2 B0V]N=&5N="U4
M>7!E.B B.PT*"0EI9BAL:6YE+FQE;F=T:" ^($-/3E1%3E1?5%E015].04U%
M+FQE;F=T:" F) T*"0D)(6EC;7 H0T].5$5.5%]465!%7TY!344L(&QI;F5;

M;W1Y<&4 ='EP92 ](&QI;F5;0T].5$5.5%]465!%7TY!344N;&5N9W1H("XN
M(&QI;F4N;&5N9W1H73L +R]"5D -" D)"6EF*'1Y<&4N;&5N9W1H(#P
M?'P :6-M<" B=&5X="\B+"!T>7!E6S  +BX -5TI*0T*"0D)"71H<F]W(&YE


M>7!E(&QI;F4 /2!S<RYR96%D3&EN92 I.R O+T)62 T*"0EP<FEN=&8H(B4N
M*G-<;B(L(&QI;F4I.PT*"0D-" D)+R]I9BAS=&0N<W1R:6YG+FEF:6YD*&QI

M95]T(&EW(#T ,#L
M"6EF*"%I8VUP*"(\+VAT;6P^(BP ;&EN95MI=R N+B!L:6YE+FQE;F=T:%TI


`
end

begin 666 htmlget_colon_eq.d
M+RH-" E(5$U,9V5T('=R:71T96X 8GD 0VAR:7-T;W!H97( 12X 36EL;&5R

M:70 9F]R(&%N>2!P=7)P;W-E+ T*"51H:7, 8V]D92!H87, ;F\ =V%R<F%N


M<W1D+G-T<F5A;3L-"FEM<&]R="!S=&0N<V]C:V5T+"!S=&0N<V]C:V5T<W1R

M<RYL96YG=&  /" R*0T*"7L-" D)<')I;G1F*")5<V%G93I<;B  (&AT;6QG

M87)G<ULQ73L ("\O($)62 T*"0T*"6EF*"AI(#H]('-T9"YS=')I;F<N9FEN



M=')I;F<N9FEN9"AU<FPL("<C)RDI("$]("TQ*2 O+R!296UO=F4 86YC:&]R
M(')E9BX ("\O($)62 T*"0EU<FP /2!U<FQ;," N+B!I73L-" D-" EC:&%R
M6UT 9&]M86EN.PT*"6EF*"AI(#H]('-T9"YS=')I;F<N9FEN9"AU<FPL("<O
M)RDI(#T








M?B B(&]N('!O<G0 (B!^('-T9"YS=')I;F<N=&]3=')I;F<H<&]R="D ?B B
M+BXN7&XB*3L-" D-" EA=71O(%-O8VME="!S;V-K(#T ;F5W(%1C<%-O8VME
M="AN97< 26YT97)N971!9&1R97-S*&1O;6%I;BP <&]R="DI.PT*"7-S(#H]
M(&YE=R!3;V-K9713=')E86TH<V]C:RD[(" O+R!"5D -" D-" ED96)U9RA(
M5$U,1T54*0T*"0EP<FEN=&8H(D-O;FYE8W1E9"%<;E)E<75E<W1I;F< 55),

M" D)9&]M86EN(#T 9&]M86EN('X (CHB('X <W1D+G-T<FEN9RYT;U-T<FEN
M9RAP;W)T*3L-" ES<RYW<FET95-T<FEN9R B1T54("( ?B!U<FP ?B B($A4
M5% O,2XQ7')<;B(-" D)(DAO<W0Z("( ?B!D;VUA:6X ?B B7')<;B(-" D)
M(EQR7&XB*3L-" D-" DO+R!3:VEP($A45%  :&5A9&5R+ T*"69O<B [.RD-



M;F4N;&5N9W1H(#X


M5%]465!%7TY!344N;&5N9W1H("XN(&QI;F4N;&5N9W1H73L ("\O($)62 T*
M"0D):68H='EP92YL96YG=&  /#T -2!\?"!I8VUP*")T97AT+R(L('1Y<&5;


M(7-S+F5O9B I*0T*"7L-" D);&EN92 Z/2!S<RYR96%D3&EN92 I.R  +R\ 

M9"YS=')I;F<N:69I;F0H;&EN92P (CPO:'1M;#XB*2 A/2 M,2D-" D)+R\)

M:#L :7<K*RD-" D)>PT*"0D):68H(6EC;7 H(CPO:'1M;#XB+"!L:6YE6VEW


`
end

begin 666 htmlget_cpp.d
M+RH-" E(5$U,9V5T('=R:71T96X 8GD 0VAR:7-T;W!H97( 12X 36EL;&5R

M:70 9F]R(&%N>2!P=7)P;W-E+ T*"51H:7, 8V]D92!H87, ;F\ =V%R<F%N


M<W1D+G-T<F5A;3L-"FEM<&]R="!S=&0N<V]C:V5T+"!S=&0N<V]C:V5T<W1R

M<RYL96YG=&  /" R*0T*"7L-" D)<')I;G1F*")5<V%G93I<;B  (&AT;6QG

M=7)L(#T 87)G<ULQ73L-" EI;G0 :3L-" D-" EI(#T <W1D+G-T<FEN9RYF

M*'5R;%LP("XN(&E=+" B:'1T<"(I*0T*"0D)=&AR;W< ;F5W($5X8V5P=&EO
M;B B:'1T<#HO+R!E>'!E8W1E9"(I.PT*"7T-" D-" EI(#T <W1D+G-T<FEN
M9RYF:6YD*'5R;"P )R,G*3L-" EI9BAI("$]("TQ*2 O+R!296UO=F4 86YC
M:&]R(')E9BX-" D)=7)L(#T

M(#T]("TQ*0T*"7L-" D)9&]M86EN(#T


M"6D /2!S=&0N<W1R:6YG+F9I;F0H9&]M86EN+" G.B<I.PT*"6EF*&D /3T 


M86EN6VD *R Q("XN(&1O;6%I;BYL96YG=&A=*3L-" D)9&]M86EN(#T 9&]M

M9B B0V]N;F5C=&EN9R!T;R B('X 9&]M86EN('X (B!O;B!P;W)T("( ?B!S

M;R!48W!3;V-K970 <V]C:RAN97< 26YT97)N971!9&1R97-S*&1O;6%I;BP 
M<&]R="DI.R O+R!"5D -" E3;V-K9713=')E86T <W,H<V]C:RD[(" O+R!"
M5D -" D-" ED96)U9RA(5$U,1T54*0T*"0EP<FEN=&8H(D-O;FYE8W1E9"%<

M:68H<&]R=" A/2 X,"D-" D)9&]M86EN(#T 9&]M86EN('X (CHB('X <W1D
M+G-T<FEN9RYT;U-T<FEN9RAP;W)T*3L-" ES<RYW<FET95-T<FEN9R B1T54
M("( ?B!U<FP ?B B($A45% O,2XQ7')<;B(-" D)(DAO<W0Z("( ?B!D;VUA
M:6X ?B B7')<;B(-" D)(EQR7&XB*3L-" D-" DO+R!3:VEP($A45%  :&5A






M"0EC:&%R6UT ='EP93L-" D)"71Y<&4 /2!L:6YE6T-/3E1%3E1?5%E015].


M:')O=R!N97< 17AC97!T:6]N*")54DP :7, ;F]T('1E>'0B*3L-" D)?0T*

M"0EL:6YE(#T <W,N<F5A9$QI;F4H*3L-" D)<')I;G1F*"(E+BIS7&XB+"!L

M=&UL/B(I("$]("TQ*0T*"0DO+PEB<F5A:SL-" D)<VEZ95]T(&EW.PT*"0EF
M;W(H:7< /2 P.R!I=R A/2!L:6YE+FQE;F=T:#L :7<K*RD-" D)>PT*"0D)
M:68H(6EC;7 H(CPO:'1M;#XB+"!L:6YE6VEW("XN(&QI;F4N;&5N9W1H72DI


`
end
Sep 08 2005