View mode: basic / threaded / horizontal-split · Log in · Help
November 14, 2012
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
November 14, 2012
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
November 14, 2012
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
November 14, 2012
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
November 14, 2012
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
November 14, 2012
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);
November 14, 2012
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.
November 14, 2012
Re: Growing a Language (applicable to @attribute design)
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)
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.
1 2 3 4
Top | Discussion index | About this forum | D home