Re: accept @pure @nothrow @return attributes
On 2015-01-29 22:47, Walter Bright wrote: Ruby also has monkey patching, another misfeature. It works great, have you actually used it? The entire Rails plugin system is built around monkey patching. It's far more successful than any D project. -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 2015-01-29 22:02, ketmar wrote: this never worked good. see deadalnix. or: foo.bar .zed In Ruby .zed is not valid code, so in Ruby it means: foo.bar.zed; In D it, with my rules, it would mean: foo.bar; .zed; In D you would need to write: foo.bar. zed -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On Friday, 30 January 2015 at 09:27:09 UTC, Jacob Carlborg wrote: You need some kind of separation between the statements. In Ruby a newline works as a statement separator. I think Go actually injects ; in the lexer on tokens that can end statements if the token is followed by newline. Sounds crazy, but it works for that grammar.
Re: accept @pure @nothrow @return attributes
On 2015-01-29 22:50, Walter Bright wrote: error message clarity, recovery, and the correct identification of the location of the error degrades substantially I never had problems with the error messages in Ruby. But I do have had problems with them in D. Example: int a = 3 int b = 4; The compiler will complain there's a missing semicolon on line 4 in front of int. The user has most likely forget to add the semicolon at the end of the first line. Notice that your comment is still relying on remaining redundancy to try to figure out where the ; is supposed to go. You need some kind of separation between the statements. In Ruby a newline works as a statement separator. -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 1/30/2015 1:27 AM, Jacob Carlborg wrote: In Ruby a newline works as a statement separator. Making it not an example of what I was talking about.
Re: accept @pure @nothrow @return attributes
On Friday, 30 January 2015 at 09:21:17 UTC, Jacob Carlborg wrote: On 2015-01-29 22:47, Walter Bright wrote: Ruby also has monkey patching, another misfeature. It works great, have you actually used it? The entire Rails plugin system is built around monkey patching. It's far more successful than any D project. I have to agree with Jacob. It's an extremely powerful tool. It's used for things that D would use templating, introspection, CTFE and mixins for. Of course, each of these has its disadvantages, but that doesn't make them misfeatures at all. Unlike real misfeatures, the chance that someone uses them (or monkey patching) by accident and unintentionally is low.
Re: accept @pure @nothrow @return attributes
On 28/01/2015 22:44, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: Could it be that new languages define grammars that are more robust than the one used by C? Like Go? We're not going to significantly change the structural syntax of D, so it doesn't seem that your argument is particularly relevant here.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote: On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. And it is so bad when the codebase grows that people are willing to switch to Node.js (!)
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 13:58:52 UTC, Jacob Carlborg
wrote:
A good language design that doesn't require the ; statement
terminator would recognize void func() as a valid statement
and implicit add ;. Scan the line, if a valid language
construct has been seen at the end of the line, insert a ;, if
not continue to the next line. That works in many languages.
Tells me what this function returns in javascript :
function foo()
{
return
{
foo: bar,
}
}
Yes, you guessed right, it returns undefined. Ho you didn't ?
What a surprise !
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 17:17:44 UTC, deadalnix wrote: On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote: On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. And it is so bad when the codebase grows that people are willing to switch to Node.js (!) That is so yesterday, they are now either on Go or Clojure.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 00:03:52 UTC, Brian Schott wrote: I take it you also don't care if your IDE lags for 5 seconds every time you type a character? Actually, modern parsers can parse ambiguous grammars in O(N) using memoing. Just because you are reluctant to implement a modern parser does not mean that it cannot be done and wrapped up as a library. I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. D does not even have a published grammar that rejects programs that are not well formed. The problem is not that having a programmer friendly will cause tool writer problems. The problem is in D specification and semantics which are C++ish. What people have requested is not C++ish it is well within a CFG. You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines. What is easy for a standards committee is to check that their data structure definitions are implementable in C, C++, Java, C# and SQL. Not being able to repesent those in D will make D less attractive. Besides there is no ambiguity in allowing arbitrary field names since they are preceded by a .. (nobody cares about local variables)
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 10:22:13 UTC, Ola Fosheim Grøstad wrote: Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use body as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release. In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei). This role was rediscovered as product owner in Agile settings. Strong leadership and saying no more often that people would like is a constant among good projects. I also made D proposals back in the days and they were @crap proposals (literally). You, personally, want syntax changes AND feature freeze. Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 10:50:49 UTC, ponce wrote: In the Mythical Man Month, Brooks advises for a single person responsible for architecture, or a dynamic duo (this is exactly what we are with Walter and Andrei). You mean like Batman? I don't feel like discussing system development principles with you if you think the dynamic duo is anywhere near following sound software engineering principles. It is not a fun topic to teach (yes, I have done that). This role was rediscovered as product owner in Agile settings. Strong leadership and saying no more often that people would like is a constant among good projects. The only thing that truly matters is that you have a plan and a reasonable process to back it up. Leadership is about facilitating the process. A role is not a person, it is backing a task that to be fulfilled to facilitate the process in a predictable and orderly fashion. I also made D proposals back in the days and they were @crap proposals (literally). You, personally, want syntax changes AND feature freeze. I personally don't think it is reasonable for Walter and Andrei to present D as a tool that is suitable for production. If it is, then they have to fess up to massive critique. Take a look at dlang.org, where does it say experimental language? It used to say beta, which actually should have been alpha... I personally only want D to follow sound engineering principles. I personally don't want syntax changes or feature freeze, since it won't help without a solid process to back it up. Nobody would use a language whose leaders have said yes to the ideas of the every abusive internet users out there. I think it is abusive and dishonest to present a language as ready for use when it nowhere near a stable release. I've previously requested that they actually do language design by writing up a spec for where D is heading, so that people can make up their mind and decide to provide implementation power if they like the presented outcome. Without a clear horizon, it makes no sense to participate unless you have it as a hobby. That slows down progress. That is what makes Rust and Go winners and D a stagnation. What I suggest is the best for D is: 1. Feature freeze. 2. Fix semantics/refactor compiler internals. 3. Fix syntax to be mainstream friendly. In that order. I have no hope that it will happen without a major restructuring of the process. I'm totally with ketmar on that front.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 19:33:32 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak
wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guarantee it doesn't
introduce any ambiguity. Other then that, I don't see any
reason why it's a bad thing. It doesn't make the syntax more
complicated, it doesn't maker it harder to parse, I just
don't see why its bad.
Thats not possible:
@safe {
void some func() // now valid
}
safe:
void some func() // now valid
safe {
void some func() // could not be valid
}
safe:
void some func() // could not be valid
So you need more places where keyword needs to be contextual
keyword
And this is a path I am not sure we want to go.
None of those cases would valid. Non-Keyword attributes
without a '@' must be on the right hand side of the function
parameters.
Then I'm afraid the proposal is pointless :-( The goal AIUI is to
make the language more consistent. If we can't use the new syntax
everywhere (and later get rid of the old one), we can't achieve
that.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 03:14:10 UTC, Zach the Mystic wrote: helped. I'm also glad Walter was able to follow it up with an even better reasoning which speaks from deep experience, which I could not have done. Let's move on! Indeed, Walter has some deep reasoning ENTIRELY based on personal experience. Unfortunately it totally lacks theoretical backing and shows a complete disregard for how usability evaluation is done. Other popular languages, who have users that do not complain about language syntax, are obviously wrong because they eschew Walter's personal deep reasoned experience. These users must be delusional and clueless for being happy with a syntax that is obviously flawed for not providing redundant noise that improves usability! While D, who have few users of which a fair share keep complaining about the syntax, is beyond critique with an ever expanding feature set and an increasing pile of reserved words that prevent library authors from implementing the most common standard on this planet. Here is the crux: nobody forces people who don't want to use body as an identifier to use it, but that is not a good argument for preventing everybody else from using it as an identifier! D is a practically impractical language until it provides: 1. feature freeze 2. semantic specification 3. clean slate syntax upgrade D is a hobby language and is loosing more talent than it should for not following a reasonable trajectory. 16 years in the making, still no stable release.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 22:44:45 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. That explains why new languages make ; optional, or wait... Could it be that the language designers of new languages have realized that using ; for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go? Counter example: Rust. Of course, Rust isn't the epitome of readability. Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:25:05 UTC, Dicebot wrote: On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote: Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. Same for any symbol. Do you have a solution? Long time ago I have proposed to actually define built-it attributes as UDA's in public druntime module. That way any possible conflict can be resolved relatively easy with dfix using module system disambugation (or just hard-code druntime symbols to be legal to shadow by user ones, though that sounds too much of a magic and surprise) I suppose, when UDA conflicts with builtin attribute, that UDA can be still disambiguated through module system.
Re: accept @pure @nothrow @return attributes
On 2015-01-28 23:27, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found. A good language design that doesn't require the ; statement terminator would recognize void func() as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages. -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 2015-01-28 20:07, Jonathan Marler wrote: You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning. By that definition basically all declarations in the object module is a keyword :) -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 2015-01-29 18:17, deadalnix wrote: And it is so bad when the codebase grows that people are willing to switch to Node.js (!) And still people are using it successfully. -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On 2015-01-29 16:29, Kagamin wrote: I suppose, when UDA conflicts with builtin attribute, that UDA can be still disambiguated through module system. We can always add another @ sign in front of new attributes ;) -- /Jacob Carlborg
Re: accept @pure @nothrow @return attributes
On Thu, 29 Jan 2015 14:58:51 +0100, Jacob Carlborg wrote: On 2015-01-28 23:27, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found. A good language design that doesn't require the ; statement terminator would recognize void func() as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages. this never worked good. see deadalnix. or: foo.bar .zed is `.zed` a chained call or free call? oh, well, build symbol table to find that? and what if we have free function `zed` and a method `zed`? there can be alot of such samples. implicit `;` never worked right in grammars that allows arbitrary newlines. such grammars requires explicit end-of-sentence signs to be parsable without ambiguities on almost each code line. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On 1/29/2015 5:58 AM, Jacob Carlborg wrote: On 2015-01-28 23:27, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found. A good language design that doesn't require the ; statement terminator would recognize void func() as a valid statement and implicit add ;. Scan the line, if a valid language construct has been seen at the end of the line, insert a ;, if not continue to the next line. That works in many languages. Oh, I know it can be made to work. That wasn't my point, which I shall repeat: error message clarity, recovery, and the correct identification of the location of the error degrades substantially Notice that your comment is still relying on remaining redundancy to try to figure out where the ; is supposed to go.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 19:49:58 UTC, Jacob Carlborg wrote: On 2015-01-29 18:17, deadalnix wrote: And it is so bad when the codebase grows that people are willing to switch to Node.js (!) And still people are using it successfully. Yes, my point is that there is tradeof. This is easy to build something fast in ruby, but this becomes unmaintainable at scale. I'm not sure this is the tradeof we want in D.
Re: accept @pure @nothrow @return attributes
On Thu, 29 Jan 2015 17:17:44 +, deadalnix wrote: On Thursday, 29 January 2015 at 14:00:16 UTC, Jacob Carlborg wrote: On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. And it is so bad when the codebase grows that people are willing to switch to Node.js (!) 'cause they think that javascript is kind of magic that will turn their shitcode to great code. what they didn't realise is that shitcode lives in their heads, not in languages. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On 1/29/2015 6:00 AM, Jacob Carlborg wrote: On 2015-01-29 01:19, Walter Bright wrote: One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?) Ruby has implicit declaration of variables. Ruby it has been around longer than D and are used by far, far more developers. Some languages have started out with the implicit declaration behavior, but as they matured they provided an option to disable it (e.g. Perl's use strict or Visual Basic's Option Explicit). -- http://en.wikipedia.org/wiki/Declaration_(computer_programming)#Variables Ruby also has monkey patching, another misfeature. Even so, lots of languages survive execrable features if they are counterbalanced by more desirable one.
Re: accept @pure @nothrow @return attributes
On Thursday, January 29, 2015 13:47:47 Walter Bright via Digitalmars-d wrote: Even so, lots of languages survive execrable features if they are counterbalanced by more desirable one. C! - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote: Dicebot: Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word obvious is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-) I am aware of Python Zen and generally it is not applicable to D. Multiple ways of doing the same thing can be justified both for backwards compatibility and pragmatical reason. But in this case I see no improvement that could justify it. I'd welcome the change to attribute syntax but only one that actually fixes the problems and not just rearranges things.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 13:14:16 UTC, bearophile wrote: The word obvious is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-) Yes... but which one is obvious: [0.1*x for x in range(10)] map(operator.mul,range(10),[0.1]*10) numpy.arange(0.,0.95,0.1) numpy.linspace(0,0.9,num=10) list(itertools.islice(itertools.count(0.0, 0.1), 10)) ...
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 13:58:22 UTC, bearophile wrote: The first one (the list comp) is Pythonic, and it's obviously the obvious one :-) If you want/need to use numpy, the fourth is good. No problems :-) Ok, so we agree, but I think the obvious way if we forget about languages would be to combine range with element wise multiplication, e.g. range(10) .* 0.1. Good usability often means... stick to common conventions, but be internally consistent. Most language designs fail here by not caring enough for the know-how users bring to the table... :-/
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote: But in this case I see no improvement that could justify it. Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote: On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote: But in this case I see no improvement that could justify it. Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388 Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one camp to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. I don't see any _vision_ behind the change, just moving bits around. It is not well-thought.
Re: accept @pure @nothrow @return attributes
On 28.01.15 14:14, bearophile wrote: Dicebot: Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. Yes but also: Practicality beats purity :)
Re: accept @pure @nothrow @return attributes
Ola Fosheim Grøstad: [0.1*x for x in range(10)] map(operator.mul,range(10),[0.1]*10) numpy.arange(0.,0.95,0.1) numpy.linspace(0,0.9,num=10) list(itertools.islice(itertools.count(0.0, 0.1), 10)) The first one (the list comp) is Pythonic, and it's obviously the obvious one :-) If you want/need to use numpy, the fourth is good. No problems :-) Bye, bearophile
Re: accept @pure @nothrow @return attributes
Dicebot: Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. One of the rules of the Python Zen: There should be one-- and preferably only one --obvious way to do it. The word obvious is important, because usually there are multiple ways to do something, but only one of them should be obvious in Python :-) Bye, bearophile
Re: accept @pure @nothrow @return attributes
On Tuesday, 27 January 2015 at 18:21:37 UTC, Nick Treleaven wrote: I think you may have missed the point. I believe what Jonathan is saying is that if you turn abstract into @abstract then you have to consider how to solve the abstract class issue. Do you change it to: @abstract class ? Yes, because it affects the class's functions, not its variable members. Probably unimportant, but no, abstract and final apply to classes, not to members. tl;dr what's problem with applying attributes to classes? Classes can have various attributes, abstract and final are just among them. I would recommend this formatting: --- @abstract @final @notypeinfo class ... ---
Re: accept @pure @nothrow @return attributes
On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote: This change didn't break a single line in the libraries or the test suite. Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. It is simply moving things around for the sake of marking some bugzilla report as closed - there is no consistent rationale for applying @ to attributes available. Just the fact that change can't possibly break anything doesn't mean it is can't have negative value. It _may_ have some well-though rationale behind I am failing to spot but that is not presented to users in any way.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 14:59:48 UTC, Andrei Alexandrescu wrote: Change has been reverted. -- Andrei Thank you very much. Just to be perfectly clear : I am not against consolidating attributes or even breaking things. Only thing I want is for such changes to be done _simultaneously_ with some more detailed rationale which can be linked from a changelog and would explain everyone outside of this NG what the change is about. It is quite likely that trying to write such rationale will highlight more internal inconsistencies than any discussion could.
Re: accept @pure @nothrow @return attributes
On Wednesday, January 28, 2015 14:41:08 Dicebot via Digitalmars-d wrote: On Wednesday, 28 January 2015 at 14:30:47 UTC, Kagamin wrote: On Wednesday, 28 January 2015 at 13:20:24 UTC, Dicebot wrote: But in this case I see no improvement that could justify it. Fixes problems people have with inconsistent attribute syntax, see discussion at https://issues.dlang.org/show_bug.cgi?id=13388 Yes, but as it has been already mentioned in this thread new system is as much inconsistent - it simply has moved 3 of attributes from one camp to another. If idea was to separate attributes that affect mangling/type then we still have protection attributes. And with no plans to deprecate old syntax even more inconsistency had been introduced. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. I don't see any _vision_ behind the change, just moving bits around. It is not well-thought. Exactly. It's not like this is simply a discussion of whether a change which makes the language more consistent is worth the breaking changes that it causes. Rather, The change doesn't actually fix anything. It just moves stuff around. If more things were moved around, then maybe they'd become more consistent and would actually help the situation, but that's not what's happened. A few were attributes moved from one camp to the other with no real plan, and because it took attributes from the smaller camp and put them in the larger one, it's actually decreasing consistency and making the situation worse rather than improving it. If we're going to shuffle attributes around, we need to do it in a way that actually follows a plan and makes the language more consistent. That's not what's happening here. We either need to come up with a complete plan for shuffling attributes around in a way that will actually make them fully consistent, or we need to revert these changes and stick with the status quo. Anything else just shuffles things around without fixing the problem, and it increases confusion in the process. And honestly, after several discussions on this in the past, I don't think that it's actually possible to make the attributes fully consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects (e.g. @ on a whole bunch of keywords like private or final that other languages don't put @ on and which none of the current D literature or code out there puts @ on). I think that this is a case of folks trying to shuffle things around to fix something that just can't be fixed. At best, it'll just end up being ugly in a different way. - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote: consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects The logical conclusion from that statement would be that D semantics are fundamentally broken...
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 14:41:09 UTC, Dicebot wrote: And with no plans to deprecate old syntax even more inconsistency had been introduced. When the problem arises, then. Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. Same for any symbol. Do you have a solution? I don't see any _vision_ behind the change, just moving bits around. It is not well-thought. @pure, @nothrow and @return are relatively obscure attributes, so if they change, it should cause minor commotion. If you want to overhaul everything, you can propose a DIP.
Re: accept @pure @nothrow @return attributes
On 1/28/15 7:25 AM, Dicebot wrote: The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues. BTW what's the deal with std.meta? -- Andrei
Re: accept @pure @nothrow @return attributes
On Tuesday, 27 January 2015 at 01:14:01 UTC, Zach the Mystic wrote: On Tuesday, 27 January 2015 at 00:57:24 UTC, Jonathan Marler wrote: On Tuesday, 27 January 2015 at 00:44:14 UTC, Zach the Mystic 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without `@`. I agree that the proposal doesn't solve the consistency issue, but the proposal doesn't make things more inconsistent then they already are. It adds another way to write these attributes, but it adds a way that makes more sense in my opinion. This is a step in the right direction in solving the problem. The next step would be to solve the consistency issue, but again, that's another debate. To conclude, which code would you rather write? The consistency issue is precisely that there should not be more than one way to write an attribute. Note that that's precisely where most of the opposition to this thread's original proposal came from. Uniformity means never having to explain to anybody why there is more than one way to do something. Both this thread's proposal and your proposal *introduce* inconsistency in this way. The old syntax can be deprecated and removed after an appropriate period.
Re: accept @pure @nothrow @return attributes
If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put @ on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. And even then, instead of getting complaints about being inconsistent with @, then we'd get even more complaints about the number of keywords that we have. There is no way to win here. No matter what we do, there will be screaming from someone. And whether the language would be objectively improved would be debatable. I have proposed a way that I think is a win win. Add support for non-keyword function attributes on the right hand side of a function signature. This will not break any code since it does not require removing support for using '@' for function attributes. Then later we can deprecate support for the '@' character if we feel like it's worth breaking code. void foo() safe; // now valid, and safe is not a keyword safe void foo(); // still not valid, might make the grammar // ambiguous, if it does not then it could // be supported later void foo() @safe; // Still ok (can be deprecated) It's simple to remember that if you put the function attribute on the right hand side then no '@' is required. Plus, this will encourage developers to put their attributes on the right hand side in the future so they can remove the '@' character. PLUS, this would be very simple to implement! There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better. My proposal will not break any code.
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 19:59:58 UTC, H. S. Teoh wrote:
On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via
Digitalmars-d wrote:
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
Personally, I'd much prefer that we not make this change.
It's good to have this discussion.
Previously, it's all been advocacy and break my code by
forcing a
change from pure = @pure.
Just a few days ago on slashdot, an anonymous D user wrote:
A horrible mix of keywords and annotation syntax for
function/method attributes ('const', 'pure', and 'nothrow'
are all
keywords, but '@property', and '@nogc' are annotations)
for why he won't use D anymore.
Frankly, I think that is a great bikeshedding non-issue that
distracts
us from what is important. I hope that by doing this PR, we can
actually decide that it isn't worth it, i.e. I'd be happy to
get
consensus and revert it.
While I generally agree with the sentiment that this great
debate over
syntax is distracting from more important issues, one
particularly
attractive point about forcing @ on annotations is that const
(as a type
qualified) and @const (as a function annotation) become
syntactically
distinct:
const int myFunc() @const {}
vs. the current confusing syntax:
const int myFunc() const {}
Does this alone make it worth it? I'm skeptical. But I thought
it should
be pointed out regardless.
I wouldn't count `const` among functions annotations. It applies
to `this`, not to the function.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote: On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote: We could also remove @ from all of the attributes, and then that would be completely consistent, because then only UDAs will have @ on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with @nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack @ onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now. I would love this, and I would be fine with the breakage costs, speaking for myself. About the problem of add more attributes in the future: well, maybe that solution will put a rubber floor on the number of attributes that can be added, as they are already a big number really It would be interesting an implementation of both the solutions, and recompile a bunch of big projects out from the registry with dub, just to finally move the discussion on numbers instead of likely would break a lot / lot more / not so much breakage / etc ... I know the reply: help us trying out instead of writing! ;-P ;-P --- Paolo
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote: I have proposed a way that I think is a win win. Add support for non-keyword function attributes on the right hand side of a function signature. This will not break any code since it does not require removing support for using '@' for function attributes. Then later we can deprecate support for the '@' character if we feel like it's worth breaking code. I agree. This would also be a nice way to introduce dfix. And while we're at it, we can also move `const` etc. applying to the implicit `this` to the right side, too, so that this falltrap goes away, too.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic
wrote:
It's utterly confusing is the problem. I would consider it a
great disservice to all D programmers to allow this. Just
because you can doesn't mean you should. Walter has emphasize
there is absolutely no shortage of valid words. There is
however, a shortage of what a programmer can keep organized in
his head. That's the shortage you should prioritize, sir. I'm
not sure how to emphasize this anymore. We may just have to
agree to disagree.
I don't think this is confusing:
void foo() safe {
bool safe = false;
}
Using safe as both a function attribute and an identifier
doesn't seem confusing to me, however, it appears the leadership
agrees with you so I submit. Let's consider this resolved and
move on to better more interesting things:) I appreciate you
taking the time to voice your opinion and helping me understand
the arguments against this idea.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 19:07:59 UTC, Jonathan Marler wrote: On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum. This is actually a valid argument against my proposal. Thank you! lol. I don't agree with it but at least it's valid :) Your reasoning depends on how you define a keyword. You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning. I define a keyword as a word that the lexer recognizes as a keyword token. I see what you mean by saying that the word is a function attribute in one place and an identifier in another. But what's wrong with that? if I define a struct named mystruct...I could declare one like this: mystruct mystruct; It's utterly confusing is the problem. I would consider it a great disservice to all D programmers to allow this. Just because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. There is however, a shortage of what a programmer can keep organized in his head. That's the shortage you should prioritize, sir. I'm not sure how to emphasize this anymore. We may just have to agree to disagree.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 19:46:33 UTC, Andrei Alexandrescu wrote: I'd say we just drop it. It's a waste of time to talk about it. There's no proof on why the idea isn't accepted, and there's no need for one. I just wrote out of empathy. As a newcomer to language communities (including this one) I've had literally dozens of ideas on how they can be improved. All looked great to myself at the time, and of them some felt actually unassailably good. So good, in fact, that I'd attach a sense of importance to them and was convinced that explaining and advertising them well was essential, and that opponents didn't really understand their advantages. For the most part they were in reality weak ideas of a n00b, ideas of greatly overstated merit, and acknowledging that has made me better. Andrei Maybe this is a weak proposal but I don't know how to realize that unless I ask the people who oppose it to explain themselves. How else will I learn? My proposal would be a nice feature but like I've said, it's not a huge deal. There's so many more important things to worry about. However, I don't think it's unreasonable to ask someone to explain why they do or don't like something. I believe I'm being pragmatic here. What's frustrating to me isn't that my proposal wasn't accepted, its that it was so hard to communicate over such a simple issue. It took so much time and everything had to be said over and over again. But at least I have a reason why it was rejected. Now I can tell people, the leadership in D does not like to have a word be a function attribute in one place and normal identifier in another place. I would like to understand why the leadership does not want this but since there are more important things, and time is a finite resource, consider this issue let go. Thanks Andrei, I appreciate your input on this. Now if you can get that list of high priority issues out so I can know what I should be working on that would be great!
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic wrote: because you can doesn't mean you should. Walter has emphasize there is absolutely no shortage of valid words. @can @you @spot @the @contradiction @?
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 21:37:02 UTC, Daniel Kozak wrote:
Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v
19:33 +:
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak
wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guarantee it doesn't
introduce any ambiguity. Other then that, I don't see any
reason why it's a bad thing. It doesn't make the syntax
more complicated, it doesn't maker it harder to parse, I
just don't see why its bad.
Thats not possible:
@safe {
void some func() // now valid
}
safe:
void some func() // now valid
safe {
void some func() // could not be valid
}
safe:
void some func() // could not be valid
So you need more places where keyword needs to be contextual
keyword
And this is a path I am not sure we want to go.
None of those cases would valid. Non-Keyword attributes
without a '@' must be on the right hand side of the function
parameters.
void some func(); // some is not a keyword, so it is invalid
Typo I mean some_func
Oh ok. Then I'm not sure what your trying to say with your
examples. The proposal is that you could only omit the '@'
symbol if the word appeared after the function parameters.
safe void foo(); // STILL NOT VALID
void foo() safe; // NOW VALID
If it comes before, then you still need the '@'.
@safe void foo(); // STILL VALID (no change), however,
// this usage would be discouraged
Your examples do bring up a usage I hadn't thought of though. It
would be a bit odd for newcomers to use safe without an '@' in
one case and then have to include the '@' another case (the
example you provided). This makes it less appealing. Either
way, I don't think it matters since the proposal isn't acceptable
for a different reason, the leadership doesn't like the same
words to be used as function attributes sometimes and identifiers
other times.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote: Thanks Andrei, I appreciate your input on this. Now if you can get that list of high priority issues out so I can know what I should be working on that would be great! +1.000.000.000 (Finally an empathic confession for betterment!)
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote: Now if you can get that list of high priority issues out so I can know what I should be working on that would be great! It would be nice to know the priorities of the leadership, but, if you have the skills to hack the compiler, bugzilla is the place to start earning one's wings and influence. I would love it you could fix this (these) bugs. https://issues.dlang.org/show_bug.cgi?id=13372 https://issues.dlang.org/show_bug.cgi?id=12496 And I'm sure bug fixes are already pre-approved. Mike
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote: On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. yep. that is slave to the machine approach. i don't really care how hard machine should work to understand what i want. ;-) I take it you also don't care if your IDE lags for 5 seconds every time you type a character? i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me. If it really is work that the machine can do for you, why haven't you made the machine do it?
Re: accept @pure @nothrow @return attributes
Jonathan Marler via Digitalmars-d píše v St 28. 01. 2015 v 19:33 +:
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guarantee it doesn't
introduce any ambiguity. Other then that, I don't see any
reason why it's a bad thing. It doesn't make the syntax more
complicated, it doesn't maker it harder to parse, I just don't
see why its bad.
Thats not possible:
@safe {
void some func() // now valid
}
safe:
void some func() // now valid
safe {
void some func() // could not be valid
}
safe:
void some func() // could not be valid
So you need more places where keyword needs to be contextual
keyword
And this is a path I am not sure we want to go.
None of those cases would valid. Non-Keyword attributes without
a '@' must be on the right hand side of the function parameters.
void some func(); // some is not a keyword, so it is invalid
Typo I mean some_func
Re: accept @pure @nothrow @return attributes
On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. yep. that is slave to the machine approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On 1/28/2015 3:14 PM, FG wrote: On 2015-01-28 at 23:27, Walter Bright wrote: Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program. I'm quite sure I have read this very same thing not so long ago. :) I repeat it regularly! It's one of those things that one only learns the hard way, because the subtleties of it are not at all obvious. It's one of the mistakes that inexperienced language designers make again and again. One of the other mistakes they make is the great idea of implicit declaration of variables, and then ruefully have to deprecate/remove it a year or two later. (How could those experienced designers have missed this obviously great feature?!?)
Re: accept @pure @nothrow @return attributes
On Thu, 29 Jan 2015 00:29:26 +, Brian Schott wrote: On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote: that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away. That's exactly right. I gave up on using dscanner and insisted on writing dscanner instead. sorry, it wasn't obvious that i was talking not about you in personal, as i read your text as a text about jack the random, tool writer. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On Thu, 29 Jan 2015 00:33:39 +, weaselcat wrote: Uncalled for IMO, Schott's tools are great. sure. i wasn't talking about Brian in my text, that was my dumbiness that paints the text personal. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On 29/01/15 00:06, Dicebot via Digitalmars-d wrote:
I haven't said it is a breaking change on its own - but that doesn't mean it is
any considerably better migration-wise.
Yea, you're right, this isn't about whether the feature is good or not
(personally, I find Don's case for it persuasive) -- it's about having a
well-signposted procedure for changing the language.
BTW what is @return meant to achieve? I realize I'm not familiar with this
attribute.
http://wiki.dlang.org/DIP25
Oh, of course. Though it feels a bit weird, the possibility to write,
@safe ref int identity(@return ref int x) { return x; }
Re: accept @pure @nothrow @return attributes
On Wed, 28 Jan 2015 22:39:01 +, Jonathan Marler wrote: On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote: Using safe as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit. Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn@sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake. Maintain yer own parse.c like everybody else!!! That's what ketmar and I do. It is known as Free Software Freedom. Lol, you guys are hilarious. There's D1, D2 and now DOla and DKetmar! not DKetmar, it's titled Aliced. ;-) signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On 1/28/15 3:14 PM, FG wrote: On 2015-01-28 at 23:27, Walter Bright wrote: Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program. I'm quite sure I have read this very same thing not so long ago. :) We should add that stuff and what Jonathan wrote to the FAQ on the wiki. -- Andrei
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote: On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. yep. that is slave to the machine approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me. That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer. I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. Honestly, pretty anything except C# tooling suck in comparison. The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ?
Re: accept @pure @nothrow @return attributes
On Wed, 28 Jan 2015 23:36:29 +, deadalnix wrote: On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote: On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. yep. that is slave to the machine approach. i don't really care how hard machine should work to understand what i want. ;-) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me. That is a retarded mindset. It is not about how hard it is for the machine, but for tool writer. I know many people look down on java, but quite frankly, the tooling is just way better than pretty much anything else. One could argue this is because of corporate support, but other languages like C++ also have important corporate support. And still, C++ tooling mostly suck. Honestly, pretty anything except C# tooling suck in comparison. The problem of the tool writer is your problem, because any tool that isn't written is work you need to yourself. And then who's the slave to the machine ? and there are at least 4 available codebases for writing tools. for C++ there is DMD frontend. for D there is dscanner, magicport and SDC. yet instead of thinking how all that code can help me and made my life better, i should think how making my life harder will help to write great tools somewhere in the future. that is what i call retarded mindset. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On Thu, 29 Jan 2015 00:03:51 +, Brian Schott wrote: On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote: On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. yep. that is slave to the machine approach. i don't really care how hard machine should work to understand what i want. ;-) I take it you also don't care if your IDE lags for 5 seconds every time you type a character? sure, i will not use such IDE, 'cause it's fubared. yet it has nothing with great grammars: it's fubared 'cause the authors were thinking about how we can write that cool IDE so everybody will prise us instead of how we can write our IDE that it will be fast and easy. and generally speaking, IDEs sux. i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away. You know what else is easy for humans? Image and audio processing and knowing how to walk. Things that are easy for machines are hard for humans. Things that are easy for humans are hard for machines. i wonder why we don't do all our programs in machine code today. 'cause, you know, it's hard for machine to parse all that languages. so let's use machine code! yet somehow situation is horribly reversed: instead of machine helping me to do what i want, that's me who must obey the machine orders and do the work that machine can do for me. If it really is work that the machine can do for you, why haven't you made the machine do it? i did. i'm not using vanilla D, that was mentioned in this thread. and you know what? i didn't encounter *any* problems with it. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote: that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away. That's exactly right. I gave up on using dscanner and insisted on writing dscanner instead.
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 00:14:51 UTC, ketmar wrote: On Thu, 29 Jan 2015 00:03:51 +, Brian Schott wrote: On Wednesday, 28 January 2015 at 23:22:34 UTC, ketmar wrote: On Wed, 28 Jan 2015 18:54:27 +, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. yep. that is slave to the machine approach. i don't really care how hard machine should work to understand what i want. ;-) I take it you also don't care if your IDE lags for 5 seconds every time you type a character? sure, i will not use such IDE, 'cause it's fubared. yet it has nothing with great grammars: it's fubared 'cause the authors were thinking about how we can write that cool IDE so everybody will prise us instead of how we can write our IDE that it will be fast and easy. why bother when vim exists : ) i.e. i can't see why i have to deal with problems of compiler/tool/editor author. it's easy -- at least in this case -- for human to see where keywords are keywords. machine can see that too with some analysis. I'm a tool writer. If I have enough problems, I don't build the tool. The problem is now your problem. that's good. as we already have at least 4 codebases to build tools upon, and you gave up using that and insisting on writing another one, and failed... i doubt that your tool was really important or even usable. so now i don't have to try another tool just to throw it away. Uncalled for IMO, Schott's tools are great.
Re: accept @pure @nothrow @return attributes
On 1/28/15 4:11 AM, Dicebot wrote: On Tuesday, 27 January 2015 at 10:50:53 UTC, Walter Bright wrote: This change didn't break a single line in the libraries or the test suite. Yes, but it didn't also fix anything, only introduced more ways to do the same thing - without any plans for some consistent model. It is simply moving things around for the sake of marking some bugzilla report as closed - there is no consistent rationale for applying @ to attributes available. Just the fact that change can't possibly break anything doesn't mean it is can't have negative value. It _may_ have some well-though rationale behind I am failing to spot but that is not presented to users in any way. Change has been reverted. -- Andrei
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 21:41:31 UTC, Jonathan Marler wrote: Ya same thing applies to body. I'm surprised no one has given a reason why it wasn't done this way. I made a PR, but it was not too well-received: https://github.com/D-Programming-Language/dmd/pull/3227
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote: On 1/28/15 7:25 AM, Dicebot wrote: The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues. BTW what's the deal with std.meta? -- Andrei I have replied today in relevant PR with few proposals. That one is important to me so I'll keep babysitting it :)
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 21:28:51 UTC, Zach the Mystic wrote:
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler
wrote:
Assuming I understand the problem, couldn't we modify the
language grammar to support more attributes without making
them keywords? Then we can omit the '@' on future code (and
fix the old code if we want) and we don't have to litter the
language with new keywords.
I understand that doing this may be fairly complicated. This
may create some ambiguities in the grammar that would need to
be handled carefully, but if it can work I think this would be
a good option.
I think the short answer is that it's WAY too complicated for
the benefit. Also, why burden the syntax highlighter, let alone
the human reader, with ambiguities like this?
I don't agree that it's complicated, it's just not the most
beautiful thing. But it is already used in several places.
As for the syntax highlighters, any identifiers between `)` and
`{`, or `)` and `;` can be treated as function attributes, except
those that are already known to be keywords. No problem there.
And for human readers it would be even easier, because now all
function attributes have to be placed on the right side of the
declaration.
Re: accept @pure @nothrow @return attributes
On Wednesday, January 28, 2015 06:59:49 Andrei Alexandrescu via Digitalmars-d wrote: Change has been reverted. -- Andrei Yay! - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:18:44 UTC, Kagamin wrote: Same goes for possible introduction of new attributes - if syntax for those and UDA is identical, it can break code same as introducing new keywords. Same for any symbol. Do you have a solution? Long time ago I have proposed to actually define built-it attributes as UDA's in public druntime module. That way any possible conflict can be resolved relatively easy with dfix using module system disambugation (or just hard-code druntime symbols to be legal to shadow by user ones, though that sounds too much of a magic and surprise) I don't see any _vision_ behind the change, just moving bits around. It is not well-thought. @pure, @nothrow and @return are relatively obscure attributes, so if they change, it should cause minor commotion. If you want to overhaul everything, you can propose a DIP. The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues.
Re: accept @pure @nothrow @return attributes
On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote: On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote: consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects The logical conclusion from that statement would be that D semantics are fundamentally broken... Not really. For instance, we could make the attributes completely consistent by adding @ to all of them - @pure, @public, @const, etc. But that would cause inconsistencies with other languages that have many of the same attributes, and it would likely cause far more complaining than the current situation has. We could also remove @ from all of the attributes, and then that would be completely consistent, because then only UDAs will have @ on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with @nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack @ onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now. And any situation where some of the attributes have @ on them and some don't will almost certainly result in arguments about whether the rationale makes sense and whether one or more of the attributes really belongs in the camp that it's in, so how consistent it is would depend on the eye of the beholder. I don't see any of that as being something fundamentally broken with the semantics of D. It's just life with designing a programming language - especially one which isn't 100% set in stone. There are _always_ inconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be. And I think that this is one of those cases. - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 22:36:13 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote: Using safe as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit. Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn@sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake. Maintain yer own parse.c like everybody else!!! That's what ketmar and I do. It is known as Free Software Freedom. Lol, you guys are hilarious. There's D1, D2 and now DOla and DKetmar!
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler wrote: Using safe as both a function attribute and an identifier doesn't seem confusing to me, however, it appears the leadership agrees with you so I submit. Now you disappoint me. Your rebellious mindset has been poisoned by the Evil Spirit of Gn@sh. Thou shalt not give up yer own freedom to choose yer own identifiers for heavens sake. Maintain yer own parse.c like everybody else!!! That's what ketmar and I do. It is known as Free Software Freedom.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 22:28:08 UTC, Walter Bright wrote: For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. That explains why new languages make ; optional, or wait... Could it be that the language designers of new languages have realized that using ; for discrimination on line endings is fragile and tedious. Could it be that new languages define grammars that are more robust than the one used by C? Like Go? Or to put it succinctly: If legibility is dependent on a little fly shit on the screen, then the language design sure isn't optimal.
Re: accept @pure @nothrow @return attributes
On 26/01/15 22:29, Dicebot via Digitalmars-d wrote: However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary. I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change. It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit). BTW what is @return meant to achieve? I realize I'm not familiar with this attribute.
Re: accept @pure @nothrow @return attributes
On 1/28/2015 1:46 PM, Jonathan Marler wrote: Your examples do bring up a usage I hadn't thought of though. It would be a bit odd for newcomers to use safe without an '@' in one case and then have to include the '@' another case (the example you provided). This makes it less appealing. Either way, I don't think it matters since the proposal isn't acceptable for a different reason, the leadership doesn't like the same words to be used as function attributes sometimes and identifiers other times. Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program. For example, people often realize that the ; statement terminator is redundant, so they propose removing it. In trying it, however, it soon becomes clear that error message clarity, recovery, and the correct identification of the location of the error degrades substantially. So consider: void func() safe T = 7; With your proposal, an error isn't discovered until the '=' is found. But what kind of error is it? Did the user mean: void func() safe; void func() safe T; void func(); safe T = 7; Even for humans it can be hard to discern what the user meant it to be, especially if he also is not using whitespace formatting as further redundancy. Keywords and punctuation form anchors that both humans, syntax highlighters, and parsers use to add redundancy and synchronization points (which enable error recovery, such as give up on the current AST and scan forward to find the next anchor and start afresh).
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 22:58:02 UTC, Joseph Rushton Wakeling wrote: On 26/01/15 22:29, Dicebot via Digitalmars-d wrote: However my complaint is not about the change itself (though I personally disagree with Don reasoning in that issue, it is a delicate matter) but about the fact that it is again done as a casual PR and our breaking change culture does not seem to change : it is still all or nothing approach. No automatic migration tools, no easily found rationale / explanation, no posts in D.announce - just an ordinary commit. No wonder any of more notable change is considered that scary. I don't have any disagreement with your request for better reporting and public justification of decisions like this, but I don't understand why you consider it a breaking change. It's not backwards-incompatible -- the existing pure and nothrow will still work (which I just verified by building druntime and phobos with a dmd instance built from the controversial commit). I haven't said it is a breaking change on its own - but that doesn't mean it is any considerably better migration-wise. BTW what is @return meant to achieve? I realize I'm not familiar with this attribute. http://wiki.dlang.org/DIP25
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 20:11:32 UTC, Jonathan Marler wrote: Maybe this is a weak proposal but I don't know how to realize that unless I ask the people who oppose it to explain themselves. How else will I learn? I also think arguing is a very good way to learn too - but please don't forget that Walter time is extremely precious and if understanding has not been achieved quickly enough it may be better to drop the discussion for a while. Later more data may appear, context may change, Walter opinion may change (that happens!) and another small iteration will yield much more productive results.
Re: accept @pure @nothrow @return attributes
On 2015-01-28 at 23:27, Walter Bright wrote: Good language design has redundancy in it. Often people see the redundancy, and advocate removing it as noise. But the redundancy has a valuable purpose - diagnosing of errors, and offering suggestions for fixing the errors. If there was no redundancy in the language, every random sequence of bytes would be a valid program. I'm quite sure I have read this very same thing not so long ago. :)
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 21:53:29 UTC, Jonathan Marler
wrote:
On Wednesday, 28 January 2015 at 20:12:03 UTC, Zach the Mystic
wrote:
It's utterly confusing is the problem. I would consider it a
great disservice to all D programmers to allow this. Just
because you can doesn't mean you should. Walter has emphasize
there is absolutely no shortage of valid words. There is
however, a shortage of what a programmer can keep organized in
his head. That's the shortage you should prioritize, sir. I'm
not sure how to emphasize this anymore. We may just have to
agree to disagree.
I don't think this is confusing:
void foo() safe {
bool safe = false;
}
Using safe as both a function attribute and an identifier
doesn't seem confusing to me, however, it appears the
leadership agrees with you so I submit. Let's consider this
resolved and move on to better more interesting things:) I
appreciate you taking the time to voice your opinion and
helping me understand the arguments against this idea.
I invested the time because you took a very polite and civil
tone. ;) I'm glad I was able to find a way of wording it that
helped. I'm also glad Walter was able to follow it up with an
even better reasoning which speaks from deep experience, which I
could not have done. Let's move on!
Re: accept @pure @nothrow @return attributes
On 1/28/15 4:29 PM, Brian Schott wrote: I gave up on using dscanner and insisted on writing dscanner instead. Nice. Interrogative - time to promote dscanner to tools/? Brian, what do you think? -- Andrei
Re: accept @pure @nothrow @return attributes
On Thursday, 29 January 2015 at 02:23:56 UTC, Andrei Alexandrescu wrote: Nice. Interrogative - time to promote dscanner to tools/? Brian, what do you think? -- Andrei That discussion probably deserves its own thread.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote: inconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be. I think I misinterpreted what you meant to say, but if the semantics are good and sound then you should be able to device a consistent syntax for the language that is in line with current terminology in comp sci (even if that means pointing to Wikipedia for a definition of the term). That would of course mean a lot of changes to D terminology: const = readonly enum = const range=iterator pure=no global effect ubyte = byte lazy = by name etc...
Re: accept @pure @nothrow @return attributes
On 1/28/15 7:50 AM, Dicebot wrote: On Wednesday, 28 January 2015 at 15:40:31 UTC, Andrei Alexandrescu wrote: On 1/28/15 7:25 AM, Dicebot wrote: The one who wants to make a change should propose a DIP. I am personally OK with status quo for the time being - there are more important issues. BTW what's the deal with std.meta? -- Andrei I have replied today in relevant PR with few proposals. That one is important to me so I'll keep babysitting it :) Link: https://github.com/D-Programming-Language/phobos/pull/2687 Andrei
Re: accept @pure @nothrow @return attributes
On Wednesday, January 28, 2015 16:10:28 via Digitalmars-d wrote: On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote: inconsistencies and annoying points in the language. And much of the time, those inconsistencies and annoying points are forced by other aspects of the language that actually make things nice and clean. There are always tradeoffs, and often, there is no clear, right answer to how it should be. I think I misinterpreted what you meant to say, but if the semantics are good and sound then you should be able to device a consistent syntax for the language that is in line with current terminology in comp sci (even if that means pointing to Wikipedia for a definition of the term). That would of course mean a lot of changes to D terminology: const = readonly enum = const range=iterator pure=no global effect ubyte = byte lazy = by name etc... I don't see what any of that has to do with which attributes have @ on them or not. The problem is that any situation where some of the attributes have @ and some don't is going to cause some confusion, whereas putting @ on all of them would create inconsistencies with the expectations of folks coming from other languages and make porting code to D more annoying, and putting @ on none of them means that we're consistent but would mean that every time that we had to introduce a new built-in attribute (which we don't want to do much more of, but it still happens occasionally), we would either break existing code (because it would mean introducing a new keyword), or we'd have to put @ on it (making things inconsistent again, but only risking breaking UDA code, which is less prevalent). If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put @ on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. And even then, instead of getting complaints about being inconsistent with @, then we'd get even more complaints about the number of keywords that we have. There is no way to win here. No matter what we do, there will be screaming from someone. And whether the language would be objectively improved would be debatable. There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better. - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote: PLUS, this would be very simple to implement! Then I recommend you submit a pull request. Mike
Re: accept @pure @nothrow @return attributes
On 1/28/15 10:19 AM, Jonathan Marler wrote: On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote: On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote: PLUS, this would be very simple to implement! Then I recommend you submit a pull request. Mike I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it. Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST? Here's what would change - void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change - nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() @nogc; // STILL VALID (no change) @nogc myfunc(); // STILL VALID (no change) Andrei
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote: On 1/28/15 10:19 AM, Jonathan Marler wrote: On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote: On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote: PLUS, this would be very simple to implement! Then I recommend you submit a pull request. Mike I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it. Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST? Here's what would change - void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change - nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() @nogc; // STILL VALID (no change) @nogc myfunc(); // STILL VALID (no change) Andrei You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsj...@forum.dlang.org I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create context-sensitive tokens and so he would immediately dismiss it. I tried to understand what he meant by context-sensitive tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them. Walter [A context-sensitive token is] A keyword in one context and an identifier in another Anyway, I'll restate my proposal again: 1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side void foo() x; // valid SYNTAX (note: has not semantic meaning) void foo() safe; // valid SYNTAX and valid SEMANTICS 2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes. A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the '@' character from all non-keyword function attributes. Seems like a no-brainer to me.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote: On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote: PLUS, this would be very simple to implement! Then I recommend you submit a pull request. Mike I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it. I'm not sure what to do here. If I get the go ahead from Walter or anyone who would be able to merge the PR then I would happily do the work :) For some reason no one with power is addressing my proposal. Andrei? Jonathan? Dicebot? Walter? Walter I know you've been responding to most of my posts, but again, I think you are misinterpreting my proposal. For some reason it seems like you think I'm trying to make the lexer be context-sensitive. My proposal would not touch the lexer.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 15:37:28 UTC, Jonathan M Davis wrote: On Wednesday, January 28, 2015 15:16:50 via Digitalmars-d wrote: On Wednesday, 28 January 2015 at 15:11:35 UTC, Jonathan M Davis wrote: consistent. They're always going to be inconsistent in one way or another, even if it's simply because they don't match what anyone coming from other languages expects The logical conclusion from that statement would be that D semantics are fundamentally broken... Not really. For instance, we could make the attributes completely consistent by adding @ to all of them - @pure, @public, @const, etc. But that would cause inconsistencies with other languages that have many of the same attributes, and it would likely cause far more complaining than the current situation has. We could also remove @ from all of the attributes, and then that would be completely consistent, because then only UDAs will have @ on them. But the next time that we need to add a new attribute (which will hopefully be rare, but it happens sometimes - e.g. with @nogc recently), then we'd have to add a new keyword to avoid making things inconsistent, which would likely break existing code. So, more likely, we'd just tack @ onto it (which can still break code, but only UDA-specific code, so the breakage would be far more minimal), and we'd be right back where we are now. Actually we could support removing the '@' symbol from all attributes without making them keywords :) It would be quite simple to do (probably a day of work in DMD, in parser.c and a couple other places that use the code tree). At least for the attributes on the right side of the function signature. For the attributes on the left-hand side, it may make the syntax ambiguous...not sure. The idea is we allow non-keyword identifiers to be used as function attributes (on the right hand side).
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 16:39:51 UTC, Jonathan M Davis wrote: I don't see what any of that has to do with which attributes have @ on them or not. As I said, I misinterpreted what you wrote. You came through as being overly defensive when it comes to accepting a syntax with bad usability. It does affect both usability and marketing what the syntax looks like and whether the terminology is consistent with definitions. It sends signals about the design and the implementation that will be picked up by people who evaluate the language. For instance, the syntax of Cray's Chapel sends strong signals of the designers know what they are doing, so I am more inclined to give it a spin... If we could start from scratch and guarantee that no new attributes would ever be introduced, then we could just put @ on none of them and thus be fully consistent. But we can't start from scratch, and we can't guarantee that there will be no new attributes. Of course you can, but you need to get the semantics right first. There may be set of changes that would ultimately be better enough that they'd be worth making - where the pros are generally considered to outweigh the cons - but we'll be stuck with the cons regardless, and I seriously question that any change to attribute names is enough of an improvement to merit the code breakage that it would cause, even if it were objectively better. That's one viewpoint. An alternative viewpoint is that when/if D has reached a stable state, then it is a relatively small task for someone (1-2 people) to fork the language, design a new grammar and implement a parser for it that maps to the compiler internals. It is not a big project to write a new parser if the rest is stable. Syntactical code breakage is not a real problem, since: 1. the D corpus is small 2. transpilers can do source-to-source compilation 3. a compiler can include multiple parsers for the same language semantics Except... string mixins.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. How is somethign that's a built-in attribute one place and an identifier in another not context sensitive. Walter said that `exit`, `C++`, i.e. `scope(exit)`, `extern (C++)` etc. were never keywords, but I disagree. They are indeed context sensitive keywords. They have wisely been kept to a minimum. They are just confusing to reason about, except in the most strictly confined places, where they are now. I think that's why they're out of the question. They have wisely been kept to a minimum. This is actually a valid argument against my proposal. Thank you! lol. I don't agree with it but at least it's valid :) Your reasoning depends on how you define a keyword. You seem to be defining a keyword in terms of an identifier that is recognized by the compiler to have a special meaning. I define a keyword as a word that the lexer recognizes as a keyword token. I see what you mean by saying that the word is a function attribute in one place and an identifier in another. But what's wrong with that? if I define a struct named mystruct...I could declare one like this: mystruct mystruct; The first appearance is a type and the second is an identifier. I'm sure there are many examples of this in the language. Anyway, I disagree with your conclusion, however, I agree that this could be a concern.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 18:54:29 UTC, Zach the Mystic wrote: I think a keyword is a keyword is a keyword. If it's a keyword to the right it should be one everywhere. That's a reserved word. A reserved word cannot be used as an identifier. A keyword is a phrase that has a special semantic meaning in a context. That does not make it context sensitive if the language can be recognized by a context free grammar... Confusing? I guess... Some languages would allow this: if if = 0 then ... fi, it is not context sensitive because it can be recognized by a CFG. The first if is a keyword. The second if is an identifier.
Re: accept @pure @nothrow @return attributes
On Wednesday, 28 January 2015 at 19:29:25 UTC, Daniel Kozak wrote:
I would think the reason would be it could make the grammar
ambiguous. That's why I proposed it only be valid on the
right hand side of the function to guarantee it doesn't
introduce any ambiguity. Other then that, I don't see any
reason why it's a bad thing. It doesn't make the syntax more
complicated, it doesn't maker it harder to parse, I just don't
see why its bad.
Thats not possible:
@safe {
void some func() // now valid
}
safe:
void some func() // now valid
safe {
void some func() // could not be valid
}
safe:
void some func() // could not be valid
So you need more places where keyword needs to be contextual
keyword
And this is a path I am not sure we want to go.
None of those cases would valid. Non-Keyword attributes without
a '@' must be on the right hand side of the function parameters.
void some func(); // some is not a keyword, so it is invalid
Re: accept @pure @nothrow @return attributes
On 1/28/15 10:37 AM, Jonathan Marler wrote: On Wednesday, 28 January 2015 at 18:27:34 UTC, Andrei Alexandrescu wrote: On 1/28/15 10:19 AM, Jonathan Marler wrote: On Wednesday, 28 January 2015 at 17:52:56 UTC, Mike wrote: On Wednesday, 28 January 2015 at 17:41:54 UTC, Jonathan Marler wrote: PLUS, this would be very simple to implement! Then I recommend you submit a pull request. Mike I would but Walter said no. I'm certain he misunderstood my proposal and I tried to explain it to him but I couldn't get him to address it. Was that the proposal leading to this state of affairs (quoting from your post on 2015/01/26 16:05 PST? Here's what would change - void myfunc() nogc; // VALID (Only if this proposal is accepted) void myfunc() safe; // VALID (Only if this proposal is accepted) Here's what WOULD NOT change - nogc myfunc(); // STILL INVALID: invalid unless it can be verified // that this wouldn't result in ambiguity // in the grammar void myfunc() @nogc; // STILL VALID (no change) @nogc myfunc(); // STILL VALID (no change) Andrei You can follow this thread: http://forum.dlang.org/post/fxbqqecgqdhrepxsj...@forum.dlang.org I explained my proposal 3 or 4 times but each time Walter seemed to be misunderstanding my proposal saying it was going to create context-sensitive tokens and so he would immediately dismiss it. I tried to understand what he meant by context-sensitive tokens because my proposal didn't have anything to do with them (at least my definition of them), but even after he defined them my proposal clearly does not create them. Walter [A context-sensitive token is] A keyword in one context and an identifier in another Anyway, I'll restate my proposal again: 1. Modify the SYNTAX of function to allow it to be decorated with IDENTIFIER tokens on the right hand side void foo() x; // valid SYNTAX (note: has not semantic meaning) void foo() safe; // valid SYNTAX and valid SEMANTICS 2. Modify the code that interprets the syntax tree to recognize these identifiers as function attributes. A simple solution that would allow us to standardize where we put the function attributes and allow us to remove the '@' character from all non-keyword function attributes. Seems like a no-brainer to me. That's not a misunderstanding. Your proposal has been understood. It can be made to work. That doesn't necessarily make it desirable. I don't think it's particularly helpful and Walter is against it, so simply put it won't happen. Let it go. Thanks for it and keep the good ideas coming. -- Andrei
