November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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 |
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to renoX | 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
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to renoX | 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);
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to renoX | 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.
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
November 14, 2012 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 <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
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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. |
Copyright © 1999-2021 by the D Language Foundation