Re: Growing a Language (applicable to @attribute design)
size_t i = to!size_t(1) << m;
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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);
Re: Growing a Language (applicable to @attribute design)
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;
Re: Growing a Language (applicable to @attribute design)
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?
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
On 11/14/2012 3:06 AM, Simen Kjaeraas wrote: On 2012-43-14 11:11, Walter Bright 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.
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
On Wednesday, November 14, 2012 12:06:29 Simen Kjaeraas wrote: > On 2012-43-14 11:11, Walter Bright 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
Re: Growing a Language (applicable to @attribute design)
On 2012-43-14 11:11, Walter Bright 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
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
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);
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
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 */
Re: Growing a Language (applicable to @attribute design)
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.
Re: Growing a Language (applicable to @attribute design)
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
Re: Growing a Language (applicable to @attribute design)
On 11/14/12, Walter Bright 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.
Re: Growing a Language (applicable to @attribute design)
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.
