Jump to page: 1 24  
Page
Thread overview
Growing a Language
Nov 13, 2012
Walter Bright
Nov 13, 2012
Peter Alexander
Re: Growing a Language (applicable to @attribute design)
Nov 14, 2012
Walter Bright
Nov 14, 2012
Andrej Mitrovic
Nov 14, 2012
Adam D. Ruppe
Nov 14, 2012
Adam D. Ruppe
Nov 14, 2012
deadalnix
Nov 14, 2012
Walter Bright
Nov 14, 2012
Jacob Carlborg
Nov 14, 2012
Walter Bright
Nov 14, 2012
Manfred Nowak
Nov 14, 2012
Jacob Carlborg
Nov 14, 2012
renoX
Nov 14, 2012
Jonathan M Davis
Nov 14, 2012
Walter Bright
Nov 14, 2012
Simen Kjaeraas
Nov 14, 2012
Walter Bright
Nov 15, 2012
Era Scarecrow
Nov 15, 2012
Jacob Carlborg
Nov 14, 2012
Jonathan M Davis
Nov 15, 2012
Walter Bright
Nov 16, 2012
Jacob Carlborg
Nov 16, 2012
Jonathan M Davis
Nov 17, 2012
Kagamin
Nov 14, 2012
Timon Gehr
Nov 14, 2012
Timon Gehr
Nov 14, 2012
Walter Bright
Nov 15, 2012
Timon Gehr
Nov 14, 2012
Paulo Pinto
November 13, 2012
An insightful talk by Guy Steele on what makes a language successful.

http://www.youtube.com/watch?v=_ahvzDzKdB0
November 13, 2012
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
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
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
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
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
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
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
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
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.

« First   ‹ Prev
1 2 3 4