www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Growing a Language

reply Walter Bright <newshound2 digitalmars.com> writes:
An insightful talk by Guy Steele on what makes a language successful.

http://www.youtube.com/watch?v=_ahvzDzKdB0
Nov 13 2012
next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Tuesday, 13 November 2012 at 20:56:26 UTC, Walter Bright wrote:

 An insightful talk by Guy Steele on what makes a language 
 successful.

 http://www.youtube.com/watch?v=_ahvzDzKdB0



Watched this one ages ago. Definitely in my top 10 programming 
talks.
Nov 13 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2012 12:56 PM, Walter Bright wrote:

 An insightful talk by Guy Steele on what makes a language successful.

 http://www.youtube.com/watch?v=_ahvzDzKdB0



Guy says something interesting in there that's applicable to one of our current 
discussions.

Particularly, should we allow:

     identifier

as a user-defined attribute, in potential conflict with future reserved 
attribute words, or not?

Guy makes the argument that users need to be able to extend the vocabulary of a 
language and have those new words look like built-in ones. We have that today, 
of course, with the ability of defining new types. There is no special syntax 
that says "this is a user-defined type, not a keyword."

I think this is a compelling argument, and tips the scales in its favor. 
Probably we've been excessively worried about the problems of adding a new 
builtin attribute type.
Nov 13 2012
next sibling parent reply "Chris Nicholson-Sauls" <ibisbasenji gmail.com> writes:
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright 
wrote:

 On 11/13/2012 12:56 PM, Walter Bright wrote:

 An insightful talk by Guy Steele on what makes a language 
 successful.

 http://www.youtube.com/watch?v=_ahvzDzKdB0



 Guy says something interesting in there that's applicable to 
 one of our current discussions.

 Particularly, should we allow:

     identifier

 as a user-defined attribute, in potential conflict with future 
 reserved attribute words, or not?

 Guy makes the argument that users need to be able to extend the 
 vocabulary of a language and have those new words look like 
 built-in ones. We have that today, of course, with the ability 
 of defining new types. There is no special syntax that says 
 "this is a user-defined type, not a keyword."

 I think this is a compelling argument, and tips the scales in 
 its favor. Probably we've been excessively worried about the 
 problems of adding a new builtin attribute type.



Still better to worry now, only to concede later, than to develop 
a hobo stew of a language.  :)

-- Chris Nicholson-Sauls
Nov 13 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2012 5:19 PM, Chris Nicholson-Sauls wrote:

 Still better to worry now, only to concede later, than to develop a hobo stew
of
 a language.  :)



Like all long-lived languages, if D grows old it will be come a hobo stew. Of 
course, we must still try to minimize that.
Nov 13 2012
parent Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:


  it will be come a hobo stew



... at least one would be able to sell it:
http://www.agrinews.com/wadena/opens/its/arms/to/harvest/thyme/b
istro/story-4936.html

-manfred
Nov 13 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 14 November 2012 at 01:16:15 UTC, Andrej Mitrovic 
wrote:

 There are some attributes that would probably be very hardor
 impossible to implement in a library, e.g.  property



 property is very hard to implement in the compiler!


 I could think of
  inline, but that's hardly implementable in a library, so no 
 conflicts there.



There's always the option of making some of the magical 
identifiers, kinda like intrinsic functions.

The name follows normal D rules, but the behavior for a specific 
name is compiler magic.
Nov 13 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Wednesday, 14 November 2012 at 01:21:37 UTC, Adam D. Ruppe 
wrote:

 The name follows normal D rules, but the behavior for a 
 specific name is compiler magic.



BTW by this I mean fully qualified names.

import core.attributes;

 inline void foo(); /* core.attributes.inline is the magical name 
*/


module custom;
enum inline;
 inline void foo(); /* custom.inline is not magical */
