Thread overview | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 13, 2012 Growing a Language | ||||
---|---|---|---|---|
| ||||
An insightful talk by Guy Steele on what makes a language successful. http://www.youtube.com/watch?v=_ahvzDzKdB0 |
November 13, 2012 Re: Growing a Language | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
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:
> 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
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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. |
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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 */
|
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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. |
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrej Mitrovic | 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. |
November 14, 2012 Re: Growing a Language (applicable to @attribute design) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Nicholson-Sauls | 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.
|
Copyright © 1999-2021 by the D Language Foundation