www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Alternate declaration syntax

reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Ok, Posting to the main forum so it doesn't get lost in the const stuff.

Perhaps a slight variation to the C declaration might be in order, since 
I know that multiple return values are wanted, a simple and readable 
syntax for inheritance is needed (using : as an inheritor does not make 
code more readable) try this out and see if it makes it clearer

<modifiers,...> <identifier> <properties,...> {...}

such that:
const foo(const int, const double) §
     throws barExtension §
     returns const int, const float
{
     // ... code ...
}

same for classes:

const class foo § extends bar {
     const int x;
     pure foo(const int, const double) § returns invariant string;
     // ... more code ...
}

(Note: § is used as a divider because no one uses it for anything in 
programming and I didn't want to start an argument over : or | or ; or 
any other punctuation being used elsewhere and being bad, quite possible 
punctuation wouldn't be neccessary)

It looks like a hideous cross between java and visual basic but it is 
clean, readable, simple to machine parse(I think) and descriptive. using 
slightly longer keywords makes a language a little more verbose, but it 
also makes it readable. if you want to use punctuation for everything 
you get what happened to perl when someone got a little too creative


$!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
Apr 11 2008
next sibling parent reply "Koroskin Denis" <2korden+dmd gmail.com> writes:
On Fri, 11 Apr 2008 21:26:24 +0400, Hans W. Uhlig  =

<huhlig clickconsulting.com> wrote:


 Ok, Posting to the main forum so it doesn't get lost in the const stuf=


f.

 Perhaps a slight variation to the C declaration might be in order, sin=


ce  =


 I know that multiple return values are wanted, a simple and readable  =



 syntax for inheritance is needed (using : as an inheritor does not mak=


e  =


 code more readable) try this out and see if it makes it clearer

 <modifiers,...> <identifier> <properties,...> {...}

 such that:
 const foo(const int, const double) =C2=A7
      throws barExtension =C2=A7
      returns const int, const float
 {
      // ... code ...
 }

 same for classes:

 const class foo =C2=A7 extends bar {
      const int x;
      pure foo(const int, const double) =C2=A7 returns invariant string=


;

      // ... more code ...
 }

 (Note: =C2=A7 is used as a divider because no one uses it for anything=


 in  =


 programming and I didn't want to start an argument over : or | or ; or=


  =


 any other punctuation being used elsewhere and being bad, quite possib=


le  =


 punctuation wouldn't be neccessary)

 It looks like a hideous cross between java and visual basic but it is =


 =


 clean, readable, simple to machine parse(I think) and descriptive. usi=


ng  =


 slightly longer keywords makes a language a little more verbose, but i=


t  =


 also makes it readable. if you want to use punctuation for everything =


 =


 you get what happened to perl when someone got a little too creative




*,$:, %)=3D(

 $!=3D~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=3D++;$.++;$=


.++;




++




=3D`


Yeah, except that I (and many others) don't have that sign on my keyboar=
d  =

<g>
Did you mean $, not =C2=A7? IMO, colon serves the purpose better.

Other than this, I like Jave-style throwable list. I believe it makes DB=
C  =

more powerful.
I would also like to see thread safety attribute as well, but it could b=
e  =

a pain for compiler to verify.
Apr 11 2008
next sibling parent reply "Hans W. Uhlig" <huhlig clickconsulting.com> writes:
Koroskin Denis wrote:

 On Fri, 11 Apr 2008 21:26:24 +0400, Hans W. Uhlig 
 <huhlig clickconsulting.com> wrote:
 

 Ok, Posting to the main forum so it doesn't get lost in the const stuff.

 Perhaps a slight variation to the C declaration might be in order, 
 since I know that multiple return values are wanted, a simple and 
 readable syntax for inheritance is needed (using : as an inheritor 
 does not make code more readable) try this out and see if it makes it 
 clearer

 <modifiers,...> <identifier> <properties,...> {...}

 such that:
 const foo(const int, const double) §
      throws barExtension §
      returns const int, const float
 {
      // ... code ...
 }

 same for classes:

 const class foo § extends bar {
      const int x;
      pure foo(const int, const double) § returns invariant string;
      // ... more code ...
 }

 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite 
 possible punctuation wouldn't be neccessary)

 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. 
 using slightly longer keywords makes a language a little more verbose, 
 but it also makes it readable. if you want to use punctuation for 
 everything you get what happened to perl when someone got a little too 
 creative


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$..++;




 
 
 Yeah, except that I (and many others) don't have that sign on my 
 keyboard <g>
 Did you mean $, not §? IMO, colon serves the purpose better.
 
 Other than this, I like Jave-style throwable list. I believe it makes 
 DBC more powerful.
 I would also like to see thread safety attribute as well, but it could 
 be a pain for compiler to verify.


I used § as a placeholder, I was looking more for the syntax then the 
punctuation I prefer using a : or none at all if possible. I just used § 
to stem off a horrendous debate on the merits and flaws of the colon.
Apr 11 2008
parent reply "Scott S. McCoy" <tag cpan.org> writes:
I see where you're going with this suggestion, but we don't need to
change that much to have multiple return values, either with the
existing syntax, or the syntax I previously suggested. in the last
thread:

public const const(int), const(float) foo (const int foo);

(syntax I suggested)
public const int:const, float:const foo (const int foo);

This is already quite possible, syntactically, with minimal
restructuring of method declarations.

Also, with syntactical additions such as keywords like "throws" or
"returns", the additional punctuation seems unnecessary.

But if you are going to affix a method declaration with multiple
possible types of statements (throws, returns, whatever else) keywords
seem to make more sense than punctuation.

Cheers,
	Scott S. McCoy

On Fri, 2008-04-11 at 11:41 -0700, Hans W. Uhlig wrote:

 Koroskin Denis wrote:

 On Fri, 11 Apr 2008 21:26:24 +0400, Hans W. Uhlig 
 <huhlig clickconsulting.com> wrote:
 

 Ok, Posting to the main forum so it doesn't get lost in the const stuff.

 Perhaps a slight variation to the C declaration might be in order, 
 since I know that multiple return values are wanted, a simple and 
 readable syntax for inheritance is needed (using : as an inheritor 
 does not make code more readable) try this out and see if it makes it 
 clearer

 <modifiers,...> <identifier> <properties,...> {...}

 such that:
 const foo(const int, const double) §
      throws barExtension §
      returns const int, const float
 {
      // ... code ...
 }

 same for classes:

 const class foo § extends bar {
      const int x;
      pure foo(const int, const double) § returns invariant string;
      // ... more code ...
 }

 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite 
 possible punctuation wouldn't be neccessary)

 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. 
 using slightly longer keywords makes a language a little more verbose, 
 but it also makes it readable. if you want to use punctuation for 
 everything you get what happened to perl when someone got a little too 
 creative


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$..++;




 
 
 Yeah, except that I (and many others) don't have that sign on my 
 keyboard <g>
 Did you mean $, not §? IMO, colon serves the purpose better.
 
 Other than this, I like Jave-style throwable list. I believe it makes 
 DBC more powerful.
 I would also like to see thread safety attribute as well, but it could 
 be a pain for compiler to verify.


 
 I used § as a placeholder, I was looking more for the syntax then the 
 punctuation I prefer using a : or none at all if possible. I just used § 
 to stem off a horrendous debate on the merits and flaws of the colon.
Apr 11 2008
parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Scott S. McCoy wrote:

 I see where you're going with this suggestion, but we don't need to
 change that much to have multiple return values, either with the
 existing syntax, or the syntax I previously suggested. in the last
 thread:
 
 public const const(int), const(float) foo (const int foo);
 
 (syntax I suggested)
 public const int:const, float:const foo (const int foo);
 
 This is already quite possible, syntactically, with minimal
 restructuring of method declarations.
 
 Also, with syntactical additions such as keywords like "throws" or
 "returns", the additional punctuation seems unnecessary.
 
 But if you are going to affix a method declaration with multiple
 possible types of statements (throws, returns, whatever else) keywords
 seem to make more sense than punctuation.
 
 Cheers,
 	Scott S. McCoy
 
 On Fri, 2008-04-11 at 11:41 -0700, Hans W. Uhlig wrote:

 Koroskin Denis wrote:

 On Fri, 11 Apr 2008 21:26:24 +0400, Hans W. Uhlig 
 <huhlig clickconsulting.com> wrote:


 Ok, Posting to the main forum so it doesn't get lost in the const stuff.

 Perhaps a slight variation to the C declaration might be in order, 
 since I know that multiple return values are wanted, a simple and 
 readable syntax for inheritance is needed (using : as an inheritor 
 does not make code more readable) try this out and see if it makes it 
 clearer

 <modifiers,...> <identifier> <properties,...> {...}

 such that:
 const foo(const int, const double) §
      throws barExtension §
      returns const int, const float
 {
      // ... code ...
 }

 same for classes:

 const class foo § extends bar {
      const int x;
      pure foo(const int, const double) § returns invariant string;
      // ... more code ...
 }

 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite 
 possible punctuation wouldn't be neccessary)

 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. 
 using slightly longer keywords makes a language a little more verbose, 
 but it also makes it readable. if you want to use punctuation for 
 everything you get what happened to perl when someone got a little too 
 creative


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$..++;




 Yeah, except that I (and many others) don't have that sign on my 
 keyboard <g>
 Did you mean $, not §? IMO, colon serves the purpose better.

 Other than this, I like Jave-style throwable list. I believe it makes 
 DBC more powerful.
 I would also like to see thread safety attribute as well, but it could 
 be a pain for compiler to verify.


 I used § as a placeholder, I was looking more for the syntax then the 
 punctuation I prefer using a : or none at all if possible. I just used § 
 to stem off a horrendous debate on the merits and flaws of the colon.


 


I agree. The syntax I suppose was to make it look more distinct from 
other methods. I dont like tacking on const to the begining of 
everything because when developing const functions returning touples you 
end up with 4 or 5 consts and it gets really confusing. I agree the 
simple keywords would be best as this eliminates all of the ambiguity in 
the syntax and also makes it alot easier to read.
Apr 12 2008
parent reply "Koroskin Denis" <2korden gmail.com> writes:
Talking about multiple return values, I'd like to see the following synt=
ax:

// both types are 'int's (just for simplicity)
[int, int] someFunction()
{
     return [1, 2];
}

instead of, for example,

Tuple!(int,int) somFunction()
{
     return Tuple!(int,int) {1, 2};
}

In fact, Tuple!(int,int) isn't that different from int[2].
They share 'length' property, and I like result[0] more than result._0,
'cause it's simpler, more intuitive and behaves just like built-in type:=


auto result =3D someFunction();

auto len =3D result.length; // compile-time evalualable
auto r0 =3D result[0];      // types can be easily deduced
auto r1 =3D result[1];
auto r2 =3D result[2];      // fails to compile, out of bounds.

Whaddya think? :)
Apr 12 2008
parent reply Yigal Chripun <yigal100 gmail.com> writes:
Koroskin Denis wrote:

 Talking about multiple return values, I'd like to see the following
 syntax:

 // both types are 'int's (just for simplicity)
 [int, int] someFunction()
 {
     return [1, 2];
 }

 instead of, for example,

 Tuple!(int,int) somFunction()
 {
     return Tuple!(int,int) {1, 2};
 }

 In fact, Tuple!(int,int) isn't that different from int[2].
 They share 'length' property, and I like result[0] more than result._0,
 'cause it's simpler, more intuitive and behaves just like built-in type:

 auto result = someFunction();

 auto len = result.length; // compile-time evalualable
 auto r0 = result[0];      // types can be easily deduced
 auto r1 = result[1];
 auto r2 = result[2];      // fails to compile, out of bounds.

 Whaddya think? :)


I like the basic idea, although I would prefer a different operator than [].
basically, my only issue is that when i see res[i] I would assume that
res is an array.

Tuples have much more in common with structs than with arrays, and as
such, I would prefer:

{int, double} someFunction()
{
    return {1, 2.5};
}

and:

auto result = someFunction();

auto len = result.length; // compile-time evalualable
auto r0 = result{0};      // types can be easily deduced
auto r1 = result{0,1};  // define a new tuple with a subset of result's
values

or:

result.at(0);

or even something similar to ML's:
r1 = $1(result) ; // second item in tuple

-- Yigal
Apr 12 2008
parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Yigal Chripun wrote:

 Koroskin Denis wrote:

 Talking about multiple return values, I'd like to see the following
 syntax:

 // both types are 'int's (just for simplicity)
 [int, int] someFunction()
 {
     return [1, 2];
 }

 instead of, for example,

 Tuple!(int,int) somFunction()
 {
     return Tuple!(int,int) {1, 2};
 }

 In fact, Tuple!(int,int) isn't that different from int[2].
 They share 'length' property, and I like result[0] more than result._0,
 'cause it's simpler, more intuitive and behaves just like built-in type:

 auto result = someFunction();

 auto len = result.length; // compile-time evalualable
 auto r0 = result[0];      // types can be easily deduced
 auto r1 = result[1];
 auto r2 = result[2];      // fails to compile, out of bounds.

 Whaddya think? :)


 I like the basic idea, although I would prefer a different operator than [].
 basically, my only issue is that when i see res[i] I would assume that
 res is an array.
 
 Tuples have much more in common with structs than with arrays, and as
 such, I would prefer:
 
 {int, double} someFunction()
 {
     return {1, 2.5};
 }
 
 and:
 
 auto result = someFunction();
 
 auto len = result.length; // compile-time evalualable
 auto r0 = result{0};      // types can be easily deduced
 auto r1 = result{0,1};  // define a new tuple with a subset of result's
 values
 
 or:
 
 result.at(0);
 
 or even something similar to ML's:
 r1 = $1(result) ; // second item in tuple
 
 -- Yigal
 


In this I must agree, using

	return {1,"string",objectref}; is far cleaner then eigther prior 
reference.
Apr 12 2008
parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Hans W. Uhlig wrote:

 Yigal Chripun wrote:

 Koroskin Denis wrote:

 Talking about multiple return values, I'd like to see the following
 syntax:

 // both types are 'int's (just for simplicity)
 [int, int] someFunction()
 {
     return [1, 2];
 }

 instead of, for example,

 Tuple!(int,int) somFunction()
 {
     return Tuple!(int,int) {1, 2};
 }

 In fact, Tuple!(int,int) isn't that different from int[2].
 They share 'length' property, and I like result[0] more than result._0,
 'cause it's simpler, more intuitive and behaves just like built-in type:

 auto result = someFunction();

 auto len = result.length; // compile-time evalualable
 auto r0 = result[0];      // types can be easily deduced
 auto r1 = result[1];
 auto r2 = result[2];      // fails to compile, out of bounds.

 Whaddya think? :)


 I like the basic idea, although I would prefer a different operator 
 than [].
 basically, my only issue is that when i see res[i] I would assume that
 res is an array.

 Tuples have much more in common with structs than with arrays, and as
 such, I would prefer:

 {int, double} someFunction()
 {
     return {1, 2.5};
 }

 and:

 auto result = someFunction();

 auto len = result.length; // compile-time evalualable
 auto r0 = result{0};      // types can be easily deduced
 auto r1 = result{0,1};  // define a new tuple with a subset of result's
 values

 or:

 result.at(0);

 or even something similar to ML's:
 r1 = $1(result) ; // second item in tuple

 -- Yigal


 In this I must agree, using
 
     return {1,"string",objectref}; is far cleaner then eigther prior 
 reference.


I would think something similar to perl would work

{var1, var2, var3} = blah(1,2,3);
{int var1, string var2, object var3} = blah(1,2,3);

const blah(int a, int b, int c) returns const int, invariant string, 
object {
	return 1, "hello", this;
}
Apr 12 2008
parent reply Georg Wrede <georg nospam.org> writes:
Hans W. Uhlig wrote:

 Hans W. Uhlig wrote:
 

 Yigal Chripun wrote:


 Koroskin Denis wrote:


 Talking about multiple return values, I'd like to see the following
 syntax:

 // both types are 'int's (just for simplicity)
 [int, int] someFunction()
 {
     return [1, 2];
 }

 instead of, for example,

 Tuple!(int,int) somFunction()
 {
     return Tuple!(int,int) {1, 2};
 }

 In fact, Tuple!(int,int) isn't that different from int[2].
 They share 'length' property, and I like result[0] more than result._0,
 'cause it's simpler, more intuitive and behaves just like built-in 
 type:

 auto result = someFunction();

 auto len = result.length; // compile-time evalualable
 auto r0 = result[0];      // types can be easily deduced
 auto r1 = result[1];
 auto r2 = result[2];      // fails to compile, out of bounds.

 Whaddya think? :)


 I like the basic idea, although I would prefer a different operator 
 than [].
 basically, my only issue is that when i see res[i] I would assume that
 res is an array.

 Tuples have much more in common with structs than with arrays, and as
 such, I would prefer:

 {int, double} someFunction()
 {
     return {1, 2.5};
 }

 and:

 auto result = someFunction();

 auto len = result.length; // compile-time evalualable
 auto r0 = result{0};      // types can be easily deduced
 auto r1 = result{0,1};  // define a new tuple with a subset of result's
 values

 or:

 result.at(0);

 or even something similar to ML's:
 r1 = $1(result) ; // second item in tuple

 -- Yigal


 In this I must agree, using

     return {1,"string",objectref}; is far cleaner then eigther prior 
 reference.


 
 I would think something similar to perl would work
 
 {var1, var2, var3} = blah(1,2,3);
 {int var1, string var2, object var3} = blah(1,2,3);
 
 const blah(int a, int b, int c) returns const int, invariant string, 
 object {
     return 1, "hello", this;
 }


Well, at first sight, this looks nice.
Apr 13 2008
parent reply "Koroskin Denis" <2korden gmail.com> writes:
On Sun, 13 Apr 2008 12:07:11 +0400, Georg Wrede <georg nospam.org> wrote=
:

 Hans W. Uhlig wrote:

  I would think something similar to perl would work
  {var1, var2, var3} =3D blah(1,2,3);
 {int var1, string var2, object var3} =3D blah(1,2,3);
  const blah(int a, int b, int c) returns const int, invariant string,=




  =


 object {
     return 1, "hello", this;
 }


 Well, at first sight, this looks nice.


Doesn't look nice to me. Look at this:

auto t =3D 1, "hello", this;

What it the t.typeof? Do you think it's {int, string, this.typeof}?
No, it's just this.typeof, because comma is a statement separator in thi=
s  =

context.
Moreover, I don't think this is consistent:

int i;
string s;
this.typeof t;

{i, s, t} =3D 1, "hello", this;

Compare to:
{i, s, t} =3D {1, "hello, "this};

or to:
[i, s, t] =3D [1, "hello", this];

Anyway, I don't like {} syntax much. I believe, in D it denotes scopes.
Even array initialization moved from C style {1, 2, 3} to D style [1, 2,=
  =

3].

To me, tuples aren't different from arrays. And I would like to operate =
on  =

them like on arrays:

auto t =3D [1, "hello", this];
auto s =3D t[0..1]; // s =3D=3D {1, "hello" }. t{0..1} looks like an ugl=
y  =

language hack to me.

Or like this:

{int, int, string} k =3D [1, 2, "3"];
k[0..1] =3D [1, 1];   // here it is. What is the type of [1, 1]? I don't=
  =

care!
int[2] i =3D k[0..1]; // Arrays should be convertible to tuples and  =

vice-versa
Apr 13 2008
next sibling parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Koroskin Denis wrote:

 On Sun, 13 Apr 2008 12:07:11 +0400, Georg Wrede <georg nospam.org> wrote:

 Hans W. Uhlig wrote:

  I would think something similar to perl would work
  {var1, var2, var3} = blah(1,2,3);
 {int var1, string var2, object var3} = blah(1,2,3);
  const blah(int a, int b, int c) returns const int, invariant string, 
 object {
     return 1, "hello", this;
 }


 Well, at first sight, this looks nice.


 
 Doesn't look nice to me. Look at this:
 
 auto t = 1, "hello", this;
 
 What it the t.typeof? Do you think it's {int, string, this.typeof}?
 No, it's just this.typeof, because comma is a statement separator in 
 this context.
 Moreover, I don't think this is consistent:
 
 int i;
 string s;
 this.typeof t;
 
 {i, s, t} = 1, "hello", this;
 
 Compare to:
 {i, s, t} = {1, "hello, "this};
 
 or to:
 [i, s, t] = [1, "hello", this];
 
 Anyway, I don't like {} syntax much. I believe, in D it denotes scopes.
 Even array initialization moved from C style {1, 2, 3} to D style [1, 2, 
 3].
 
 To me, tuples aren't different from arrays. And I would like to operate 
 on them like on arrays:
 
 auto t = [1, "hello", this];
 auto s = t[0..1]; // s == {1, "hello" }. t{0..1} looks like an ugly 
 language hack to me.
 
 Or like this:
 
 {int, int, string} k = [1, 2, "3"];
 k[0..1] = [1, 1];   // here it is. What is the type of [1, 1]? I don't 
 care!
 int[2] i = k[0..1]; // Arrays should be convertible to tuples and 
 vice-versa


[] would fit the paradime anyhow. Perl actually uses (x,y,z) = (a,b,c); 
so using [a,b,c] I thin k would work fine. As for initialization inside 
a "touple bracket" I think it should be eigther allowed only with auto 
(at which point the compiler should effectively treat each variable as a 
seperate statement, i.E.

(auto i, j, k) = blah();
auto i = blah()[0];
j = blah()[1];
k = blah()[2];


since as I understand it, a touple is effectively an anonymous array

return a,b,c; becomes

void * touplereturn[] = [&a, &b, &c];
return touplereturn;

at which point you simply retreive the resulting array and process

perhaps this is where some native(rather then library) array 
handling/dereferencing might be appropriate.

when using standard vs touple syntax, if Walter wants to avoid the 
suggested syntax as being too pascal like

touple foobar(int a, int b, int c) returns int, double, string {}

such that touple is an array reference containing references, and the 
compiler then looks to the property returns for the return types. 
However, at least in my mind this is a horrendous cluge but still 
providdes the neccessary type checking and compiler enforcement.

while I think this is a hack and leads to more confusion it would 
provide a bit more readability then otherwise would be gained.

so, in short, my vote for the declaration statement moves to the end of 
the line

function <identifier>(<<parameter modifier, ...> parameter, ...>) 
returns <<return modifier> return type, ...> { // block

	returns [x,y,z]; or returns x,y,z;
	returns [x]; or returns x;
}

[x,y,z] = foo();
[auto x, auto y, z] = foo();

comments?
Apr 13 2008
parent "Scott S. McCoy" <tag cpan.org> writes:
On Sun, 2008-04-13 at 10:40 -0700, Hans W. Uhlig wrote:

 Koroskin Denis wrote:

 On Sun, 13 Apr 2008 12:07:11 +0400, Georg Wrede <georg nospam.org> wrote:

 Hans W. Uhlig wrote:

  I would think something similar to perl would work
  {var1, var2, var3} = blah(1,2,3);
 {int var1, string var2, object var3} = blah(1,2,3);
  const blah(int a, int b, int c) returns const int, invariant string, 
 object {
     return 1, "hello", this;
 }


 Well, at first sight, this looks nice.


 
 Doesn't look nice to me. Look at this:
 
 auto t = 1, "hello", this;
 
 What it the t.typeof? Do you think it's {int, string, this.typeof}?
 No, it's just this.typeof, because comma is a statement separator in 
 this context.
 Moreover, I don't think this is consistent:
 
 int i;
 string s;
 this.typeof t;
 
 {i, s, t} = 1, "hello", this;
 
 Compare to:
 {i, s, t} = {1, "hello, "this};
 
 or to:
 [i, s, t] = [1, "hello", this];
 
 Anyway, I don't like {} syntax much. I believe, in D it denotes scopes.
 Even array initialization moved from C style {1, 2, 3} to D style [1, 2, 
 3].
 
 To me, tuples aren't different from arrays. And I would like to operate 
 on them like on arrays:
 
 auto t = [1, "hello", this];
 auto s = t[0..1]; // s == {1, "hello" }. t{0..1} looks like an ugly 
 language hack to me.
 
 Or like this:
 
 {int, int, string} k = [1, 2, "3"];
 k[0..1] = [1, 1];   // here it is. What is the type of [1, 1]? I don't 
 care!
 int[2] i = k[0..1]; // Arrays should be convertible to tuples and 
 vice-versa


 [] would fit the paradime anyhow. Perl actually uses (x,y,z) = (a,b,c); 
 so using [a,b,c] I thin k would work fine. As for initialization inside 
 a "touple bracket" I think it should be eigther allowed only with auto 
 (at which point the compiler should effectively treat each variable as a 
 seperate statement, i.E.
 
 (auto i, j, k) = blah();
 auto i = blah()[0];
 j = blah()[1];
 k = blah()[2];
 
 
 since as I understand it, a touple is effectively an anonymous array
 
 return a,b,c; becomes



You realize this is functionally defunct for the purposes of type
inference?  Just thought I'd run that by you.  What we would need, for
list context, is the same type of return type-checking we currently
have, but with multiple values.


 
 void * touplereturn[] = [&a, &b, &c];
 return touplereturn;
 
 at which point you simply retreive the resulting array and process
 
 perhaps this is where some native(rather then library) array 
 handling/dereferencing might be appropriate.
 
 when using standard vs touple syntax, if Walter wants to avoid the 
 suggested syntax as being too pascal like
 
 touple foobar(int a, int b, int c) returns int, double, string {}
 
 such that touple is an array reference containing references, and the 
 compiler then looks to the property returns for the return types. 
 However, at least in my mind this is a horrendous cluge but still 
 providdes the neccessary type checking and compiler enforcement.
 
 while I think this is a hack and leads to more confusion it would 
 provide a bit more readability then otherwise would be gained.
 
 so, in short, my vote for the declaration statement moves to the end of 
 the line
 
 function <identifier>(<<parameter modifier, ...> parameter, ...>) 
 returns <<return modifier> return type, ...> { // block
 
 	returns [x,y,z]; or returns x,y,z;
 	returns [x]; or returns x;
 }
 
 [x,y,z] = foo();
 [auto x, auto y, z] = foo();
 
 comments?
Apr 13 2008
prev sibling parent Yigal Chripun <yigal100 gmail.com> writes:
I wholeheartedly disagree with your post. remember, D is a compiled
language with a type system, it's not javascript.
your view of tuples adds ambiguities for both humans and compilers:
you state that tuples should be convertible to arrays and vice-versa:
int[2] = {11, "hello"} // that is a compiler error.
[int, string] = [ 1, 1]; //and so is this
tuples are implemented as anonymous _structs_ not arrays and should be
treated as such.

regarding syntax:
return 1, "hello", this;  // this should not be a tuple.

IMO, tuples must be denoted as such by either {int, string} (for
example) or if you really dislike it, than replace it with (int, string)
which is good as well. the main benefit is that I know that (a,b) is a
tuple and [a,b] is an array.
You know that often occurring bug in C/C++ where:
double res = 5 / 2; // this equals 2 and _not_ 2.5 as you (or a newbie)
would expect
well, the ambiguities of tuples versus arrays would bring the same type
of bugs if you have them both use the same syntax.

for a function to return a tuple i would suggest with the current syntax
(and parens, I've just decided I prefer them...):
pure invariant (invariant int, string) func (invariant int a, invariant
int b);
or with return values at the end, which i prefer:
// if you prefer keywords, replace colon with "returns"
pure invariant func (invariant int a, invariant int b) : (invariant int,
string);

-- Yigal

Koroskin Denis wrote:

 On Sun, 13 Apr 2008 12:07:11 +0400, Georg Wrede <georg nospam.org> wrote:

 Hans W. Uhlig wrote:

  I would think something similar to perl would work
  {var1, var2, var3} = blah(1,2,3);
 {int var1, string var2, object var3} = blah(1,2,3);
  const blah(int a, int b, int c) returns const int, invariant
 string, object {
     return 1, "hello", this;
 }


 Well, at first sight, this looks nice.


 Doesn't look nice to me. Look at this:

 auto t = 1, "hello", this;

 What it the t.typeof? Do you think it's {int, string, this.typeof}?
 No, it's just this.typeof, because comma is a statement separator in
 this context.
 Moreover, I don't think this is consistent:

 int i;
 string s;
 this.typeof t;

 {i, s, t} = 1, "hello", this;

 Compare to:
 {i, s, t} = {1, "hello, "this};

 or to:
 [i, s, t] = [1, "hello", this];

 Anyway, I don't like {} syntax much. I believe, in D it denotes scopes.
 Even array initialization moved from C style {1, 2, 3} to D style [1,
 2, 3].

 To me, tuples aren't different from arrays. And I would like to
 operate on them like on arrays:

 auto t = [1, "hello", this];
 auto s = t[0..1]; // s == {1, "hello" }. t{0..1} looks like an ugly
 language hack to me.

 Or like this:

 {int, int, string} k = [1, 2, "3"];
 k[0..1] = [1, 1];   // here it is. What is the type of [1, 1]? I don't
 care!
 int[2] i = k[0..1]; // Arrays should be convertible to tuples and
 vice-versa
Apr 13 2008
prev sibling parent "Scott S. McCoy" <tag cpan.org> writes:
On Fri, 2008-04-11 at 22:26 +0400, Koroskin Denis wrote:

 
 Other than this, I like Jave-style throwable list. I believe it makes
 DBC  
 more powerful.


I agree.  "throws" lists are nice.  I've played with the idea of
suggesting this in the news group, after having discussed it on IRC, and
have figured it's a hot enough ticket item (with, honestly, maybe not
the most obvious ROI) that I might just leave well enough alone.

But since it's been brought up, I might like to add that while I *do*
like the ability to explicitly list exception types, and have the
compiler enforce atleast *something* is done about it, I dislike the
idea of the magical point in the inheritance tree where an exception
becomes "checked" (in java's definition), and would never suggest that
to another language.  Having to wrap what should probably be a simply
unhandled exception into a runtime exception so one can avoid handling,
it, is just plain silly.

So the suggestion I would make, if I were inclined to do so, would be
that exceptions become checked when and only when they are explicitly
listed in a throws clause.  However; I'll omit from actually making this
suggestion, because of the fact that D has multiple error handling paths
(scope, for instance) and that trying to leverage compile-time checking
into these multiple paths is more complex than I'd like to get into for
what we get out of it.

Cheers,
    Scott S. McCoy
Apr 11 2008
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
A complete proposal must discuss delegate declaration and instantiation too...
You should discuss in, out, and, ref too. I'd also avoid non-D concepts in your
examples... 

Hans W. Uhlig Wrote:


 Ok, Posting to the main forum so it doesn't get lost in the const stuff.
 
 Perhaps a slight variation to the C declaration might be in order, since 
 I know that multiple return values are wanted, a simple and readable 
 syntax for inheritance is needed (using : as an inheritor does not make 
 code more readable) try this out and see if it makes it clearer
 
 <modifiers,...> <identifier> <properties,...> {...}
 
 such that:
 const foo(const int, const double) §
      throws barExtension §
      returns const int, const float
 {
      // ... code ...
 }
 
 same for classes:
 
 const class foo § extends bar {
      const int x;
      pure foo(const int, const double) § returns invariant string;
      // ... more code ...
 }
 
 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite possible 
 punctuation wouldn't be neccessary)
 
 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. using 
 slightly longer keywords makes a language a little more verbose, but it 
 also makes it readable. if you want to use punctuation for everything 
 you get what happened to perl when someone got a little too creative
 

 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;
Apr 11 2008
parent "Hans W. Uhlig" <huhlig gmail.com> writes:
Jason House wrote:

 A complete proposal must discuss delegate declaration and instantiation too...
You should discuss in, out, and, ref too. I'd also avoid non-D concepts in your
examples... 
 
 Hans W. Uhlig Wrote:
 

 Ok, Posting to the main forum so it doesn't get lost in the const stuff.

 Perhaps a slight variation to the C declaration might be in order, since 
 I know that multiple return values are wanted, a simple and readable 
 syntax for inheritance is needed (using : as an inheritor does not make 
 code more readable) try this out and see if it makes it clearer

 <modifiers,...> <identifier> <properties,...> {...}

 such that:
 const foo(const int, const double) §
      throws barExtension §
      returns const int, const float
 {
      // ... code ...
 }

 same for classes:

 const class foo § extends bar {
      const int x;
      pure foo(const int, const double) § returns invariant string;
      // ... more code ...
 }

 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite possible 
 punctuation wouldn't be neccessary)

 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. using 
 slightly longer keywords makes a language a little more verbose, but it 
 also makes it readable. if you want to use punctuation for everything 
 you get what happened to perl when someone got a little too creative


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;




 


I will see about drafting up a proposal on saturday.
Apr 12 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Hans W. Uhlig wrote:


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;




I'm too scared to run that... is it a JAPH or something even more awesome?
Apr 11 2008
parent Jarrod <qwerty ytre.wq> writes:
On Fri, 11 Apr 2008 15:13:13 -0700, Robert Fraser wrote:


 Hans W. Uhlig wrote:


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;




 
 I'm too scared to run that... is it a JAPH or something even more
 awesome?


It's a japh.
Apr 11 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Hans W. Uhlig wrote:

 Ok, Posting to the main forum so it doesn't get lost in the const stuff.
 
 Perhaps a slight variation to the C declaration might be in order, since 
 I know that multiple return values are wanted, a simple and readable 
 syntax for inheritance is needed (using : as an inheritor does not make 
 code more readable) try this out and see if it makes it clearer
 
 <modifiers,...> <identifier> <properties,...> {...}
 
 such that:
 const foo(const int, const double) §
     throws barExtension §
     returns const int, const float
 {
     // ... code ...
 }
 
 same for classes:
 
 const class foo § extends bar {
     const int x;
     pure foo(const int, const double) § returns invariant string;
     // ... more code ...
 }
 
 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite possible 
 punctuation wouldn't be neccessary)
 
 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. using 
 slightly longer keywords makes a language a little more verbose, but it 
 also makes it readable. if you want to use punctuation for everything 
 you get what happened to perl when someone got a little too creative
 

 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;




As for the post itself, I agree the return type should be at the end, 
but good luck convincing Walter of such. Also, D has no exception 
specifications ("throws" clauses) - nor do many other languages besides 
Java (it's considered something of a failed experiment...).

My suggestion for the syntax is to indeed use the colon but not a 
"returns" keyword since that's a lot of typing. If I were designing a 
language, it would look like:

const foo(int x, int y, int z) : int
{
}

Grammatically:

<modifiers> <identifier> "(" <parameters> ")" ":" <return type> "{" 
<statements> "}"
Apr 11 2008
parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Robert Fraser wrote:

 Hans W. Uhlig wrote:

 Ok, Posting to the main forum so it doesn't get lost in the const stuff.

 Perhaps a slight variation to the C declaration might be in order, 
 since I know that multiple return values are wanted, a simple and 
 readable syntax for inheritance is needed (using : as an inheritor 
 does not make code more readable) try this out and see if it makes it 
 clearer

 <modifiers,...> <identifier> <properties,...> {...}

 such that:
 const foo(const int, const double) §
     throws barExtension §
     returns const int, const float
 {
     // ... code ...
 }

 same for classes:

 const class foo § extends bar {
     const int x;
     pure foo(const int, const double) § returns invariant string;
     // ... more code ...
 }

 (Note: § is used as a divider because no one uses it for anything in 
 programming and I didn't want to start an argument over : or | or ; or 
 any other punctuation being used elsewhere and being bad, quite 
 possible punctuation wouldn't be neccessary)

 It looks like a hideous cross between java and visual basic but it is 
 clean, readable, simple to machine parse(I think) and descriptive. 
 using slightly longer keywords makes a language a little more verbose, 
 but it also makes it readable. if you want to use punctuation for 
 everything you get what happened to perl when someone got a little too 
 creative


 $!=~/(.)(.).(.)(.)(.)(.)..(.)(.)(.)..(.)......(.)/,$"),$=++;$.++;$.++;




 
 As for the post itself, I agree the return type should be at the end, 
 but good luck convincing Walter of such. Also, D has no exception 
 specifications ("throws" clauses) - nor do many other languages besides 
 Java (it's considered something of a failed experiment...).
 
 My suggestion for the syntax is to indeed use the colon but not a 
 "returns" keyword since that's a lot of typing. If I were designing a 
 language, it would look like:
 
 const foo(int x, int y, int z) : int
 {
 }
 
 Grammatically:
 
 <modifiers> <identifier> "(" <parameters> ")" ":" <return type> "{" 
 <statements> "}"


Ok, I have to ask the stupid question, what are peoples problem with 
typing. Programmers should not be so lazy as to be unable to type 7 
characters. the throws was also an example of how this could be used to 
apply a clean syntax to other properties that need to be defined, 
extends for inheritance, etc. In a system like this, major additions to 
the function declaration can be made rather easily, and it produces 
easier to read code. Nice thing about it is, D could support both for a 
while and I dont think it would be too hard to implement parser wise.
Apr 12 2008
parent reply boyd <gaboonviper gmx.net> writes:
Okay, so I've been working with D for a while now. I stumbled upon it when  
I was searching for a better language for me to use.

Other languages always seemed to lack some crucial feature. D is generally  
easy to use, easy to read and has all the options I wanted. I also love  
the attention it has given to little details that just make things so much  
easier.

It's not perfect by any means, but overal it's better than anything. I  
currently have gripes with mixins, which are a pain to use. From what I  
hear Macros are gong to replace them, so for now I'll avoid that subject.


Instead I've been wondering about a problem that, to my knowledge, hasn't  
gotten any attention yet: function declaration keyword.

One thing I never really liked about C++ is the way function declarations  
look. You can't easily differentiate them from variable declarations.  
Maybe it's partly because I started with Object Pascal rather than C++,  
but I never got used to it.

Anyway, why not use a keyword for function declarations?

   function void DoSomething(int someParam);

Here it's easier to figure out what it is than:

   void DoSomething(int someParam);

It also solves some storage class problems like:

   const int DoSomething(int someParam);

Is the function const? or is the return value const? With the current  
const system we know this means the return value is const, but it isn't  
obvious to anyone who doesn't know this.

   function const int DoSomething(int someParam);

This is much more natural and it has the advantage that storage classes  
meant for the function aren't confusing.

   static int DoSomething(int someParam);

does this return a static integer variable? We know it's not possible, but  
at first glance that might be what you see. Using the function keyword  
however, there is no such problem:

   static function int DoSomething(int someParam);

It also removes the need to have storage classes like pure and const at  
the end of the function.

   int DoSomething(int someParam) pure;

vs

   pure function int DoSomething(int someParam);

Starting function declarations with a keyword may seem like a small  
detail, but I think it can improve the expressiveness of D a lot.

Anyway, what do you guys think?

Cheers,
Boyd
Apr 12 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it 
 when I was searching for a better language for me to use.

 Other languages always seemed to lack some crucial feature. D is 
 generally easy to use, easy to read and has all the options I wanted. I 
 also love the attention it has given to little details that just make 
 things so much easier.
 
 It's not perfect by any means, but overal it's better than anything. I 
 currently have gripes with mixins, which are a pain to use. From what I 
 hear Macros are gong to replace them, so for now I'll avoid that subject.


Heartily agree with you there.  For all the complaining I do here, I 
still keep using D, because I really haven't found anything better.


 
 
 Instead I've been wondering about a problem that, to my knowledge, 
 hasn't gotten any attention yet: function declaration keyword.
 
 One thing I never really liked about C++ is the way function 
 declarations look. You can't easily differentiate them from variable 
 declarations. Maybe it's partly because I started with Object Pascal 
 rather than C++, but I never got used to it.
 
 Anyway, why not use a keyword for function declarations?
 
   function void DoSomething(int someParam);


I just hope I don't ever have to type this in D:

   protected override invariant pure function invariant(double)[] 
func(invariant (double)[]) {...}

Scarily, it's looking like that's probably going to be quite a 
reasonable signature for a D2 pure method to have.  (Except for the 
'function' part from your suggestion).

For whatever else, K&R knew the value of keeping common keywords short, 
even if it meant using abbreviations.  That's why we have
- int not integer
- char not character
- const not constant
- enum not enumeration
- float not floating_point
and later, thanks to Stroustrup, I guess:
- bool not boolean


So anyway, if it is going to become required on every function, let's at 
least make it something shorter than 'function'.

I think the chances of it happening are slim and none, though.  Unless 
you can come up with some more compelling reasons for it.  Heck we can't 
even get Walter to remove 'printf' from Object.d.

--bb
Apr 12 2008
next sibling parent reply boyd <gaboonviper gmx.net> writes:
 So anyway, if it is going to become required on every function, let's at  
 least make it something shorter than 'function'.


I personally prefer the keyword 'function', it's not that long and it's  
clear. Shorter is okay as long as it doesn't decrease readability. I'm  
wary of using 'func', as it could also indicate functor. I have no Idea  
what a functor is but i've seen it used around here several times. Anyway,  
are those 8 characters really such a pain to write?

Regardless of what keyword will be used, the main reason for using a  
keyword in the first place is readability. Not just for the user, but also  
for the parser. I'm not an expert on parsing, but I'm pretty sure this  
keyword could help identifying functions more easily.

Plus there won't be any need for those special case storage classes like  
'pure' and 'const' to be written at the end of the function, decreasing  
the overal complexity of the D Language. Decreasing complexity of the  
basic features becomes more and more important when more features are  
added to D.


 I think the chances of it happening are slim and none, though.  Unless  
 you can come up with some more compelling reasons for it.  Heck we can't  
 even get Walter to remove 'printf' from Object.d.


Having a keyword for function declarations is a completely different  
matter from removing one lousy function in the standard library.

The chances of this feature from happening depends on whether this  
proposal appeals to the ideas of the designers of D, and partly on what  
the D community thinks of it. So, there's really no telling what kinds of  
odds we're dealing with here.


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]  
 func(invariant (double)[]) {...}


This function would be even better if the implementation was: { return  
_myArray; } :P
Seriously, I don't think the function declaration keyword really affects  
this problem.

Anyway, thanks for the feedback.

Cheers,
Boyd



--------
On Sat, 12 Apr 2008 14:16:29 +0200, Bill Baxter  
<dnewsgroup billbaxter.com> wrote:


 boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it  
 when I was searching for a better language for me to use.


  >

 Other languages always seemed to lack some crucial feature. D is  
 generally easy to use, easy to read and has all the options I wanted. I  
 also love the attention it has given to little details that just make  
 things so much easier.
  It's not perfect by any means, but overal it's better than anything. I  
 currently have gripes with mixins, which are a pain to use. From what I  
 hear Macros are gong to replace them, so for now I'll avoid that  
 subject.


 Heartily agree with you there.  For all the complaining I do here, I  
 still keep using D, because I really haven't found anything better.


   Instead I've been wondering about a problem that, to my knowledge,  
 hasn't gotten any attention yet: function declaration keyword.
  One thing I never really liked about C++ is the way function  
 declarations look. You can't easily differentiate them from variable  
 declarations. Maybe it's partly because I started with Object Pascal  
 rather than C++, but I never got used to it.
  Anyway, why not use a keyword for function declarations?
    function void DoSomething(int someParam);


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]  
 func(invariant (double)[]) {...}

 Scarily, it's looking like that's probably going to be quite a  
 reasonable signature for a D2 pure method to have.  (Except for the  
 'function' part from your suggestion).

 For whatever else, K&R knew the value of keeping common keywords short,  
 even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean


 So anyway, if it is going to become required on every function, let's at  
 least make it something shorter than 'function'.

 I think the chances of it happening are slim and none, though.  Unless  
 you can come up with some more compelling reasons for it.  Heck we can't  
 even get Walter to remove 'printf' from Object.d.

 --bb
Apr 12 2008
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
boyd wrote:

 The chances of this feature from happening depends on whether this 
 proposal appeals to the ideas of the designers of D, and partly on what 
 the D community thinks of it. So, there's really no telling what kinds 
 of odds we're dealing with here.


After you've observed Walter's behavior for a year or so, you start to 
get a feel for what he will or will not go for.  In my opinion, based on 
Walter's track record, he's not going to break with C tradition just to 
slightly improve readability.  He's hunting for features that that will 
enable paradigm shifts.

And he has an irrational fear of all things Pascal.  :-)

--bb
Apr 12 2008
parent reply Georg Wrede <georg nospam.org> writes:
Bill Baxter wrote:

 boyd wrote:
 

 The chances of this feature from happening depends on whether this 
 proposal appeals to the ideas of the designers of D, and partly on 
 what the D community thinks of it. So, there's really no telling what 
 kinds of odds we're dealing with here.


 
 After you've observed Walter's behavior for a year or so, you start to 
 get a feel for what he will or will not go for.  In my opinion, based on 
 Walter's track record, he's not going to break with C tradition just to 
 slightly improve readability.  He's hunting for features that that will 
 enable paradigm shifts.
 
 And he has an irrational fear of all things Pascal.  :-)


Mmmmpppghhhhh.....fffff........................
Apr 13 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Georg Wrede wrote:

 Bill Baxter wrote:

 boyd wrote:


 The chances of this feature from happening depends on whether this 
 proposal appeals to the ideas of the designers of D, and partly on 
 what the D community thinks of it. So, there's really no telling what 
 kinds of odds we're dealing with here.


 After you've observed Walter's behavior for a year or so, you start to 
 get a feel for what he will or will not go for.  In my opinion, based 
 on Walter's track record, he's not going to break with C tradition 
 just to slightly improve readability.  He's hunting for features that 
 that will enable paradigm shifts.

 And he has an irrational fear of all things Pascal.  :-)


 
 Mmmmpppghhhhh.....fffff........................


I don't get it.

But actually I take it back, Walter doesn't have an irrational fear of 
Pascal.  What he's said in the past (most recent I recall was discussion 
of using "var" instead of "auto") is that some people hate Pascal so 
much that they will shun a language if it even *reminds* them of Pascal.

So it's more like he has an irrational fear of people who have an 
irrational fear of Pascal. :-)

--bb
Apr 13 2008
parent Georg Wrede <georg nospam.org> writes:
Bill Baxter wrote:

 Georg Wrede wrote:

 Bill Baxter wrote:

 boyd wrote:


 The chances of this feature from happening depends on whether this 
 proposal appeals to the ideas of the designers of D, and partly on 
 what the D community thinks of it. So, there's really no telling 
 what kinds of odds we're dealing with here.


 After you've observed Walter's behavior for a year or so, you start 
 to get a feel for what he will or will not go for.  In my opinion, 
 based on Walter's track record, he's not going to break with C 
 tradition just to slightly improve readability.  He's hunting for 
 features that that will enable paradigm shifts.

 And he has an irrational fear of all things Pascal.  :-)


 Mmmmpppghhhhh.....fffff........................


 
 I don't get it.


Well, it was an entertaining and funny remark, but I decided not to 
laugh. :-)


 But actually I take it back, Walter doesn't have an irrational fear of 
 Pascal.  What he's said in the past (most recent I recall was discussion 
 of using "var" instead of "auto") is that some people hate Pascal so 
 much that they will shun a language if it even *reminds* them of Pascal.


That certainly was the case in the old times. Until Borland introduced 
Turbo Pascal, the language was hateable. And somehow that stigma has 
stuck in certain circles, especially with people who've never really 
acquainted themselves with Borland Pascal. Ok, Pascal was an academic 
language, solely designed to teach Good Programming, but still, trying 
to use it in real life (which obviously happens -- who'd want to spend 
years at the university learning a language, and then not try to solve 
one's problems with it), was problematic. For example handling console 
IO or files. Oh, and compilers used to cost upwards of $1000, but TP 
cost only $99, with a money-back guarantee, /and no/ copy protection. 
Total blasphemy!

And advocates in the academia took exception to Borland's way of 
resolving such issues. At the same time, regular people were 
exhilarated. Now one could really use Pascal in pretty much every kind 
of programming tasks, and it was fun, and their compiler was simply 
unbelievably fast. At the time, compiling even a trivial example 
(actually in any language) took typically minutes, and Borland's 
compiler did even non-trivials in seconds! Plus, any runtime errors gave 
you an address value, which you could give to then IDE, which then 
brought you to the exact source line! And the academia shouted "that's 
not Real Pascal!"

Of course, Pascal isn't C, and Serious Systems Programming, bare metal 
stuff, and guru style pointer wizardry are, of course, easier in C. And 
C folks simply hated BEGIN and END being used instead of {}, which made 
the language in their eyes look like kindergarten stuff. Including me, 
but otherwise I loved and still love the language. And I have to thank 
Borland for getting me into serious programming at all.

Besides, until about a year ago, you could do virtually anything you 
could do in D, in Borland Pascal, without much tweaking or extra effort. 
When we made a comparison table, it was a surprise to Walter that the 
difference in Yes boxes was so small. The biggest difference was 
actually the lack of GC.

If I had to write an operating system from scratch, and the choices 
given to me were D and Borland Pascal (in practice, that would be Free 
Pascal because I want a free as in beer language), I'd choose the 
latter, any day. Today, D is good for "regular programming", but Real 
Systems Work, I'm sorry to say, is not here yet with D. GC is one 
reason, runtime library dependencies and non-modularity are another. But 
I'm sure we're getting there.
Apr 14 2008
prev sibling next sibling parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
boyd wrote:

 So anyway, if it is going to become required on every function, let's 
 at least make it something shorter than 'function'.


 
 I personally prefer the keyword 'function', it's not that long and it's 
 clear. Shorter is okay as long as it doesn't decrease readability. I'm 
 wary of using 'func', as it could also indicate functor. I have no Idea 
 what a functor is but i've seen it used around here several times. 
 Anyway, are those 8 characters really such a pain to write?
 
 Regardless of what keyword will be used, the main reason for using a 
 keyword in the first place is readability. Not just for the user, but 
 also for the parser. I'm not an expert on parsing, but I'm pretty sure 
 this keyword could help identifying functions more easily.
 
 Plus there won't be any need for those special case storage classes like 
 'pure' and 'const' to be written at the end of the function, decreasing 
 the overal complexity of the D Language. Decreasing complexity of the 
 basic features becomes more and more important when more features are 
 added to D.
 

 I think the chances of it happening are slim and none, though.  Unless 
 you can come up with some more compelling reasons for it.  Heck we 
 can't even get Walter to remove 'printf' from Object.d.


 
 Having a keyword for function declarations is a completely different 
 matter from removing one lousy function in the standard library.
 
 The chances of this feature from happening depends on whether this 
 proposal appeals to the ideas of the designers of D, and partly on what 
 the D community thinks of it. So, there's really no telling what kinds 
 of odds we're dealing with here.
 

 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[] 
 func(invariant (double)[]) {...}


 
 This function would be even better if the implementation was: { return 
 _myArray; } :P
 Seriously, I don't think the function declaration keyword really affects 
 this problem.
 
 Anyway, thanks for the feedback.
 
 Cheers,
 Boyd
 
 
 
 --------
 On Sat, 12 Apr 2008 14:16:29 +0200, Bill Baxter 
 <dnewsgroup billbaxter.com> wrote:
 

 boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it 
 when I was searching for a better language for me to use.


  >

 Other languages always seemed to lack some crucial feature. D is 
 generally easy to use, easy to read and has all the options I wanted. 
 I also love the attention it has given to little details that just 
 make things so much easier.
  It's not perfect by any means, but overal it's better than anything. 
 I currently have gripes with mixins, which are a pain to use. From 
 what I hear Macros are gong to replace them, so for now I'll avoid 
 that subject.


 Heartily agree with you there.  For all the complaining I do here, I 
 still keep using D, because I really haven't found anything better.


   Instead I've been wondering about a problem that, to my knowledge, 
 hasn't gotten any attention yet: function declaration keyword.
  One thing I never really liked about C++ is the way function 
 declarations look. You can't easily differentiate them from variable 
 declarations. Maybe it's partly because I started with Object Pascal 
 rather than C++, but I never got used to it.
  Anyway, why not use a keyword for function declarations?
    function void DoSomething(int someParam);


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[] 
 func(invariant (double)[]) {...}

 Scarily, it's looking like that's probably going to be quite a 
 reasonable signature for a D2 pure method to have.  (Except for the 
 'function' part from your suggestion).

 For whatever else, K&R knew the value of keeping common keywords 
 short, even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean


 So anyway, if it is going to become required on every function, let's 
 at least make it something shorter than 'function'.

 I think the chances of it happening are slim and none, though.  Unless 
 you can come up with some more compelling reasons for it.  Heck we 
 can't even get Walter to remove 'printf' from Object.d.

 --bb




Update to my prior notes:

<modifier ...> <type> <identifier><(parameter, ...)> <property ...> 
<{block}>

where modifier is:
  const, static, pure, invariant(can a function or class be invariant?), 
etc...
where type is:
	class, function, etc...
where identifier is:
	the human identifier of the declaration
where parameter defined as:
	<modifier ...> <type> <identifier>
	where modifier is:
		const, static, final, invariant, volitile(cpu optimization for 
loops?), etc.
	where type is:
		int, double, float, void, etc.
	where identifier is:
		the human identifier of the declaration
where property is:
	<property <entry, ...>>	
	returns <parameter, ...>, throws?, (more later?)
where block is:
	code!

curious, someone mentioned before using in, out and ref... These are 
unknown to me, could someone give me a quick gist or point me to a page, 
  if so I will update this.
Apr 12 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Hans W. Uhlig wrote:


 boyd wrote:

 So anyway, if it is going to become required on every function, let's
 at least make it something shorter than 'function'.


 
 I personally prefer the keyword 'function', it's not that long and it's
 clear. Shorter is okay as long as it doesn't decrease readability. I'm
 wary of using 'func', as it could also indicate functor. I have no Idea
 what a functor is but i've seen it used around here several times.
 Anyway, are those 8 characters really such a pain to write?
 
 Regardless of what keyword will be used, the main reason for using a
 keyword in the first place is readability. Not just for the user, but
 also for the parser. I'm not an expert on parsing, but I'm pretty sure
 this keyword could help identifying functions more easily.
 
 Plus there won't be any need for those special case storage classes like
 'pure' and 'const' to be written at the end of the function, decreasing
 the overal complexity of the D Language. Decreasing complexity of the
 basic features becomes more and more important when more features are
 added to D.
 

 I think the chances of it happening are slim and none, though.  Unless
 you can come up with some more compelling reasons for it.  Heck we
 can't even get Walter to remove 'printf' from Object.d.


 
 Having a keyword for function declarations is a completely different
 matter from removing one lousy function in the standard library.
 
 The chances of this feature from happening depends on whether this
 proposal appeals to the ideas of the designers of D, and partly on what
 the D community thinks of it. So, there's really no telling what kinds
 of odds we're dealing with here.
 

 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]
 func(invariant (double)[]) {...}


 
 This function would be even better if the implementation was: { return
 _myArray; } :P
 Seriously, I don't think the function declaration keyword really affects
 this problem.
 
 Anyway, thanks for the feedback.
 
 Cheers,
 Boyd
 
 
 
 --------
 On Sat, 12 Apr 2008 14:16:29 +0200, Bill Baxter
 <dnewsgroup billbaxter.com> wrote:
 

 boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it
 when I was searching for a better language for me to use.


  >

 Other languages always seemed to lack some crucial feature. D is
 generally easy to use, easy to read and has all the options I wanted.
 I also love the attention it has given to little details that just
 make things so much easier.
  It's not perfect by any means, but overal it's better than anything.
 I currently have gripes with mixins, which are a pain to use. From
 what I hear Macros are gong to replace them, so for now I'll avoid
 that subject.


 Heartily agree with you there.  For all the complaining I do here, I
 still keep using D, because I really haven't found anything better.


   Instead I've been wondering about a problem that, to my knowledge,
 hasn't gotten any attention yet: function declaration keyword.
  One thing I never really liked about C++ is the way function
 declarations look. You can't easily differentiate them from variable
 declarations. Maybe it's partly because I started with Object Pascal
 rather than C++, but I never got used to it.
  Anyway, why not use a keyword for function declarations?
    function void DoSomething(int someParam);


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]
 func(invariant (double)[]) {...}

 Scarily, it's looking like that's probably going to be quite a
 reasonable signature for a D2 pure method to have.  (Except for the
 'function' part from your suggestion).

 For whatever else, K&R knew the value of keeping common keywords
 short, even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean


 So anyway, if it is going to become required on every function, let's
 at least make it something shorter than 'function'.

 I think the chances of it happening are slim and none, though.  Unless
 you can come up with some more compelling reasons for it.  Heck we
 can't even get Walter to remove 'printf' from Object.d.

 --bb




 Update to my prior notes:
 
 <modifier ...> <type> <identifier><(parameter, ...)> <property ...>
 <{block}>
 
 where modifier is:
   const, static, pure, invariant(can a function or class be invariant?),
 etc...
 where type is:
 class, function, etc...
 where identifier is:
 the human identifier of the declaration
 where parameter defined as:
 <modifier ...> <type> <identifier>
 where modifier is:
 const, static, final, invariant, volitile(cpu optimization for
 loops?), etc.
 where type is:
 int, double, float, void, etc.
 where identifier is:
 the human identifier of the declaration
 where property is:
 <property <entry, ...>>
 returns <parameter, ...>, throws?, (more later?)
 where block is:
 code!
 
 curious, someone mentioned before using in, out and ref... These are
 unknown to me, could someone give me a quick gist or point me to a page,
   if so I will update this.


See "function parameters" section at
http://www.digitalmars.com/d/1.0/function.html
Apr 13 2008
parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Jason House wrote:

 Hans W. Uhlig wrote:
 

 boyd wrote:

 So anyway, if it is going to become required on every function, let's
 at least make it something shorter than 'function'.


 I personally prefer the keyword 'function', it's not that long and it's
 clear. Shorter is okay as long as it doesn't decrease readability. I'm
 wary of using 'func', as it could also indicate functor. I have no Idea
 what a functor is but i've seen it used around here several times.
 Anyway, are those 8 characters really such a pain to write?

 Regardless of what keyword will be used, the main reason for using a
 keyword in the first place is readability. Not just for the user, but
 also for the parser. I'm not an expert on parsing, but I'm pretty sure
 this keyword could help identifying functions more easily.

 Plus there won't be any need for those special case storage classes like
 'pure' and 'const' to be written at the end of the function, decreasing
 the overal complexity of the D Language. Decreasing complexity of the
 basic features becomes more and more important when more features are
 added to D.


 I think the chances of it happening are slim and none, though.  Unless
 you can come up with some more compelling reasons for it.  Heck we
 can't even get Walter to remove 'printf' from Object.d.


 Having a keyword for function declarations is a completely different
 matter from removing one lousy function in the standard library.

 The chances of this feature from happening depends on whether this
 proposal appeals to the ideas of the designers of D, and partly on what
 the D community thinks of it. So, there's really no telling what kinds
 of odds we're dealing with here.


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]
 func(invariant (double)[]) {...}


 This function would be even better if the implementation was: { return
 _myArray; } :P
 Seriously, I don't think the function declaration keyword really affects
 this problem.

 Anyway, thanks for the feedback.

 Cheers,
 Boyd



 --------
 On Sat, 12 Apr 2008 14:16:29 +0200, Bill Baxter
 <dnewsgroup billbaxter.com> wrote:


 boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it
 when I was searching for a better language for me to use.


  >

 Other languages always seemed to lack some crucial feature. D is
 generally easy to use, easy to read and has all the options I wanted.
 I also love the attention it has given to little details that just
 make things so much easier.
  It's not perfect by any means, but overal it's better than anything.
 I currently have gripes with mixins, which are a pain to use. From
 what I hear Macros are gong to replace them, so for now I'll avoid
 that subject.


 Heartily agree with you there.  For all the complaining I do here, I
 still keep using D, because I really haven't found anything better.


   Instead I've been wondering about a problem that, to my knowledge,
 hasn't gotten any attention yet: function declaration keyword.
  One thing I never really liked about C++ is the way function
 declarations look. You can't easily differentiate them from variable
 declarations. Maybe it's partly because I started with Object Pascal
 rather than C++, but I never got used to it.
  Anyway, why not use a keyword for function declarations?
    function void DoSomething(int someParam);


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]
 func(invariant (double)[]) {...}

 Scarily, it's looking like that's probably going to be quite a
 reasonable signature for a D2 pure method to have.  (Except for the
 'function' part from your suggestion).

 For whatever else, K&R knew the value of keeping common keywords
 short, even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean


 So anyway, if it is going to become required on every function, let's
 at least make it something shorter than 'function'.

 I think the chances of it happening are slim and none, though.  Unless
 you can come up with some more compelling reasons for it.  Heck we
 can't even get Walter to remove 'printf' from Object.d.

 --bb




 Update to my prior notes:

 <modifier ...> <type> <identifier><(parameter, ...)> <property ...>
 <{block}>

 where modifier is:
   const, static, pure, invariant(can a function or class be invariant?),
 etc...
 where type is:
 class, function, etc...
 where identifier is:
 the human identifier of the declaration
 where parameter defined as:
 <modifier ...> <type> <identifier>
 where modifier is:
 const, static, final, invariant, volitile(cpu optimization for
 loops?), etc.
 where type is:
 int, double, float, void, etc.
 where identifier is:
 the human identifier of the declaration
 where property is:
 <property <entry, ...>>
 returns <parameter, ...>, throws?, (more later?)
 where block is:
 code!

 curious, someone mentioned before using in, out and ref... These are
 unknown to me, could someone give me a quick gist or point me to a page,
   if so I will update this.


 
 See "function parameters" section at
 http://www.digitalmars.com/d/1.0/function.html


Thank you, However after reading that, in, out, ref and lazy seem to be 
simply modifiers to parameters for the scope of the function definition, 
I am unsure as to how that would change this definition.
Apr 13 2008
parent Jason House <jason.james.house gmail.com> writes:
Hans W. Uhlig wrote:


 Jason House wrote:

 Hans W. Uhlig wrote:
 

 boyd wrote:

 So anyway, if it is going to become required on every function, let's
 at least make it something shorter than 'function'.


 I personally prefer the keyword 'function', it's not that long and it's
 clear. Shorter is okay as long as it doesn't decrease readability. I'm
 wary of using 'func', as it could also indicate functor. I have no Idea
 what a functor is but i've seen it used around here several times.
 Anyway, are those 8 characters really such a pain to write?

 Regardless of what keyword will be used, the main reason for using a
 keyword in the first place is readability. Not just for the user, but
 also for the parser. I'm not an expert on parsing, but I'm pretty sure
 this keyword could help identifying functions more easily.

 Plus there won't be any need for those special case storage classes
 like 'pure' and 'const' to be written at the end of the function,
 decreasing the overal complexity of the D Language. Decreasing
 complexity of the basic features becomes more and more important when
 more features are added to D.


 I think the chances of it happening are slim and none, though.  Unless
 you can come up with some more compelling reasons for it.  Heck we
 can't even get Walter to remove 'printf' from Object.d.


 Having a keyword for function declarations is a completely different
 matter from removing one lousy function in the standard library.

 The chances of this feature from happening depends on whether this
 proposal appeals to the ideas of the designers of D, and partly on what
 the D community thinks of it. So, there's really no telling what kinds
 of odds we're dealing with here.


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]
 func(invariant (double)[]) {...}


 This function would be even better if the implementation was: { return
 _myArray; } :P
 Seriously, I don't think the function declaration keyword really
 affects this problem.

 Anyway, thanks for the feedback.

 Cheers,
 Boyd



 --------
 On Sat, 12 Apr 2008 14:16:29 +0200, Bill Baxter
 <dnewsgroup billbaxter.com> wrote:


 boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it
 when I was searching for a better language for me to use.


  >

 Other languages always seemed to lack some crucial feature. D is
 generally easy to use, easy to read and has all the options I wanted.
 I also love the attention it has given to little details that just
 make things so much easier.
  It's not perfect by any means, but overal it's better than anything.
 I currently have gripes with mixins, which are a pain to use. From
 what I hear Macros are gong to replace them, so for now I'll avoid
 that subject.


 Heartily agree with you there.  For all the complaining I do here, I
 still keep using D, because I really haven't found anything better.


   Instead I've been wondering about a problem that, to my knowledge,
 hasn't gotten any attention yet: function declaration keyword.
  One thing I never really liked about C++ is the way function
 declarations look. You can't easily differentiate them from variable
 declarations. Maybe it's partly because I started with Object Pascal
 rather than C++, but I never got used to it.
  Anyway, why not use a keyword for function declarations?
    function void DoSomething(int someParam);


 I just hope I don't ever have to type this in D:

    protected override invariant pure function invariant(double)[]
 func(invariant (double)[]) {...}

 Scarily, it's looking like that's probably going to be quite a
 reasonable signature for a D2 pure method to have.  (Except for the
 'function' part from your suggestion).

 For whatever else, K&R knew the value of keeping common keywords
 short, even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean


 So anyway, if it is going to become required on every function, let's
 at least make it something shorter than 'function'.

 I think the chances of it happening are slim and none, though.  Unless
 you can come up with some more compelling reasons for it.  Heck we
 can't even get Walter to remove 'printf' from Object.d.

 --bb




 Update to my prior notes:

 <modifier ...> <type> <identifier><(parameter, ...)> <property ...>
 <{block}>

 where modifier is:
   const, static, pure, invariant(can a function or class be invariant?),
 etc...
 where type is:
 class, function, etc...
 where identifier is:
 the human identifier of the declaration
 where parameter defined as:
 <modifier ...> <type> <identifier>
 where modifier is:
 const, static, final, invariant, volitile(cpu optimization for
 loops?), etc.
 where type is:
 int, double, float, void, etc.
 where identifier is:
 the human identifier of the declaration
 where property is:
 <property <entry, ...>>
 returns <parameter, ...>, throws?, (more later?)
 where block is:
 code!

 curious, someone mentioned before using in, out and ref... These are
 unknown to me, could someone give me a quick gist or point me to a page,
   if so I will update this.


 
 See "function parameters" section at
 http://www.digitalmars.com/d/1.0/function.html


 Thank you, However after reading that, in, out, ref and lazy seem to be
 simply modifiers to parameters for the scope of the function definition,
 I am unsure as to how that would change this definition.


How do out parameters get handled when handling multiple return types?  Is
there a way to mix a=b() syntax with b(a)?
Apr 13 2008
prev sibling parent "Scott S. McCoy" <tag cpan.org> writes:
There isn't much reason, so far as I can see, for a function keyword.

I've never really mixed up:

int foo;
and
int foo () {
}

Something about the later just, sticks out at me as not being the
former.  Maybe it's the curly brackets, or the prototype.  Dunno!

I don't really want too much syntax added that can't be inferred,
particularly in a language like D which appears to favor inference.
May 04 2008
prev sibling parent reply "Hans W. Uhlig" <huhlig gmail.com> writes:
Bill Baxter wrote:

 boyd wrote:

 Okay, so I've been working with D for a while now. I stumbled upon it 
 when I was searching for a better language for me to use.


  >

 Other languages always seemed to lack some crucial feature. D is 
 generally easy to use, easy to read and has all the options I wanted. 
 I also love the attention it has given to little details that just 
 make things so much easier.

 It's not perfect by any means, but overal it's better than anything. I 
 currently have gripes with mixins, which are a pain to use. From what 
 I hear Macros are gong to replace them, so for now I'll avoid that 
 subject.


 
 Heartily agree with you there.  For all the complaining I do here, I 
 still keep using D, because I really haven't found anything better.
 

 Instead I've been wondering about a problem that, to my knowledge, 
 hasn't gotten any attention yet: function declaration keyword.

 One thing I never really liked about C++ is the way function 
 declarations look. You can't easily differentiate them from variable 
 declarations. Maybe it's partly because I started with Object Pascal 
 rather than C++, but I never got used to it.

 Anyway, why not use a keyword for function declarations?

   function void DoSomething(int someParam);


 
 I just hope I don't ever have to type this in D:
 
   protected override invariant pure function invariant(double)[] 
 func(invariant (double)[]) {...}
 
 Scarily, it's looking like that's probably going to be quite a 
 reasonable signature for a D2 pure method to have.  (Except for the 
 'function' part from your suggestion).
 
 For whatever else, K&R knew the value of keeping common keywords short, 
 even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean
 
 
 So anyway, if it is going to become required on every function, let's at 
 least make it something shorter than 'function'.
 
 I think the chances of it happening are slim and none, though.  Unless 
 you can come up with some more compelling reasons for it.  Heck we can't 
 even get Walter to remove 'printf' from Object.d.
 
 --bb


I would think this was more the case as you had significant resource 
limitations that you had to begin with. I think a lot of older school 
programmers would like to see would be nice tight code output, a little 
verbosity in the language isn't bad, it makes it readable and more 
expressive. We have Terrabyte hard drives and gigs of working memory on 
programming stations so a large text files are not a problem(and yes I 
know some of you work on 4MB 286s running a self rolled linux and vi, a 
50k sourcefile still wont kill you)  as long as what it puts out on 
compiling is small and tight, a couple extra kilobytes in source wont 
hurt us. The binary should be tight, not the source code.  The whole who 
needs more then 640k idea is outdated. Java has some right ideas that 
methods, keywords and attributes being descriptive(and no I don't 
support 
thisMethodTakesTwoValuesAndMultiplysThemOutAfterAskingTheUserMethod(int, 
int) {} that is just plain overkill.)
Apr 12 2008
parent reply Georg Wrede <georg nospam.org> writes:
Hans W. Uhlig wrote:

 Bill Baxter wrote:

 boyd wrote:


 Okay, so I've been working with D for a while now. I stumbled upon it 
 when I was searching for a better language for me to use.



 Other languages always seemed to lack some crucial feature. D is 
 generally easy to use, easy to read and has all the options I wanted. 
 I also love the attention it has given to little details that just 
 make things so much easier.

 It's not perfect by any means, but overal it's better than anything. 
 I currently have gripes with mixins, which are a pain to use. From 
 what I hear Macros are gong to replace them, so for now I'll avoid 
 that subject.


 Heartily agree with you there.  For all the complaining I do here, I 
 still keep using D, because I really haven't found anything better.


 Instead I've been wondering about a problem that, to my knowledge, 
 hasn't gotten any attention yet: function declaration keyword.

 One thing I never really liked about C++ is the way function 
 declarations look. You can't easily differentiate them from variable 
 declarations. Maybe it's partly because I started with Object Pascal 
 rather than C++, but I never got used to it.

 Anyway, why not use a keyword for function declarations?

   function void DoSomething(int someParam);


 I just hope I don't ever have to type this in D:

   protected override invariant pure function invariant(double)[] 
 func(invariant (double)[]) {...}

 Scarily, it's looking like that's probably going to be quite a 
 reasonable signature for a D2 pure method to have.  (Except for the 
 'function' part from your suggestion).

 For whatever else, K&R knew the value of keeping common keywords 
 short, even if it meant using abbreviations.  That's why we have
 - int not integer
 - char not character
 - const not constant
 - enum not enumeration
 - float not floating_point
 and later, thanks to Stroustrup, I guess:
 - bool not boolean


 So anyway, if it is going to become required on every function, let's 
 at least make it something shorter than 'function'.

 I think the chances of it happening are slim and none, though.  Unless 
 you can come up with some more compelling reasons for it.  Heck we 
 can't even get Walter to remove 'printf' from Object.d.


 
 I would think this was more the case as you had significant resource 
 limitations that you had to begin with. I think a lot of older school 
 programmers would like to see would be nice tight code output, 


Yes.


 a little verbosity in the language isn't bad, it makes it readable
 and more expressive.


It's called redundancy. So, if a keyword is 12 characters long, it 
pisses off everybody. But, if there's some subtle redundancy in the 
syntax (as opposed to C(++), where there's almost none, which results in 
you being able to write just anything and it's acceptable code -- in 
other words, it may not be syntactically wrong, it simply does something 
else than you possibly could have imagined), the code and the error 
messages the compiler can give you become vastly more helpful /towards/ 
effort per hour productivity.


 We have Terrabyte hard drives and gigs of working memory on 
 programming stations so a large text files are not a problem(and yes I 
 know some of you work on 4MB 286s running a self rolled linux and vi, a 
 50k sourcefile still wont kill you) 


Stab ignored. :-)  (Not to mention, I can actually show you a machine 
that corresponds to your specs..., except that the 286s rarely had 4MB 
of RAM. The issues with 286 were more like whether you had 0.6MB or 
1.0MB, and if so, what had the tweaks and kludges been to actually claim 
the usability of the 1MB. Look up on Google, issues like XMS and EMS.)

A programming language ought to work as well, whether you have "a 
default *386*" or "the coolest 16-CPU 16GB, 4MHz, 16TB HD" machine.


 as long as what it puts out on compiling is small and tight, a couple
 extra kilobytes in source wont hurt us. The binary should be tight,
 not the source code.  The whole who needs more then 640k idea is
 outdated.


An eighth of the 640K with D goes to the standard library. That means, 
that there's no way of running like 7 TSRs written in D, and then have 
enough RAM to use for your regular program.

This wouldn't bug me, if it weren't that my definition of a Systems 
Programming Language implies usability with arbitrary processors. As it 
stands now, D with PIC -- just forget it. D with


 Java has some right ideas that 
 methods, keywords and attributes being descriptive(and no I don't 
 support 
 thisMethodTakesTwoValuesAndMultiplysThemOutAfterAskingTheUserMethod(int, 
 int) {} that is just plain overkill.)
Apr 13 2008
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Georg Wrede wrote:

 It's called redundancy. So, if a keyword is 12 characters long, it 
 pisses off everybody.


foreach_reverse ...
Apr 13 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Robert Fraser wrote:

 Georg Wrede wrote:

 It's called redundancy. So, if a keyword is 12 characters long, it 
 pisses off everybody.


 
 foreach_reverse ...


touché!

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 25 2008
prev sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 12/04/2008, boyd <gaboonviper gmx.net> wrote:

   const int DoSomething(int someParam);

  Is the function const? or is the return value const? With the current const
 system we know this means the return value is const


No it doesn't.

However, the fact that you think it does makes the point beautifully
the current syntax is counterintuitive
Apr 14 2008
parent "Scott S. McCoy" <tag cpan.org> writes:
On Mon, 2008-04-14 at 08:15 +0100, Janice Caron wrote:

 On 12/04/2008, boyd <gaboonviper gmx.net> wrote:

   const int DoSomething(int someParam);

  Is the function const? or is the return value const? With the current const
 system we know this means the return value is const


 
 No it doesn't.
 
 However, the fact that you think it does makes the point beautifully
 the current syntax is counterintuitive


YES.
Apr 14 2008