Nov 13 2012
prev sibling next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 14/11/2012 02:16, Andrej Mitrovic a écrit :

 There are some attributes that would probably be very hardor
 impossible to implement in a library, e.g.  property ("..waits for
 someone to scream AST macros"), but I think there should be very few
 of those.



AST MACROS !!!

Actually, that one is pretty hard, especially considering how 
inconsistent the current behavior is.


 I don't think we'll have much conflicts. Can you think of any future
 attributes that should be part of the language? I could think of
  inline, but that's hardly implementable in a library, so no conflicts
 there.
Nov 13 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2012 5:16 PM, Andrej Mitrovic wrote:

 I would argue that we should strive to implement most new attributes
 into libraries.



I think that goes without saying, although it is a hard road to travel.

Consider, for example, the other thread where we are really trying hard to do 
"unique" as a library type rather than a builtin.



 I don't think we'll have much conflicts. Can you think of any future
 attributes that should be part of the language?



Well, we are guaranteed to think of some. But I don't anticipate it will be
many.
Nov 13 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-14 01:53, Walter Bright wrote:


 Guy says something interesting in there that's applicable to one of our
 current discussions.

 Particularly, should we allow:

      identifier

 as a user-defined attribute, in potential conflict with future reserved
 attribute words, or not?

 Guy makes the argument that users need to be able to extend the
 vocabulary of a language and have those new words look like built-in
 ones. We have that today, of course, with the ability of defining new
 types. There is no special syntax that says "this is a user-defined
 type, not a keyword."

 I think this is a compelling argument, and tips the scales in its favor.
 Probably we've been excessively worried about the problems of adding a
 new builtin attribute type.



Thank you for finally realizing. It's the same reason why we have 
operator overloading, we want user defined types to look like built in 
types.

-- 
/Jacob Carlborg
Nov 13 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-14 02:16, Andrej Mitrovic wrote:


 There are some attributes that would probably be very hardor
 impossible to implement in a library, e.g.  property ("..waits for
 someone to scream AST macros"), but I think there should be very few
 of those.



Seems I don't have to :)

-- 
/Jacob Carlborg
Nov 13 2012
prev sibling next sibling parent reply "renoX" <renozyx gmail.com> writes:
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright 
wrote:
[cut]

 Guy makes the argument that users need to be able to extend the 
 vocabulary of a language and have those new words look like 
 built-in ones. We have that today, of course, with the ability 
 of defining new types. There is no special syntax that says 
 "this is a user-defined type, not a keyword."



That's not strictly true: type inference works better for 
built-in types than for user-defined types, with "auto x = 1;" x 
is an int, how do I have the same type of syntax for MyInt?
AFAIK I can't, that's why I have mixed feelings towards type 
inference..

BR,
renoX
Nov 14 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2012 1:49 AM, renoX wrote:

 That's not strictly true: type inference works better for built-in types than
 for user-defined types, with "auto x = 1;" x is an int, how do I have the same
 type of syntax for MyInt?



You can have user-defined literals in D:

    auto x = MyInt(1);
Nov 14 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 12:06:29 Simen Kjaeraas wrote:

 On 2012-43-14 11:11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 11/14/2012 1:49 AM, renoX wrote:

 That's not strictly true: type inference works better for built-in
 types than
 for user-defined types, with "auto x = 1;" x is an int, how do I have
 the same
 type of syntax for MyInt?



 You can have user-defined literals in D:
     auto x = MyInt(1);



 But the syntax for built-in types is better, in that you don't need to
 write:
 
 auto x = int(1);



That's only because built-in types have literals built into the language. The 
type deduction is identical either way. It sounds like your complaint has 
nothing to do with type deduction then but rather with the fact that literals 
for user-defined types aren't as pretty as those for the built-in types.

- Jonathan M Davis
Nov 14 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:

 On 2012-43-14 11:11, Walter Bright <newshound2 digitalmars.com> wrote:


 On 11/14/2012 1:49 AM, renoX wrote:

 That's not strictly true: type inference works better for built-in types than
 for user-defined types, with "auto x = 1;" x is an int, how do I have the same
 type of syntax for MyInt?



 You can have user-defined literals in D:

     auto x = MyInt(1);



 But the syntax for built-in types is better, in that you don't need to
 write:

 auto x = int(1);



If you're going to argue that D should have some facility to create
user-defined 
literals that are arbitrary sequences of arbitrary characters, I think you're 
taking Guy's advice way beyond the breaking point.

This is pretty much true about every "principle" of language design. If you use 
that principle to blindly override everything else, you do not get anything
useful.

All design is a compromise of competing goals.
Nov 14 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-15 20:32, Era Scarecrow wrote:


   Hmmm... Correct me if I'm wrong, but you can create/use opAssign,
 correct? Although that doesn't work during initialization...

 struct MyInt
 {
    int i;
    ref MyInt opAssign(int rhs) {
      i = rhs;
      return this;
    }
 }

 MyInt x = MyInt(10);
 MyInt y; // = 15; //cannot implicity convert
 y = 15;



That's what a construtor is for:

struct MyInt
{
     int i;

     this (int i)
     {
         this.i = i;
     }

     ref MyInt opAssign(int rhs) {
         i = rhs;
         return this;
     }
}

void main()
{
     MyInt i = 3;
}

-- 
/Jacob Carlborg
Nov 15 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/15/2012 2:24 AM, Joseph Rushton Wakeling wrote:

 On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:

 But the syntax for built-in types is better, in that you don't need to
 write:

 auto x = int(1);



 .... suppose I want a size_t?



size_t x = 1;
Nov 15 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-11-15 22:08, Joseph Rushton Wakeling wrote:


 Complete misunderstanding there -- I'd interpreted Simen's remark as
 saying that e.g. auto x = 1; would automatically assign the correct type
 where builtins were concerned, and I was pointing out that this wouldn't
 cover all builtins.  Though I guess auto x = 1UL; would work.



Should this give you an unsigned long regardless of architecture? 
"size_t" is unsigned int on 32bit platforms and unsigned long on 64bit 
platforms.

-- 
/Jacob Carlborg
Nov 15 2012
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 10:49 AM, renoX wrote:

 On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright wrote:
 [cut]

 Guy makes the argument that users need to be able to extend the
 vocabulary of a language and have those new words look like built-in
 ones. We have that today, of course, with the ability of defining new
 types. There is no special syntax that says "this is a user-defined
 type, not a keyword."



 That's not strictly true: type inference works better for built-in types
 than for user-defined types, with "auto x = 1;" x is an int, how do I
 have the same type of syntax for MyInt?
 AFAIK I can't, that's why I have mixed feelings towards type inference..

 BR,
 renoX



(I prefer to call it type deduction. The term type inference has another 
meaning.)

I think you identified the wrong language feature as the cause.
Nov 14 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Wednesday, November 14, 2012 10:49:41 renoX wrote:

 That's not strictly true: type inference works better for
 built-in types than for user-defined types, with "auto x = 1;" x
 is an int, how do I have the same type of syntax for MyInt?
 AFAIK I can't, that's why I have mixed feelings towards type
 inference..



auto x = MyInt(1);

I don't see what's missing. What about type inference works better for built-
in types?

- Jonathan M Davis
Nov 14 2012
prev sibling next sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On 2012-43-14 11:11, Walter Bright <newshound2 digitalmars.com> wrote:


 On 11/14/2012 1:49 AM, renoX wrote:

 That's not strictly true: type inference works better for built-in  
 types than
 for user-defined types, with "auto x = 1;" x is an int, how do I have  
 the same
 type of syntax for MyInt?



 You can have user-defined literals in D:

     auto x = MyInt(1);



But the syntax for built-in types is better, in that you don't need to
write:

auto x = int(1);

-- 
Simen
Nov 14 2012
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 01:53 AM, Walter Bright wrote:

 On 11/13/2012 12:56 PM, Walter Bright wrote:

 An insightful talk by Guy Steele on what makes a language successful.

 http://www.youtube.com/watch?v=_ahvzDzKdB0



 Guy says something interesting in there that's applicable to one of our
 current discussions.

 Particularly, should we allow:

      identifier

 as a user-defined attribute, in potential conflict with future reserved
 attribute words, or not?

 Guy makes the argument that users need to be able to extend the
 vocabulary of a language and have those new words look like built-in
 ones. We have that today, of course, with the ability of defining new
 types. There is no special syntax that says "this is a user-defined
 type, not a keyword."



Well,

template Foo(alias a){ }
struct S{}

alias S X;     // ok
alias int Y;   // ok
mixin Foo!S;   // ok
mixin Foo!int; // not ok

Please fix that. (Everything should be ok.)


 I think this is a compelling argument, and tips the scales in its favor.
 Probably we've been excessively worried about the problems of adding a
 new builtin attribute type.
Nov 14 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2012 3:18 AM, Timon Gehr wrote:

 template Foo(alias a){ }
 struct S{}

 alias S X;     // ok
 alias int Y;   // ok
 mixin Foo!S;   // ok
 mixin Foo!int; // not ok

 Please fix that. (Everything should be ok.)



Please file a bugzilla for that.
Nov 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/14/2012 11:24 PM, Walter Bright wrote:

 On 11/14/2012 3:18 AM, Timon Gehr wrote:

 template Foo(alias a){ }
 struct S{}

 alias S X;     // ok
 alias int Y;   // ok
 mixin Foo!S;   // ok
 mixin Foo!int; // not ok

 Please fix that. (Everything should be ok.)



 Please file a bugzilla for that.



http://d.puremagic.com/issues/show_bug.cgi?id=9029
Nov 15 2012
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 14 November 2012 at 00:54:07 UTC, Walter Bright 
wrote:

 On 11/13/2012 12:56 PM, Walter Bright wrote:

 An insightful talk by Guy Steele on what makes a language 
 successful.

 http://www.youtube.com/watch?v=_ahvzDzKdB0



 Guy says something interesting in there that's applicable to 
 one of our current discussions.

 Particularly, should we allow:

     identifier

 as a user-defined attribute, in potential conflict with future 
 reserved attribute words, or not?

 Guy makes the argument that users need to be able to extend the 
 vocabulary of a language and have those new words look like 
 built-in ones. We have that today, of course, with the ability 
 of defining new types. There is no special syntax that says 
 "this is a user-defined type, not a keyword."

 I think this is a compelling argument, and tips the scales in 
 its favor. Probably we've been excessively worried about the 
 problems of adding a new builtin attribute type.



I think an example to watch is how Java has been evolving.

Since attributes were added to the language, new features tend to 
be introduced via new attributes (e.g.  Overload,  NotNull, ...) 
to avoid collisions with existing code.

While it makes sense from the backwards compatibility point of 
view, and Python3 is a good example people don't like rewriting 
legacy code, it leads to attribute definition explosion.

--
Paulo
Nov 14 2012
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/14/2012 12:06 PM, Simen Kjaeraas wrote:

 But the syntax for built-in types is better, in that you don't need to
 write:

 auto x = int(1);



.... suppose I want a size_t?
Nov 15 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Wednesday, 14 November 2012 at 22:23:17 UTC, Walter Bright 
wrote:

 On 11/14/2012 3:06 AM, Simen Kjaeraas wrote:

 But the syntax for built-in types is better, in that you don't 
 need to write:

 auto x = int(1);



 If you're going to argue that D should have some facility to 
 create user-defined literals that are arbitrary sequences of 
 arbitrary characters, I think you're taking Guy's advice way 
 beyond the breaking point.



  Hmmm... Correct me if I'm wrong, but you can create/use 
opAssign, correct? Although that doesn't work during 
initialization...

struct MyInt
{
   int i;
   ref MyInt opAssign(int rhs) {
     i = rhs;
     return this;
   }
}

MyInt x = MyInt(10);
MyInt y; // = 15; //cannot implicity convert
y = 15;

writeln(x);
writeln(y);
Nov 15 2012
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 11/15/2012 11:54 AM, Walter Bright wrote:

 size_t x = 1;



Complete misunderstanding there -- I'd interpreted Simen's remark as saying
that 
e.g. auto x = 1; would automatically assign the correct type where builtins
were 
concerned, and I was pointing out that this wouldn't cover all builtins. 
Though 
I guess auto x = 1UL; would work.

I wasn't asking how to create a size_t per se, which I do know how to do ... :-)

I once came an awful cropper due to lack of UL in an integer assignment.  I'd 
got a bit of C(++) code like this:

      size_t p = 1 << m;

where m was chosen such that p would be the largest power of 2 on the system 
that could (i) be multiplied by 2 without integer wraparound and (ii) was
within 
the range of the uniform integer random number generator in use.

And that worked fine ... until I installed a 64-bit OS, and suddenly, all the 
numbers were coming out different.

They shouldn't have been, because the RNG in use was still based around int32_t 
and so the same constraints on m and p should have been in place ... and then I 
discovered what was happening: 1 << m; wasn't taking a size_t (unsigned long) 
and bitshifting it by m places, it was taking a regular int and bitshifting it 
by m places ... which given the value of m, was causing integer wraparound, the 
result of which was then converted to a size_t.

It just so happened that on 32-bit this was taking the value back to where it 
was supposed to be anyway.  But on 64-bit the wraparound made 1 << m a negative 
number which in turn corresponded to a far too _large_ value when converted
into 
a size_t.

And so I learned that I had to use 1UL << m; instead ... :-P
Nov 15 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 11/14/12, Walter Bright <newshound2 digitalmars.com> wrote:

 Particularly, should we allow:

      identifier

 as a user-defined attribute, in potential conflict with future reserved
 attribute words, or not?



I would argue that we should strive to implement most new attributes
into libraries. Every time you make an attribute a language feature it
means all compilers must implement it (+ it increases the perceived
complexity of the language). And since we're constantly improving
reflection capabilities of the language most attributes should become
implementable in a library sooner or later.

There are some attributes that would probably be very hardor
impossible to implement in a library, e.g.  property ("..waits for
someone to scream AST macros"), but I think there should be very few
of those.

I don't think we'll have much conflicts. Can you think of any future
attributes that should be part of the language? I could think of
 inline, but that's hardly implementable in a library, so no conflicts
there.
Nov 13 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 16, 2012 08:26:10 Jacob Carlborg wrote:

 On 2012-11-15 22:08, Joseph Rushton Wakeling wrote:

 Complete misunderstanding there -- I'd interpreted Simen's remark as
 saying that e.g. auto x = 1; would automatically assign the correct type
 where builtins were concerned, and I was pointing out that this wouldn't
 cover all builtins.  Though I guess auto x = 1UL; would work.



 Should this give you an unsigned long regardless of architecture?
 "size_t" is unsigned int on 32bit platforms and unsigned long on 64bit
 platforms.



Yeah. If you want a literal to be size_t, then you either need to assign it to 
a variable of type size_t or cast it. L means long and UL means unsigned long, 
whereas size_t varies from architecture to architecture.

- Jonathan M Davis
Nov 15 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
size_t i = to!size_t(1) << m;
Nov 17 2012