Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
On 09.03.2012 11:58, Jonathan M Davis wrote: On Friday, March 09, 2012 11:53:51 Dmitry Olshansky wrote: The goal is to make std.algorithm general when it comes to UTF-x ranges, VLE range seems a best suited abstraction level so far. Other things like base64 encoded stuff could be there, though it needs some thought. My point is that it doesn't make sense to try and design the lexer around an as yet undesigned and unused VLE range. Interface-wise, yes. Either the lexer should just move forward with how things are currently done and then be adjusted later to use VLE ranges once they've been sorted out, or it should be postponed until VLE ranges are sorted out. Or it could use whatever abstraction it needs internally, providing (for starters) (w|d)string interface. -- Dmitry Olshansky
Re: D port of dmd: Lexer, Parser, AND CodeGenerator fully operational
Now, there is interest in having a D parser and lexer in Phobos. I don't know if your version will fit the bill (e.g. it must have a range-based API), but we need one at some point. The original idea was to more or less directly port dmd's lexer and parser with some adjustments to the API as necessary (primarily to make it range-based). But no one has had the time to complete such a project yet (I originally volunteered to do it, but I just haven't had the time). I did wrote a complete D lexer some time ago. I'd consider it a little too CTFE heavy for phobos though. https://gist.github.com/1255439 - generic lexer generator https://gist.github.com/1262321 - D lexer
Re: Our second mentor: Alex Rønne Petersen
On Sunday, 4 March 2012 at 23:31:41 UTC, deadalnix wrote: Le 04/03/2012 22:45, Andrei Alexandrescu a écrit : On 3/4/12 3:08 PM, deadalnix wrote: Le 04/03/2012 21:52, Andrei Alexandrescu a écrit : Please join me in welcoming Alex Rønne Petersen as a mentor! We believe he will bring great expertise and value to our ranks. Andrei What does that imply in practice ? You mean what a mentor's responsibilities are? Refer to the GSoC 2012 FAQ: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs Andrei Tak Tak? Are you scandinavian? /Jonas
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 07/03/2012 11:08, Timon Gehr a écrit : On 03/06/2012 10:30 PM, deadalnix wrote: auto helps too. This remark was explicitly about _Java_ code style. 1/ We are not in the java's newsgroup. 2/ In java, the tooling is that awesome that you don't need to type most of it anyway.
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 07/03/2012 03:42, H. S. Teoh a écrit : On Tue, Mar 06, 2012 at 09:18:13PM -0500, Nick Sabalausky wrote: [...] But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; +1. +1 if it can be used as a property. Which require explicit modification of dur.
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 07/03/2012 02:00, F i L a écrit : I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#. The problem with making any change to Phobos is backwards compatibility. We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so.
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 07/03/2012 04:05, Bill a écrit : F i L Wrote: I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#. The problem with making any change to Phobos is backwards compatibility. So, what if there was a way to satisfy both parties and keep backwards compatibility? Is there any compelling reason why simply wrapping Phobos into a different format would be such bad thing? Meaning: // system.io private import std.stdio; alias write Write; alias writeln WriteLine; // etc... Besides keeping things in-sync and error messages referring to the original function names (which could be amended), I don't see why such a library couldn't be written as a way to make the language easier to swallow to potential D users coming from Java/C#. Microsoft used similar tactics with J#/F# to help the Java/Python folks adapt their code to .NET. good idea ! can refer to the java c # naming specification, to work out d own naming specification good luck�� Bill This is an horrible idea. That make code easier to write, and harder to read. Some language beat D at this game, consider PERL, which is close to write only.
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 07/03/2012 04:46, Nick Sabalausky a écrit : Adam D. Ruppedestructiona...@gmail.com wrote in message news:bwqkuqhyiygvgqswi...@forum.dlang.org... On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote: I don't understand this complaint at all. curr is an incredibly common abbreviation for current. Is it your *first* choice? In the general case, it frequently is for me. In the specific case of Clock.curr(ent)?Time, I'm equally happy either way. Although I agree with whoever it was (Brad?) that said Clock.now() would be even better. The usage of current is often a smell that is saying « I had no clue how to name that, so I did name it using current ». Meaningful name are what we should look for. And now is meaningful.
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 07/03/2012 06:54, H. S. Teoh a écrit : On Wed, Mar 07, 2012 at 04:42:50AM +0100, Adam D. Ruppe wrote: On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote: I don't understand this complaint at all. curr is an incredibly common abbreviation for current. Is it your *first* choice? My first choice is actually 'cur', but I'm OK with 'curr'. I've consistently used 'cur' for 'current' for at least the last decade and a half, probably more. Don't want to be mean, but this isn't about what whoever is used to use. I know many people in non English speaking country that are used to name things using local language. SO what, do we should also consider « courrant », « corrente » and so on ? Note that I'm not advocating for naming in local languages. This is a dumb idea, but anyway, this is used in the industry quite a lot. So ? Shouldn't English should be the default, international language ? And so, English words isn't better than a double translation ?
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 09:39:23 deadalnix wrote: Le 07/03/2012 04:46, Nick Sabalausky a écrit : Adam D. Ruppedestructiona...@gmail.com wrote in message news:bwqkuqhyiygvgqswi...@forum.dlang.org... On Wednesday, 7 March 2012 at 03:24:23 UTC, Jonathan M Davis wrote: I don't understand this complaint at all. curr is an incredibly common abbreviation for current. Is it your *first* choice? In the general case, it frequently is for me. In the specific case of Clock.curr(ent)?Time, I'm equally happy either way. Although I agree with whoever it was (Brad?) that said Clock.now() would be even better. The usage of current is often a smell that is saying « I had no clue how to name that, so I did name it using current ». Meaningful name are what we should look for. And now is meaningful. It's no more meaniful than currTime. It's just another name for the same thing. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 09:33:20 deadalnix wrote: Le 07/03/2012 02:00, F i L a écrit : I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#. The problem with making any change to Phobos is backwards compatibility. We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so. We're not changing symbol names without a good reason. Yes, there's a deprecation process that allows us to change them if we need to, but it's still disruptive. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 09/03/2012 05:42, H. S. Teoh a écrit : On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common.
Re: Multiple return values...
On 9 March 2012 02:59, Mantis mail.mantis...@gmail.com wrote: 09.03.2012 2:23, Manu пишет: On 9 March 2012 01:56, Mantis mail.mantis...@gmail.com mailto: mail.mantis.88@gmail.**com mail.mantis...@gmail.com wrote: [...] Is tuple required to be anonymous struct? I thought it's implementation details that may be done the other way if tuples implemented in language rather then library. There's another problem with non-named return values, as this: auto (sin_a, cos_a) = sincos( a ); is not equivalent to this: auto (cos_a, sin_a) = sincos( a ); I can't imagine a syntax that's non-destructive to the existing grammar where order is not important, but order would be clearly stated in the auto-complete pop-up, and in the reference. Also mismatching types would throw errors. You can't mess with the parameters order in this case: http://dl.dropbox.com/u/**36715190/Images/par_order.jpghttp://dl.dropbox.com/u/36715190/Images/par_order.jpg Is it impossible to make efficient multiple return values without the need to trade off the help from tools? Eh? How so? Visual studio show's the return value and function name in the same tooltip (not just the argument list as your image shows). Tools may need to tweak their popup if they don't present the return values already. Also, tools can do the usual red-squiggly underline thing on return assignments with mismatching result count or types easily. On 9 March 2012 03:24, bearophile bearophileh...@lycos.com wrote: I understand. But in other languages tuples are used for such purpose, so there is some risk people will think of them as a third kind of tuples, despite they are a different thing. I really don't think so. The only language I know of that behaves like you say is lua (oh, and python?); scripting languages, not too interested with ABI expression, and bear virtually no relation whatsoever to any c-like language. I think the comparison might be drawn to something more like Go. Octave does it with an interesting syntax, but these are not compatible with D in a non-breaking way. What kind of syntax do you suggest? I detailed my initial idea in my post prior to yours, but perhaps other more interesting syntax might also exist: I imagine something like: auto (x, y) = func(); // specify auto for all results? float (x, y) = func(); // specify explicit type for all results? (int x, float y) = func; // explicitly type each result? int x; ... (x, float y) = func(); // assign to predeclared variable(/s)? (x, , z) = func(); // ignore the second result value, intuitive and visible (elimination of the second result's code path) I'm sure other more bizarre syntax could be possible too to help reduce bracket spam. Ideas from things like lambda syntax?
Re: Arbitrary abbreviations in phobos considered ridiculous
On 09/03/12 05:54, H. S. Teoh wrote: On Thu, Mar 08, 2012 at 07:07:04PM -0500, Nick Sabalausky wrote: [...] Heh one of us should hack up DMD to produce a NihonD, using (or at least allowing) kanji instead of the kanas wherever appropriate :) That'd be both fun to make and to use. [...] On another note, I've always dreamt about a language where keywords are i18n'd. Every keyword has an equivalent in every language (well, up to the languages currently supported, of course), and can be used interchangeably. Support for Arabic and Hebrew would be tricky because of the right-to-left thing, but cool if it can be pulled off. Even cooler would be to support top-to-bottom, right-to-left for traditional Chinese writing. Don't know how it would interoperate with code written in English, though. :-P (Though it would mainly be a display issue, since at the Unicode level everything is just an unambiguous sequence of characters.) T Ugh. VBA does that. It's just horrid. I used to write the VBA code on my laptop, in English. But I could only test it on a German PC. If I found a small bug, I'd fix it on the test system. Problem is, when you look at the code, the keywords and built-in functions have all changed. Trying to guess which German word the keyword changes to is a nightmare, especially when there are abbreviations. Eg, AVG() -- MITTELWERT().
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 09:55:50 deadalnix wrote: Le 09/03/2012 05:42, H. S. Teoh a écrit : On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common. Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing? Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 01:07:57 Jonathan M Davis wrote: On Friday, March 09, 2012 09:55:50 deadalnix wrote: Le 09/03/2012 05:42, H. S. Teoh a écrit : On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common. Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing? Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different. If you want to read Walter's arguments on the matter as well as more detailed discussion on this particular case, then just read the comments in the now closed pull requested for adding secs: https://github.com/D-Programming-Language/druntime/pull/173 - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 09/03/2012 10:07, Jonathan M Davis a écrit : On Friday, March 09, 2012 09:55:50 deadalnix wrote: Le 09/03/2012 05:42, H. S. Teoh a écrit : On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common. Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing? Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different. - Jonathan M Davis This is not alias. This is about accepting template parameters. The actual isn't very consistent anyway (seconds, but usecs ?).
Re: Arbitrary abbreviations in phobos considered ridiculous
On 08/03/2012 21:08, Matt Soucy wrote: American does have the benefit of being more pronounceable, though...I just tried to pronounce that oohz-ee-an, us-ee-an, etc and they all sound odd. I say it as Yu-Essian, it gets a lot of funny looks even after I have explained ^^ A...
Re: Arbitrary abbreviations in phobos considered ridiculous
On 09/03/2012 00:07, Nick Sabalausky wrote: But yea, it would be interesting to see a langauge that was based on something very different. A German-based one would be fun. Or even better, something that doesn't use the Latin alphabet, like Japanese or Hebrew or Russian. Or Swahili (which is an awesome-sounding language). Designing/using an Arabic (right-to-left, IIRC) programming language would be a great mind-fuck. Heh one of us should hack up DMD to produce a NihonD, using (or at least allowing) kanji instead of the kanas wherever appropriate :) That'd be both fun to make and to use. I recall, but have no idea where to start looking for it, reading an article about why English is the only language that works for programming. I think the jist was that its archaic rules allowed any syntax needed to be shoe-horned into place. After all, grammatical, everything Yoda says, is. Or perhaps it is a relic of lost colonialism that English is good for listing instructions. Having said that, I'd love to see a programming language that was based on Welsh/Gaelic/Irish/Cornish/Occitan/Catalan, they make for beautiful sounding poetry (no idea what they mean though) and I have a theory that poetic languages would be good for programming in. Also I think I remember there being a Greek version of C, but it never took off even in Greece. A...
Annotations or custom attributes
Does D have a nice way to add annotations or custom attributes to entities? In Java/C# for example, it is common to annotate things with useful compile time information. I'd like to be able to do that in D on occasion. For instance, I'm serialising some struct/class using reflection to some text format, but there are a couple of members in a particular class that I don't want to be written. A nice solution might be that I could annotate various members: @DoNotSerialise int thing; ... or something along those lines, whatever concept you want to apply, which I could then inspect in static if() logic to produce some requested additional behaviour. This is a trivial example, but looking at C#/Java, you can see how many useful things can be done with this sort of system. How would it be done currently?
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 10:28:12 deadalnix wrote: Le 09/03/2012 10:07, Jonathan M Davis a écrit : On Friday, March 09, 2012 09:55:50 deadalnix wrote: Le 09/03/2012 05:42, H. S. Teoh a écrit : On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common. Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing? Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different. - Jonathan M Davis This is not alias. This is about accepting template parameters. The actual isn't very consistent anyway (seconds, but usecs ?). It amounts to the same thing, and core.time and std.datetime are as consistent as they're going to get. seconds are _always_ seconds, and _no_ units greater than seconds are ever abbreviated. Only the sub-second units are abbreviated. And they're abbreviated only because they would have been way too long otherwise. And making seconds secs would create even _more_ inconsistencies. Just read the discusion in the pull request: https://github.com/D-Programming-Language/druntime/pull/173 - Jonathan M Davis
Re: [OT] American versus British spelling and pronunciation
On Thu, 08 Mar 2012 23:27:18 -, Nick Sabalausky a@a.a wrote: But anyway, to me, rolling Rs seems pretentious It seems Spanish to me ;) Get your yappy 'perro' off my leg! LOL :) R -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Annotations or custom attributes
On 09-03-2012 11:56, Manu wrote: Does D have a nice way to add annotations or custom attributes to entities? Unfortunately, no. In Java/C# for example, it is common to annotate things with useful compile time information. I'd like to be able to do that in D on occasion. Yes. This is a very needed feature. For instance, I'm serialising some struct/class using reflection to some text format, but there are a couple of members in a particular class that I don't want to be written. A nice solution might be that I could annotate various members: @DoNotSerialise int thing; ... or something along those lines, whatever concept you want to apply, which I could then inspect in static if() logic to produce some requested additional behaviour. This is a trivial example, but looking at C#/Java, you can see how many useful things can be done with this sort of system. How would it be done currently? Probably not at all (to my knowledge anyway). -- - Alex
Re: Arbitrary abbreviations in phobos considered ridiculous
Le 09/03/2012 11:58, Jonathan M Davis a écrit : This is not alias. This is about accepting template parameters. The actual isn't very consistent anyway (seconds, but usecs ?). It amounts to the same thing, and core.time and std.datetime are as consistent as they're going to get. seconds are _always_ seconds, and _no_ units greater than seconds are ever abbreviated. Only the sub-second units are abbreviated. And they're abbreviated only because they would have been way too long otherwise. And making seconds secs would create even _more_ inconsistencies. Just read the discusion in the pull request: https://github.com/D-Programming-Language/druntime/pull/173 - Jonathan M Davis Yes, this is consistent in this regards. What isn't consistent is to choose to not abbreviate seconds, hours, minutes, but to abbreviate nsecs, usecs. Considering the existing codebase, I think the best option now is to allow both. In an ideal worlds, I would argue that we go for all abbreviation or none. I did read, the topic. Interesting, but I think walter isn't consistent with its own argumentation on point 6. Consider that in french, « dur » means « hard ». Even associated with keyword like dlang, this is 100% ungooglable. He is also plain wrong on point 5. No progress is made for experienced D programmers (arghuably, it is a step backward for such people), but for newcomers it is. At some point, we will have to consider newcomers as an important subject. I do agree with most other points, this is not good to have 2 names for the same thing. However, the actual names are confusing, it seems that this thread make it pretty much clear. A lot of people have trouble with dur and seconds. Now, instead of changing everything that exists, lets make secs available. This isn't perfect, but it is the consequence of the inconsistency of naming convention that occurs (between sub seconds units and other units) in a first place, not the ideal case.
Re: Annotations or custom attributes
On 2012-03-09 11:56, Manu wrote: Does D have a nice way to add annotations or custom attributes to entities? Unfortunately no. In Java/C# for example, it is common to annotate things with useful compile time information. I'd like to be able to do that in D on occasion. For instance, I'm serialising some struct/class using reflection to some text format, but there are a couple of members in a particular class that I don't want to be written. A nice solution might be that I could annotate various members: @DoNotSerialise int thing; ... or something along those lines, whatever concept you want to apply, which I could then inspect in static if() logic to produce some requested additional behaviour. This is a trivial example, but looking at C#/Java, you can see how many useful things can be done with this sort of system. How would it be done currently? Yeah, it would be so nice to have. As a workaround you can mixin some code, variables or similar in a class/struct. For serialization you could use my library Orange, which already supports this. You can have a look at the NonSerialized template at: http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializable.html https://github.com/jacob-carlborg/orange -- /Jacob Carlborg
Re: Arbitrary abbreviations in phobos considered ridiculous
PS: just to be clear, I do agree with most of what you said here : https://github.com/D-Programming-Language/druntime/pull/173
Re: The One-Letter Nested Function - a sample article for some kind of
On 13-2-2012 15:14, bearophile wrote:
Zach the Mystic:
void setRandomColorPair( ref ColorPair cp )
{
import std.random;
ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }
Where possible it's good to add static to nested functions:
Why?
Re: Annotations or custom attributes
On 09.03.2012 14:56, Manu wrote: Does D have a nice way to add annotations or custom attributes to entities? There is a potential for them. At least technically everything with @ in front of it was supposed to be an annotation (like @property). I think it's just, sort of, reserved for future. [...] -- Dmitry Olshansky
Re: Arbitrary abbreviations in phobos considered ridiculous
On 3/9/12 6:17 AM, Jonathan M Davis wrote: On Friday, March 09, 2012 01:07:57 Jonathan M Davis wrote: On Friday, March 09, 2012 09:55:50 deadalnix wrote: Le 09/03/2012 05:42, H. S. Teoh a écrit : On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. Why it isn't possible to support both ? And miliseconds as well a usecs ? This make sense, as long as they are both common. Because it creates needless aliases. Now you have to remember _both_ of them, because they're both going to be used in code. And people reading code will wonder what the difference is. It just adds more confusion to the library and reduces its cohesiveness and consistency. It works far better to just have the one symbol. Isn't that one of the major complaints about PHP? That it has a ton of different ways to do the same thing? Walter and Andrei are very much against having aliases in the library just to create different names for the same stuff. And adding more options for the time units argument to the templates that use them is basically the same thing. So, we're not going to add such aliases. It's not like it's all that hard to learn the library, and none of the names are horribly wrong. They just don't happen to be the names that you prefer. You have to learn the names of the symbols of _any_ library that you use. This is no different. If you want to read Walter's arguments on the matter as well as more detailed discussion on this particular case, then just read the comments in the now closed pull requested for adding secs: https://github.com/D-Programming-Language/druntime/pull/173 - Jonathan M Davis Sample Ruby session: irb ruby-1.8.7-p352 :001 [1, 2, 3].count = 3 ruby-1.8.7-p352 :002 [1, 2, 3].length = 3 ruby-1.8.7-p352 :003 [1, 2, 3].size = 3 I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders why didn't he wrote 'length' instead of 'size', because the meaning is clear.
Re: Annotations or custom attributes
Okay, so the consensus is, it doesn't currently exist, but there is no real resistance, and is tentatively planned? Sounds good to me. On 9 March 2012 15:42, Dmitry Olshansky dmitry.o...@gmail.com wrote: On 09.03.2012 14:56, Manu wrote: Does D have a nice way to add annotations or custom attributes to entities? There is a potential for them. At least technically everything with @ in front of it was supposed to be an annotation (like @property). I think it's just, sort of, reserved for future. [...] -- Dmitry Olshansky
Re: Creating dynamic arrays of known size
Isn't this just as good? Key[] keys; keys.reserve(num_keys) foreach (key; keys_in_aa) keys ~= key;
Re: Multiple return values...
On 03/09/2012 01:23 AM, Manu wrote: I can imagine syntax using parentheses, but I don't think I'm qualified to propose a robust syntax, I don't know enough about the finer details of the grammar. Perhaps if other people agree with me, they could present some creative solutions to the syntax? I imagine something like: auto (x, y) = func(); // specify auto for all results? float (x, y) = func(); // specify explicit type for all results? (int x, float y) = func; // explicitly type each result? This works, and Kenji Hara has already implemented appropriate parser extensions. int x; ... (x, float y) = func(); // assign to predeclared variable(/s)? (x, , z) = func(); // ignore the second result value (elimination of the second result's code path) Those two would work, but (x,y) = func(); conflicts with the comma operator. (I'd prefer (,) to be a tuple constructor though.)
Re: The One-Letter Nested Function - a sample article for some kind of
On 03/09/2012 02:29 PM, Jos van Uden wrote:
On 13-2-2012 15:14, bearophile wrote:
Zach the Mystic:
void setRandomColorPair( ref ColorPair cp )
{
import std.random;
ubyte u(int a, int b) { return cast(ubyte) uniform(a,b); }
Where possible it's good to add static to nested functions:
Why?
Because then you don't have to rely on the compiler to optimize away the
unneeded context pointer parameter. It should be able to do that though.
I don't know if DMD is.
Re: inout and function/delegate parameters
On Thu, 08 Mar 2012 17:43:34 -0500, Stewart Gordon smjg_1...@yahoo.com wrote: On 08/03/2012 19:38, Steven Schveighoffer wrote: snip Yes, I couldn't really find that. It does specifically say casting away const and then modifying is invalid, but it does not say anything about if you know the underlying data is mutable. But again, this is the point I was trying to make, we are casting away a const-like attribute and modifying the data. snip No more than we are already doing with the inout return. Except that technique has been approved by Walter and included in the language. -Steve
Re: Creating dynamic arrays of known size
On Fri, 09 Mar 2012 01:59:34 -0500, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, March 08, 2012 22:05:57 H. S. Teoh wrote:
On Thu, Mar 08, 2012 at 09:13:13PM -0800, H. S. Teoh wrote:
So, I'm plodding along with my AA implementation that *hopefully* will
eventually reach the point where it's usable enough to be dropped into
druntime. I'm writing .keys and .values right now, and wondering
what's
the best way to construct the returned array.
Obviously, using =~ repeatedly is a bad idea, since we already know
the resulting array size. Would this be the best way to do it?
Key[] keys;
keys.length = num_keys;
for (size_t i=0; i num_keys; i++) {
keys[i] = ...;
}
Looking at aaA.d, I see that _aaKeys calls gc_malloc directly and sets
BlkAttr.NO_SCAN. Should I just copy this code?
[...]
Another problem: if Key is a const/immutable type, then keys[i] is
immutable, so the keys can't be copied into the resulting array. I tried
inout but it doesn't seem to be good enough, because individual array
elements need to be assigned to, which violates const/immutable, even
though we're really just copying const/immutable data here.
I see two options. Allocate the entire array, set the length to 0, and
use
assumeSafeAppend (or maybe the function that it uses, since
assumeSafeAppend
is in _object.d) so that appending doesn't cause reallocations, or
create the
array as mutable and then cast it to the appropriate type.
1.
auto keys = new Key[](num_keys);
keys.length = 0;
assumeSafeAppend(keys);
for(i; 0 .. num_keys)
keys ~= ...;
2.
auto keys = new (Unqual!Key)[](num_keys);
foreach(ref key; keys)
key = ...;
auto actualKeys = cast(Key[])keys;
Use the second method. This is low-level runtime code, it should be as
fast as possible. Casting is OK as long as it's justified.
-Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On 03/08/2012 10:07 PM, H. S. Teoh wrote:
On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:
On 3/8/12 7:27 AM, Timon Gehr wrote:
On 03/08/2012 03:14 AM, Ary Manzana wrote:
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
Or I could have written:
Hash[
Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
).map{|x| [x.id, x]}
]
No abbreviation at all,
uniq.
[...]
And ids.
T
Is that in some standard library interface?
Re: Arbitrary abbreviations in phobos considered ridiculous
On Wed, 07 Mar 2012 17:11:43 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: On Wed, 07 Mar 2012 10:25:32 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: On Wed, 07 Mar 2012 08:47:48 -0500, Steven Schveighoffer schvei...@yahoo.com wrote: I'll see if I can do a pull request. Almost done, need to test: https://github.com/schveiguy/druntime/commit/cf9d1ba4f5498c447d91497cb5edbd735d2b4c7e Actually cleans up a lot of the template constraints too... https://github.com/D-Programming-Language/druntime/pull/173 https://github.com/D-Programming-Language/phobos/pull/483 These have been rejected, so I guess you're stuck with seconds instead of secs :( -Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
YOn 03/09/2012 09:12 AM, deadalnix wrote: Le 07/03/2012 11:08, Timon Gehr a écrit : On 03/06/2012 10:30 PM, deadalnix wrote: auto helps too. This remark was explicitly about _Java_ code style. 1/ We are not in the java's newsgroup. 2/ In java, the tooling is that awesome that you don't need to type most of it anyway. 1/ We are not in the tooling's newsgroup. 2/ I am aware of that.
Re: dereferencing null
On 03/09/2012 01:43 AM, bearophile wrote: Adam D. Ruppe: D rox the web (and has for a while). (Oh, you are starting to copy Andrei talk style now :-) The birth of community words, idioms and sub-languages is a very common thing, sociology studies such things a lot). But there's always some space for improvements :-) In D.learn there is a thread titled 0 negative loop condition bug or misunderstanding on my part: http://forum.dlang.org/thread/tbsvfbotcupussmet...@forum.dlang.org Web coders are not going to appreciate such traps. I think integral bound tests at run-time are able to catch part of those problems. Bye, bearophile Comparing signed/unsigned is perfectly reasonable. This is what causes the problem discussed in D.learn: assert(-10U); // fail.
Re: [OT] Smoking sections (Was: Arbitrary abbreviations in phobos considered ridiculous)
On Thu, Mar 08, 2012 at 11:01:21PM -0800, Jonathan M Davis wrote: On Friday, March 09, 2012 01:45:13 Nick Sabalausky wrote: [...] That's one great thing about Ohio: A few years back we had a state law passed here (by public vote! I had been convinced it wouldn't pass) prohibiting smoking in workplaces and public buildings/businesses. That includes, of course, restaurants. No more smoking sections! I feel so spoiled now when I travel to a state that still has public indoor smoking. It's like stepping back into the stone age. I'm from California, where it's been illegal to smoke in restaurants for 15+ years now, and it always shocks me to see a smoking section in restaurants in other states. It's not something that I even think about. [...] You think it's bad to have a smoking section in restaurants? Back in the old days (I'm pretty sure it isn't the case anymore -- at least I sure hope not!), Japan Airlines used to have a smoking section in the cabin. I was on a *transatlantic* flight like that once. You cannot imagine my relief after the flight was finally over. T -- Give me some fresh salted fish, please.
Re: Annotations or custom attributes
Manu: Okay, so the consensus is, it doesn't currently exist, but there is no real resistance, and is tentatively planned? Sounds good to me. As far as I know there are no concrete ideas yet for the semantics and precise usage of this feature. And I think there are different ideas regarding what this feature has to do (example: I think of it as as a user-defined extension of the type system. Other people think of this feature more like the C#, Scala or Java ones). So if you want this feature to happen and you have good ideas, then I suggest you to write down a little concrete proposal of definition syntax/semantics (implementation isn't needed now). Bye, bearophile
Re: Multiple return values...
On Fri, Mar 09, 2012 at 03:27:14PM +0100, Timon Gehr wrote: On 03/09/2012 01:23 AM, Manu wrote: [...] int x; ... (x, float y) = func(); // assign to predeclared variable(/s)? (x, , z) = func(); // ignore the second result value (elimination of the second result's code path) Those two would work, but (x,y) = func(); conflicts with the comma operator. (I'd prefer (,) to be a tuple constructor though.) Just out of curiosity, *why* does D have a comma operator? It's one of those obscure things about C that can be really, really, nasty if you're unaware of it. And C++ makes it worse by making the comma operator *overloadable*. T -- It's amazing how careful choice of punctuation can leave you hanging:
Re: dereferencing null
Timon Gehr: Comparing signed/unsigned is perfectly reasonable. Right, but only if the numbers don't get implicit reinterpretations to other intervals, as C/C++/D do. Bye, bearophile
Re: Multiple return values...
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch wrote: On 03/09/2012 01:23 AM, Manu wrote: I can imagine syntax using parentheses, but I don't think I'm qualified to propose a robust syntax, I don't know enough about the finer details of the grammar. Perhaps if other people agree with me, they could present some creative solutions to the syntax? I imagine something like: auto (x, y) = func(); // specify auto for all results? float (x, y) = func(); // specify explicit type for all results? (int x, float y) = func; // explicitly type each result? This works, and Kenji Hara has already implemented appropriate parser extensions. int x; ... (x, float y) = func(); // assign to predeclared variable(/s)? (x, , z) = func(); // ignore the second result value (elimination of the second result's code path) Those two would work, but (x,y) = func(); conflicts with the comma operator. (I'd prefer (,) to be a tuple constructor though.) You think so? Within that context, I would think the coma could be reinterpreted however it likes. The usual use of the coma operator makes no sense in this context? These last 2 examples are what I see as being the most important part, and the precise reason that it SHOULDN'T be a tuple. The ability to directly assign results to explicit (existing) variables, and to ignore some/all of the return values, is a fundamental feature of the *concept* of return values universally. I see this as basically the whole point. Another example: (someStruct.x, y, , int err) = func(); In this example, I assign the x result to a struct, y assigns to some existing local, we ignore z because we can (visually states our intent, would be hidden through use of a tuple), and we declare an int to capture a potential error in place. If we were abusing the tuple syntax, we would need additional lines following the call to assign the rvalues out to their appropriate places, which is unnecessary spaghetti.
Re: The One-Letter Nested Function - a sample article for some kind of
Jos van Uden: On 13-2-2012 15:14, bearophile wrote: Where possible it's good to add static to nested functions: Why? For optimization, to be sure there's no closure allocation or a second pointer. But also for code correctness, because static functions can't use automatic variables defined in the enclosing function. This makes the code simpler to understand (the pure attribute has a similar purpose, you are sure your global function is not using global mutable variables). Bye, bearophile
Re: Arbitrary abbreviations in phobos considered ridiculous
On 2012-03-09 15:39, Timon Gehr wrote:
On 03/08/2012 10:07 PM, H. S. Teoh wrote:
On Thu, Mar 08, 2012 at 05:45:47PM -0300, Ary Manzana wrote:
On 3/8/12 7:27 AM, Timon Gehr wrote:
On 03/08/2012 03:14 AM, Ary Manzana wrote:
Here's something I wrote today:
parent_ids = results.map{|x|
x['_source']['parent_ids']}.flatten.uniq.compact
Hash[Site.find(parent_ids).map{|x| [x.id, x]}]
Or I could have written:
Hash[
Site.find(
results.map{|x| x['_source']['parent_ids']}.flatten.uniq.compact
).map{|x| [x.id, x]}
]
No abbreviation at all,
uniq.
[...]
And ids.
T
Is that in some standard library interface?
Site.find is part of ActiveRecord (part of Rails), the rest is part of
the core (standard) library.
--
/Jacob Carlborg
Re: Multiple return values...
On Mar 9, 2012 10:28 AM, H. S. Teoh hst...@quickfur.ath.cx wrote:
On Fri, Mar 09, 2012 at 03:27:14PM +0100, Timon Gehr wrote:
On 03/09/2012 01:23 AM, Manu wrote:
[...]
int x; ... (x, float y) = func(); // assign to predeclared
variable(/s)?
(x, , z) = func(); // ignore the second result value (elimination of
the
second result's code path)
Those two would work, but (x,y) = func(); conflicts with the comma
operator. (I'd prefer (,) to be a tuple constructor though.)
Just out of curiosity, *why* does D have a comma operator? It's one of
those obscure things about C that can be really, really, nasty if you're
unaware of it. And C++ makes it worse by making the comma operator
*overloadable
The comma operator can be worked around by using braces instead. Of course
it is very breaking and quite arguably ugly.
for ({int I; float j;} ; ) ;
But then you have to worry about what it returns. The sequence operator is
actually useful it is just unfortunate that they used it for function
parameters also.
I think that the best work around is either the braces which can be quite
elegant because it fits the rest of the language and say it returns the
return value of the last statement. Or pick a new character for the
sequence operator.
This is actually kinds nice because you get tuple in tuple out. Of
course they don't need to be tuples that can be passed around they can be
values that must be unpacked right away.
Re: Multiple return values...
On 03/09/2012 04:38 PM, Manu wrote:
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't think I'm
qualified
to propose a robust syntax, I don't know enough about the finer
details
of the grammar.
Perhaps if other people agree with me, they could present some
creative
solutions to the syntax?
I imagine something like:
auto (x, y) = func(); // specify auto for all results?
float (x, y) = func(); // specify explicit type for all results?
(int x, float y) = func; // explicitly type each result?
This works, and Kenji Hara has already implemented appropriate
parser extensions.
int x; ... (x, float y) = func(); // assign to predeclared
variable(/s)?
(x, , z) = func(); // ignore the second result value
(elimination of the
second result's code path)
Those two would work, but (x,y) = func(); conflicts with the comma
operator. (I'd prefer (,) to be a tuple constructor though.)
You think so? Within that context, I would think the coma could be
reinterpreted however it likes. The usual use of the coma operator makes
no sense in this context?
void main(){
int a,b;
(a,b)=2;
assert(a==0);
assert(b==2);
}
These last 2 examples are what I see as being the most important part,
and the precise reason that it SHOULDN'T be a tuple.
You are probably confusing the tuple concept with a Phobos Tuple.
The ability to
directly assign results to explicit (existing) variables, and to ignore
some/all of the return values, is a fundamental feature of the /concept/
of return values universally.
I see this as basically the whole point.
Another example: (someStruct.x, y, , int err) = func();
In this example, I assign the x result to a struct, y assigns to some
existing local, we ignore z because we can (visually states our intent,
would be hidden through use of a tuple), and we declare an int to
capture a potential error in place.
This is simple pattern matching.
If we were abusing the tuple syntax, we would need additional lines
following the call to assign the rvalues out to their appropriate
places, which is unnecessary spaghetti.
What you propose is tuple syntax.
Re: Annotations or custom attributes
On 9 March 2012 17:20, bearophile bearophileh...@lycos.com wrote: Manu: Okay, so the consensus is, it doesn't currently exist, but there is no real resistance, and is tentatively planned? Sounds good to me. As far as I know there are no concrete ideas yet for the semantics and precise usage of this feature. And I think there are different ideas regarding what this feature has to do (example: I think of it as as a user-defined extension of the type system. Other people think of this feature more like the C#, Scala or Java ones). So if you want this feature to happen and you have good ideas, then I suggest you to write down a little concrete proposal of definition syntax/semantics (implementation isn't needed now). Bye, bearophile Okay, well I'll do that at some point, but not now. My other multiple return values thread is about a thousand times more important to me at this point, so I'll keep driving that for the time being :P
Re: Multiple return values...
On 9 March 2012 17:57, Timon Gehr timon.g...@gmx.ch wrote:
On 03/09/2012 04:38 PM, Manu wrote:
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't think I'm
qualified
to propose a robust syntax, I don't know enough about the finer
details
of the grammar.
Perhaps if other people agree with me, they could present some
creative
solutions to the syntax?
I imagine something like:
auto (x, y) = func(); // specify auto for all results?
float (x, y) = func(); // specify explicit type for all results?
(int x, float y) = func; // explicitly type each result?
This works, and Kenji Hara has already implemented appropriate
parser extensions.
int x; ... (x, float y) = func(); // assign to predeclared
variable(/s)?
(x, , z) = func(); // ignore the second result value
(elimination of the
second result's code path)
Those two would work, but (x,y) = func(); conflicts with the comma
operator. (I'd prefer (,) to be a tuple constructor though.)
You think so? Within that context, I would think the coma could be
reinterpreted however it likes. The usual use of the coma operator makes
no sense in this context?
void main(){
int a,b;
(a,b)=2;
assert(a==0);
assert(b==2);
}
These last 2 examples are what I see as being the most important part,
and the precise reason that it SHOULDN'T be a tuple.
You are probably confusing the tuple concept with a Phobos Tuple.
The ability to
directly assign results to explicit (existing) variables, and to ignore
some/all of the return values, is a fundamental feature of the /concept/
of return values universally.
I see this as basically the whole point.
Another example: (someStruct.x, y, , int err) = func();
In this example, I assign the x result to a struct, y assigns to some
existing local, we ignore z because we can (visually states our intent,
would be hidden through use of a tuple), and we declare an int to
capture a potential error in place.
This is simple pattern matching.
I'm not sure what you mean by this?
If we were abusing the tuple syntax, we would need additional lines
following the call to assign the rvalues out to their appropriate
places, which is unnecessary spaghetti.
What you propose is tuple syntax.
What I mean is this:
retTuple = func();
someStruct.x = retTuple[0];
y = retTuple[1];
// retTuple[2] is ignored, but the intent is not clear in the code as it
was in my prior example, I like how my prior example makes this intent
explicit
int err = retTuple[3];
This is pretty horrible. Surely you can see why I want to be able to
arbitrarily assign the return values directly?
That's what I mean by 'abuse of the tuple syntax', but if that's not what
you mean, then show me an example of the usage of your suggestion?
Re: Annotations or custom attributes
On 3/9/12 2:56 AM, Manu wrote:
Does D have a nice way to add annotations or custom attributes to entities?
In Java/C# for example, it is common to annotate things with useful
compile time information. I'd like to be able to do that in D on occasion.
For instance, I'm serialising some struct/class using reflection to some
text format, but there are a couple of members in a particular class
that I don't want to be written.
A nice solution might be that I could annotate various members:
@DoNotSerialise int thing; ... or something along those lines, whatever
concept you want to apply, which I could then inspect in static if()
logic to produce some requested additional behaviour.
This is a trivial example, but looking at C#/Java, you can see how many
useful things can be done with this sort of system.
How would it be done currently?
I think a good approach in D would be to define mixins that work in
conjunction with the feature involved, for example:
class A {
int thing;
mixin(DoNotSerialize!thing);
...
}
or together:
class A {
mixin(DoNotSerialize!(int, thing));
...
}
Andrei
Re: Annotations or custom attributes
That's easy to implement and extremely ugly.
On Fri, Mar 9, 2012 at 8:15 PM, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 3/9/12 2:56 AM, Manu wrote:
Does D have a nice way to add annotations or custom attributes to
entities?
In Java/C# for example, it is common to annotate things with useful
compile time information. I'd like to be able to do that in D on occasion.
For instance, I'm serialising some struct/class using reflection to some
text format, but there are a couple of members in a particular class
that I don't want to be written.
A nice solution might be that I could annotate various members:
@DoNotSerialise int thing; ... or something along those lines, whatever
concept you want to apply, which I could then inspect in static if()
logic to produce some requested additional behaviour.
This is a trivial example, but looking at C#/Java, you can see how many
useful things can be done with this sort of system.
How would it be done currently?
I think a good approach in D would be to define mixins that work in
conjunction with the feature involved, for example:
class A {
int thing;
mixin(DoNotSerialize!thing);
...
}
or together:
class A {
mixin(DoNotSerialize!(int, thing));
...
}
Andrei
--
Bye,
Gor Gyolchanyan.
Re: Annotations or custom attributes
On 2012-03-09 17:15, Andrei Alexandrescu wrote:
On 3/9/12 2:56 AM, Manu wrote:
Does D have a nice way to add annotations or custom attributes to
entities?
In Java/C# for example, it is common to annotate things with useful
compile time information. I'd like to be able to do that in D on
occasion.
For instance, I'm serialising some struct/class using reflection to some
text format, but there are a couple of members in a particular class
that I don't want to be written.
A nice solution might be that I could annotate various members:
@DoNotSerialise int thing; ... or something along those lines, whatever
concept you want to apply, which I could then inspect in static if()
logic to produce some requested additional behaviour.
This is a trivial example, but looking at C#/Java, you can see how many
useful things can be done with this sort of system.
How would it be done currently?
I think a good approach in D would be to define mixins that work in
conjunction with the feature involved, for example:
class A {
int thing;
mixin(DoNotSerialize!thing);
...
}
or together:
class A {
mixin(DoNotSerialize!(int, thing));
...
}
Andrei
As may serialization library Orange already does:
http://dl.dropbox.com/u/18386187/orange_docs/orange.serialization.Serializable.html
Look for NonSerialized.
--
/Jacob Carlborg
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis jmdavisp...@gmx.comwrote: On Friday, March 09, 2012 09:33:20 deadalnix wrote: Le 07/03/2012 02:00, F i L a écrit : I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#. The problem with making any change to Phobos is backwards compatibility. We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so. We're not changing symbol names without a good reason. Yes, there's a deprecation process that allows us to change them if we need to, but it's still disruptive. - Jonathan M Davis The secs and seconds inconsistency is something I've seen people in IRC hit and complain about on several occasions. The dur!seconds(1) syntax I've seen complained about or confusion over on both IRC and on reddit by active and potential users. While I don't feel particularly strong about these issues I feel I should point out that actual users are hitting them and the issues bug them enough that they feel the need to complain publicly. Changes must be made with care but the former issue on inconsistency, I would argue, is a bigger issue than, say, the current symbol deprecation/replace of toISOExtendedString (though I don't know the history of the decision to make the change). There shouldn't be two ways of expressing the exact same thing so the secs/seconds should be a substitute and deprecate process rather than just a simple alias if it were made. It looks like it's been rejected already, though, which is unfortunate. phobos is still a young library (or at least parts of it, like datetime, are) and so these types of wart removal could be made with limited disruption to current users. The dur aliases would be welcome because they increase readability, intuitive design, and brevity. I know I just said their shouldn't be two ways of doing the same thing but I don't feel this is the case here. It's a shortcut to doing exactly one thing and, as I said before, I wouldn't want to lose the option of genericity. I just want to make specification of it optional since I would use seconds(5) a great deal more often than dur!base(5) (though I would use the latter fairly frequently in my line of work). Anyway, I just felt I'd share my opinion and what I've witnessed of other users so it's at least it's heard and taken into consideration. The decision is ultimately yours and Walter's. Regards, Brad Anderson
Re: Annotations or custom attributes
On 9 March 2012 18:15, Andrei Alexandrescu seewebsiteforem...@erdani.orgwrote:
On 3/9/12 2:56 AM, Manu wrote:
Does D have a nice way to add annotations or custom attributes to
entities?
In Java/C# for example, it is common to annotate things with useful
compile time information. I'd like to be able to do that in D on occasion.
For instance, I'm serialising some struct/class using reflection to some
text format, but there are a couple of members in a particular class
that I don't want to be written.
A nice solution might be that I could annotate various members:
@DoNotSerialise int thing; ... or something along those lines, whatever
concept you want to apply, which I could then inspect in static if()
logic to produce some requested additional behaviour.
This is a trivial example, but looking at C#/Java, you can see how many
useful things can be done with this sort of system.
How would it be done currently?
I think a good approach in D would be to define mixins that work in
conjunction with the feature involved, for example:
class A {
int thing;
mixin(DoNotSerialize!thing);
...
}
or together:
class A {
mixin(DoNotSerialize!(int, thing));
...
}
Andrei
Yep, that sure is horribly ugly! Sadly, that's what I thought the case was
currently. Let's hope for user defined attributes in the future ;)
Re: Arbitrary abbreviations in phobos considered ridiculous
Jonathan M Davis Wrote: On Thursday, March 08, 2012 20:42:31 H. S. Teoh wrote: On Thu, Mar 08, 2012 at 07:07:43PM -0500, Jonathan M Davis wrote: On Thursday, March 08, 2012 12:10:07 H. S. Teoh wrote: IMO, making all abbreviations in Phobos consistent would be a big step forward. You know, people keep saying that the abbreviations are inconsistent, but I don't buy that. _What_ abbreviations are inconsistent? [...] My comment was referring specifically to the pull request that adds secs as an alternative for seconds. From what Walter said, he seems to be against any renaming changes, so any existing inconsistencies that we might find seems likely to be rejected as well. But at the end of the day, this *is* just bikeshedding, so perhaps it's not worth spending so much time and energy on. People will get used to the quirky names eventually, and life goes on. *shrug* I think that most of the major issues with inconsistencies have been fixed. Sure, there may be a few left, but the longer that they're there, the more costly it is to fix them. And D is reaching the point where it needs to be stable. Constantly tweaking the standard library just doesn't cut it. I made quite a few changes to try and fix inconsistencies (such as function names which weren't camelcased like they were supposed to be), and that was painful enough, and engendered plenty of complaints in spite of the fact that there were quite a few people arguing for fixing the names to make Phobos consistent. I really don't think that Phobos is really any more quirky or inconsistent than your average standard library. It's not perfect, but it isn't particularly inconsistent either. We'll continue to make improvement to it (primarily by adding new stuff), but it's increasingly costly to make breaking changes. And, on the whole, it's not like what we have is horrible. The biggest problems involve whole modules (which are generally older) which need to be redesigned, and those will happen. But minor stuff like tweaking function names doesn't really buy us enough to be worth it anymore. If a function changes sufficiently to merit a full replacement, then maybe we can change its name and phase out the old one (e.g. if we change the functions in std.string which take patterns to take regexes instead), but changing a name to change a name just isn't worth it when we're trying to provide a serious offering with D and Phobos. We're too far along. - Jonathan M Davis make breaking changes at the same time provide a change list and provide a automatically batch changes the tools of third - party source code. good luck dolive
Re: Annotations or custom attributes
On 2012-03-09 16:15:30 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
I think a good approach in D would be to define mixins that work in
conjunction with the feature involved, for example:
class A {
int thing;
mixin(DoNotSerialize!thing);
...
}
or together:
class A {
mixin(DoNotSerialize!(int, thing));
...
}
It's ugly, but it works… only to a point though. Try to annotate
overloaded functions and it'll become a mess: either you duplicate the
function name and all the argument types for each function, or you wrap
the whole function body in the mixin.
If you need to annotate a struct or a class you'll have the same
problem, just at a bigger scale. And it gets worse if you want to
annotate templated types and functions: how can the attribute apply to
each instance?
I'm not saying any of this is impossible using mixins, just that it
becomes impractical as you go beyond the most simple cases.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: Annotations or custom attributes
On 9 March 2012 19:23, Michel Fortin michel.for...@michelf.com wrote:
On 2012-03-09 16:15:30 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org** said:
I think a good approach in D would be to define mixins that work in
conjunction with the feature involved, for example:
class A {
int thing;
mixin(DoNotSerialize!thing);
...
}
or together:
class A {
mixin(DoNotSerialize!(int, thing));
...
}
It's ugly, but it works… only to a point though. Try to annotate
overloaded functions and it'll become a mess: either you duplicate the
function name and all the argument types for each function, or you wrap the
whole function body in the mixin.
If you need to annotate a struct or a class you'll have the same problem,
just at a bigger scale. And it gets worse if you want to annotate templated
types and functions: how can the attribute apply to each instance?
I'm not saying any of this is impossible using mixins, just that it
becomes impractical as you go beyond the most simple cases.
It seems to me that everyone agrees on the usefulness of proper user
defined annotations, so I'm personally satisfied that it *will* come :) ..
It's certainly not urgent for me, but it sure would be nice!
Re: Multiple return values...
On 03/09/2012 05:14 PM, Manu wrote:
On 9 March 2012 17:57, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch wrote:
On 03/09/2012 04:38 PM, Manu wrote:
On 9 March 2012 16:27, Timon Gehr timon.g...@gmx.ch
mailto:timon.g...@gmx.ch
mailto:timon.g...@gmx.ch mailto:timon.g...@gmx.ch wrote:
On 03/09/2012 01:23 AM, Manu wrote:
I can imagine syntax using parentheses, but I don't
think I'm
qualified
to propose a robust syntax, I don't know enough about
the finer
details
of the grammar.
Perhaps if other people agree with me, they could
present some
creative
solutions to the syntax?
I imagine something like:
auto (x, y) = func(); // specify auto for all results?
float (x, y) = func(); // specify explicit type for all
results?
(int x, float y) = func; // explicitly type each result?
This works, and Kenji Hara has already implemented appropriate
parser extensions.
int x; ... (x, float y) = func(); // assign to predeclared
variable(/s)?
(x, , z) = func(); // ignore the second result value
(elimination of the
second result's code path)
Those two would work, but (x,y) = func(); conflicts with the
comma
operator. (I'd prefer (,) to be a tuple constructor though.)
You think so? Within that context, I would think the coma could be
reinterpreted however it likes. The usual use of the coma
operator makes
no sense in this context?
void main(){
int a,b;
(a,b)=2;
assert(a==0);
assert(b==2);
}
These last 2 examples are what I see as being the most important
part,
and the precise reason that it SHOULDN'T be a tuple.
You are probably confusing the tuple concept with a Phobos Tuple.
The ability to
directly assign results to explicit (existing) variables, and to
ignore
some/all of the return values, is a fundamental feature of the
/concept/
of return values universally.
I see this as basically the whole point.
Another example: (someStruct.x, y, , int err) = func();
In this example, I assign the x result to a struct, y assigns to
some
existing local, we ignore z because we can (visually states our
intent,
would be hidden through use of a tuple), and we declare an int to
capture a potential error in place.
This is simple pattern matching.
I'm not sure what you mean by this?
If we were abusing the tuple syntax, we would need additional lines
following the call to assign the rvalues out to their appropriate
places, which is unnecessary spaghetti.
What you propose is tuple syntax.
What I mean is this:
retTuple = func();
someStruct.x = retTuple[0];
y = retTuple[1];
// retTuple[2] is ignored, but the intent is not clear in the code as it
was in my prior example, I like how my prior example makes this intent
explicit
int err = retTuple[3];
This is pretty horrible. Surely you can see why I want to be able to
arbitrarily assign the return values directly?
That's what I mean by 'abuse of the tuple syntax', but if that's not
what you mean, then show me an example of the usage of your suggestion?
There are two parts, syntax and semantics.
Semantics:
D is already able to express those:
template Tuple(T...){alias T Tuple;} // not the same as std.typecons.Tuple!
// function with multiple return values:
Tuple!(int,double) foo(int a, double b){
Tuple!(int, double) result; // ok, _no imposed memory layout_
result[0] = a; // ok
result[1] = a+b; // ok
return result;
}
Multiple return values are currently *disallowed explicitly*:
DMD sez: Error: functions cannot return a tuple
Just specify the ABI, implement the code gen, and we're done.
Moot point: built-in tuples auto-flatten inside comma-separated lists.
std.typecons.Tuple is a hack to circumvent the arbitrary cannot return
tuple from function restriction as well as the auto-flattening. The
problem is that it is implemented as a struct with a built-in tuple
member. The fact that it is a struct imposes a memory layout. This is
just a side-effect of attempting to address the other two issues. It is
not something that is desirable.
Syntax:
Currently, there is just none. Tuples are a built-in types that cannot
be created without a template that makes them accessible.
IMHO Ideally, it would look like this:
(int, double) foo(int a, double b) = (a, a+b);//Jonathan does not like this
void main(){
(int, double) bar = (1,2.0);
auto (x,y) = (1,2.0);
bar = foo(x,y);
Re: Multiple return values...
On 03/09/2012 05:14 PM, Manu wrote: What I mean is this: retTuple = func(); someStruct.x = retTuple[0]; y = retTuple[1]; // retTuple[2] is ignored, but the intent is not clear in the code as it was in my prior example, I like how my prior example makes this intent explicit int err = retTuple[3]; This is pretty horrible. Surely you can see why I want to be able to arbitrarily assign the return values directly? Yes. I want to be able to do that too. That's what I mean by 'abuse of the tuple syntax', Ah ok. I misunderstood then.
Re: Creating dynamic arrays of known size
On Fri, Mar 09, 2012 at 03:10:21PM +0100, Andrej Mitrovic wrote: Isn't this just as good? Key[] keys; keys.reserve(num_keys) foreach (key; keys_in_aa) keys ~= key; I suppose that should work. Although it does open up a new can of worms: reserve is @system and also impure. I can see why, because it interacts with the GC, so by definition it affects state outside of itself. But if language-level constructs such as arrays use the GC, does that then make them impure? That doesn't seem like a good idea (can't use arrays in pure functions -- seems unnecessarily limiting). Alternatively, can reserve() be made pure? Since in a sense it only affects the array. At the very least, can reserve be made @trusted? Currently, all of this causes AA.keys and AA.values to be impure and @system, which seems a bit extreme to me. (Again, comes back to the point of language-level constructs: AA.keys/.values can't be used in pure functions; seems unnecessarily limiting.) On Fri, Mar 09, 2012 at 09:39:16AM -0500, Steven Schveighoffer wrote: On Fri, 09 Mar 2012 01:59:34 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: [...] I see two options. Allocate the entire array, set the length to 0, and use assumeSafeAppend (or maybe the function that it uses, since assumeSafeAppend is in _object.d) so that appending doesn't cause reallocations, or create the array as mutable and then cast it to the appropriate type. 1. auto keys = new Key[](num_keys); keys.length = 0; assumeSafeAppend(keys); for(i; 0 .. num_keys) keys ~= ...; 2. auto keys = new (Unqual!Key)[](num_keys); foreach(ref key; keys) key = ...; auto actualKeys = cast(Key[])keys; Use the second method. This is low-level runtime code, it should be as fast as possible. Casting is OK as long as it's justified. [...] OK. T -- What doesn't kill me makes me stranger.
Re: Multiple return values...
On Fri, Mar 09, 2012 at 07:16:19PM +0100, Timon Gehr wrote: [...] Another issue is that people would complain about auto-flattening all the time once built-in tuples get more accessible, even though it is not actually a problem. It would be just due to the fact that it does not occur in most other popular programming languages. [...] Perl auto-flattens lists. To prevent auto-flattening you have to explicitly take an array reference. But yeah, most other languages don't. T -- Real Programmers use cat a.out.
Re: Arbitrary abbreviations in phobos considered ridiculous
Alix Pexton alix.dot.pex...@gmail.dot.com wrote in message news:jjcn41$2g4g$1...@digitalmars.com... and I have a theory that poetic languages would be good for programming in. http://shakespearelang.sourceforge.net/ Hello World: http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello
Re: Arbitrary abbreviations in phobos considered ridiculous
Ary Manzana a...@esperanto.org.ar wrote in message news:jjd21r$6ni$1...@digitalmars.com... Sample Ruby session: irb ruby-1.8.7-p352 :001 [1, 2, 3].count = 3 ruby-1.8.7-p352 :002 [1, 2, 3].length = 3 ruby-1.8.7-p352 :003 [1, 2, 3].size = 3 I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders why didn't he wrote 'length' instead of 'size', because the meaning is clear. I would wonder what the subtle distinction is. FWIW.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 10:01:19 Brad Anderson wrote: On Fri, Mar 9, 2012 at 1:46 AM, Jonathan M Davis jmdavisp...@gmx.comwrote: On Friday, March 09, 2012 09:33:20 deadalnix wrote: Le 07/03/2012 02:00, F i L a écrit : I personally find it much easier to remember and use longer, more sentance-like method names. However, Jonathan and others obviously feel more comfortable writing with a high level of abbreviation, which they justify rather well. Still, if D's goal is to gain popularity, I think it should take notices of other rising languages like C#. The problem with making any change to Phobos is backwards compatibility. We just need a politic for the change. IE: make the old name a warning, then deprecated, then remove it. Spread the process to a year or so. We're not changing symbol names without a good reason. Yes, there's a deprecation process that allows us to change them if we need to, but it's still disruptive. - Jonathan M Davis The secs and seconds inconsistency is something I've seen people in IRC hit and complain about on several occasions. The dur!seconds(1) syntax I've seen complained about or confusion over on both IRC and on reddit by active and potential users. While I don't feel particularly strong about these issues I feel I should point out that actual users are hitting them and the issues bug them enough that they feel the need to complain publicly. Changes must be made with care but the former issue on inconsistency, I would argue, is a bigger issue than, say, the current symbol deprecation/replace of toISOExtendedString (though I don't know the history of the decision to make the change). There shouldn't be two ways of expressing the exact same thing so the secs/seconds should be a substitute and deprecate process rather than just a simple alias if it were made. It looks like it's been rejected already, though, which is unfortunate. phobos is still a young library (or at least parts of it, like datetime, are) and so these types of wart removal could be made with limited disruption to current users. As I explained in the pull request, if we switched to secs, it would just create a different set of inconsistencies: https://github.com/D-Programming-Language/druntime/pull/173 There would just be a different set of complaints if seconds were changed to secs. No matter what we do here, we lose. Someone's going to be complaining. There is no perfect solution. And while the library is young, it really needs to be stabilizing given that we want D to be real player in the programming world, and there is increasing resistance to changing it - especially from Walter and Andrei. If a breaking change is made, the change needs to be a clear win. And while using secs would certainly please some people, it would create it's own set of problems, so it's not at all a clear win IMHO. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, Mar 09, 2012 at 01:29:03PM -0500, Nick Sabalausky wrote: Alix Pexton alix.dot.pex...@gmail.dot.com wrote in message news:jjcn41$2g4g$1...@digitalmars.com... and I have a theory that poetic languages would be good for programming in. http://shakespearelang.sourceforge.net/ Hello World: http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello [...] +1. I've seen that one before, but it cracks me up every time. Using insults to represent negative numbers and praises to represent positive numbers is just hilarious. What would be really funny is if you wrote an actual play (with actual plot and dramatic buildup) that also does something useful. T -- If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
Re: Multiple return values...
H. S. Teoh: Perl auto-flattens lists. Maybe they have fixed this big design mistake in Perl6. Bye, bearophile
Re: Annotations or custom attributes
On Friday, March 09, 2012 16:00:03 Manu wrote: Okay, so the consensus is, it doesn't currently exist, but there is no real resistance, and is tentatively planned? Sounds good to me. I wouldn't really say that it's tentatively planned. I don't recall Walter ever weighing in on it at all, and no one is working on it. Rather, the current situation does not prevent it, and there's definitely some desire for it in the community, so there's a decent chance that it'll be implemented eventually. There are no plans for it though. Regardless, adding them should be backwards compatible, so it's really not a problem to wait until other more pressing issues have been addressed and the language has better stabilized before adding such a feature. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, Mar 09, 2012 at 01:34:38PM -0500, Nick Sabalausky wrote: Ary Manzana a...@esperanto.org.ar wrote in message news:jjd21r$6ni$1...@digitalmars.com... Sample Ruby session: irb ruby-1.8.7-p352 :001 [1, 2, 3].count = 3 ruby-1.8.7-p352 :002 [1, 2, 3].length = 3 ruby-1.8.7-p352 :003 [1, 2, 3].size = 3 I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders why didn't he wrote 'length' instead of 'size', because the meaning is clear. I would wonder what the subtle distinction is. FWIW. [...] Me too. I would assume that 'count' counts array elements whereas 'size' counts the number of bytes the array uses up. IMAO, this sort of write your mind and somehow it just works thing only encourages lazy programming (guessing what something does without knowing for sure, and copy-n-pasting code without understanding it, which leads to bit rot and hideous patchwork code that houses all sorts of subtle bugs and corner-case failures). T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Re: Multiple return values...
On Fri, Mar 09, 2012 at 02:01:34PM -0500, bearophile wrote: H. S. Teoh: Perl auto-flattens lists. Maybe they have fixed this big design mistake in Perl6. [...] Whether or not it was a mistake is debatable. It does have its uses... though forcing everyone to use references to prevent flattening *is* a bit extreme. T -- A man's wife has more power over him than the state has. -- Ralph Emerson
Re: Arbitrary abbreviations in phobos considered ridiculous
On 09/03/2012 18:29, Nick Sabalausky wrote: Alix Pextonalix.dot.pex...@gmail.dot.com wrote in message news:jjcn41$2g4g$1...@digitalmars.com... and I have a theory that poetic languages would be good for programming in. http://shakespearelang.sourceforge.net/ Hello World: http://shakespearelang.sourceforge.net/report/shakespeare/shakespeare.html#sec:hello Not quite what I had in mind, but still amusing ^^ A...
Re: Multiple return values...
Manu wrote: By contrast, multiple return values are quite the opposite. They are explicitly NON-STRUCTURED. The presumption in this case is that multiple resturn values would follow the exact same set of rules as passing multiple args TO a function, but in reverse. this seams to state a contradiction, because one cannot use the multiple return values as actual parameters for any call of a function. Furthermore it is not defined how the formal parameters of a function are to be declared, if they are assumed to receive multiple return values as actual arguments. If those actual parameters are indeed NON- STRUCTURED how can one define them or even mix them with STRUCTURED actual parameters? -manfred
Re: Arbitrary abbreviations in phobos considered ridiculous
On 3/9/12 4:09 PM, H. S. Teoh wrote:
On Fri, Mar 09, 2012 at 01:34:38PM -0500, Nick Sabalausky wrote:
Ary Manzanaa...@esperanto.org.ar wrote in message
news:jjd21r$6ni$1...@digitalmars.com...
Sample Ruby session:
irb
ruby-1.8.7-p352 :001 [1, 2, 3].count
= 3
ruby-1.8.7-p352 :002 [1, 2, 3].length
= 3
ruby-1.8.7-p352 :003 [1, 2, 3].size
= 3
I never saw *anyone* complaining about this. When you write, you
choose whatever is convenient to you (whatever comes to your mind
first). When you read it, it's understandable. Nobody wonders why
didn't he wrote 'length' instead of 'size', because the meaning is
clear.
I would wonder what the subtle distinction is. FWIW.
[...]
Me too. I would assume that 'count' counts array elements whereas 'size'
counts the number of bytes the array uses up.
Indeed, count can be used to count elements:
ruby-1.8.7-p352 :002 [1, 2, 3, 3, 3].count 3
= 3
ruby-1.8.7-p352 :004 [1, 2, 3, 3, 3].count :odd?
= 4
ruby-1.8.7-p352 :005 [1, 2, 3, 3, 3].count { |x| x = 2 }
= 2
Just that when you use it without arguments it just counts everything.
size is an alias of length. But count just work as an alias as well,
without arguments.
IMAO, this sort of write your mind and somehow it just works thing
only encourages lazy programming (guessing what something does without
knowing for sure, and copy-n-pasting code without understanding it,
which leads to bit rot and hideous patchwork code that houses all sorts
of subtle bugs and corner-case failures).
We also write lots of tests in Ruby. :-P
Re: Multiple return values...
On 9 March 2012 22:39, Manfred Nowak svv1...@hotmail.com wrote: Manu wrote: By contrast, multiple return values are quite the opposite. They are explicitly NON-STRUCTURED. The presumption in this case is that multiple resturn values would follow the exact same set of rules as passing multiple args TO a function, but in reverse. this seams to state a contradiction, because one cannot use the multiple return values as actual parameters for any call of a function. Furthermore it is not defined how the formal parameters of a function are to be declared, if they are assumed to receive multiple return values as actual arguments. If those actual parameters are indeed NON- STRUCTURED how can one define them or even mix them with STRUCTURED actual parameters? I'm just talking about the ABI for returning multiple values, not chaining a multiple return into a secondary call (I think this is what you are saying?). A multiple return should use precisely the same register/stack assignment as when passing args in to a function. Just that the process is in reverse.
Re: Multiple return values...
I'm finding HEAPS of SIMD functions want to return pairs (unpacks in particular): int4 (low, hight) = unpack(someShort8); Currently I have to duplicate everyting: int4 low = unpackLow(someShort8); int4 high = unpackHigh(someShort8); I'm getting really sick of that, it feels so... last millennium. It can also be realy inefficient. For example ARM NEON has vzip instruction that is used like this: vzip.32 q0, q1 This will interleave elements of vectors in q0 and q1 in one instruction.
Re: Arbitrary abbreviations in phobos considered ridiculous
Nick Sabalausky a@a.a wrote in message news:jjdru9$1rv5$1...@digitalmars.com... Nick Sabalausky a@a.a wrote in message news:jj6gjm$2m6a$1...@digitalmars.com... But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. https://github.com/D-Programming-Language/druntime/pull/174 https://github.com/D-Programming-Language/phobos/pull/485 https://github.com/D-Programming-Language/tools/pull/23 I completely understand the secs==seconds pull request being rejected and I think that's perfectly reasonable... But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with no aliases. Note how much *nicer* it makes all the sample and unittest code.
Re: Arbitrary abbreviations in phobos considered ridiculous
Nick Sabalausky a@a.a wrote in message news:jj6gjm$2m6a$1...@digitalmars.com... But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. https://github.com/D-Programming-Language/druntime/pull/174 https://github.com/D-Programming-Language/phobos/pull/485 https://github.com/D-Programming-Language/tools/pull/23 I completely understand the secs==seconds pull request being rejected and I think that's perfectly reasonable... But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with no aliases.
Re: Arbitrary abbreviations in phobos considered ridiculous
Ary Manzana a...@esperanto.org.ar wrote in message
news:jjdqe4$1oeb$1...@digitalmars.com...
Indeed, count can be used to count elements:
ruby-1.8.7-p352 :002 [1, 2, 3, 3, 3].count 3
= 3
ruby-1.8.7-p352 :004 [1, 2, 3, 3, 3].count :odd?
= 4
ruby-1.8.7-p352 :005 [1, 2, 3, 3, 3].count { |x| x = 2 }
= 2
Interesting idea.
IMAO, this sort of write your mind and somehow it just works thing
only encourages lazy programming (guessing what something does without
knowing for sure, and copy-n-pasting code without understanding it,
which leads to bit rot and hideous patchwork code that houses all sorts
of subtle bugs and corner-case failures).
We also write lots of tests in Ruby. :-P
Writing plenty of tests is good no matter what, but it's an inferior
substitute for proper compile-time checks. Not that that's applicable to
this count vs length vs size subdiscussion, of course. Just a general
comment on the dynamic world's fairly common lots of tests excuse.
Re: Arbitrary abbreviations in phobos considered ridiculous
On 3/9/12 6:21 PM, Nick Sabalausky wrote:
Ary Manzanaa...@esperanto.org.ar wrote in message
news:jjdqe4$1oeb$1...@digitalmars.com...
Indeed, count can be used to count elements:
ruby-1.8.7-p352 :002 [1, 2, 3, 3, 3].count 3
= 3
ruby-1.8.7-p352 :004 [1, 2, 3, 3, 3].count:odd?
= 4
ruby-1.8.7-p352 :005 [1, 2, 3, 3, 3].count { |x| x= 2 }
= 2
Interesting idea.
IMAO, this sort of write your mind and somehow it just works thing
only encourages lazy programming (guessing what something does without
knowing for sure, and copy-n-pasting code without understanding it,
which leads to bit rot and hideous patchwork code that houses all sorts
of subtle bugs and corner-case failures).
We also write lots of tests in Ruby. :-P
Writing plenty of tests is good no matter what, but it's an inferior
substitute for proper compile-time checks. Not that that's applicable to
this count vs length vs size subdiscussion, of course. Just a general
comment on the dynamic world's fairly common lots of tests excuse.
True. I'd like to find (or do) a language that combines both of two worlds.
I started one, but I don't have much time to continue it and also I'm
stuck with design/implementation decisions. :-P
https://github.com/asterite/crystal
(not everything in the bullet list is implemented, those are just
wishes, but everything in samples compiles and runs)
And other people had similar ideas:
http://whitequark.org/blog/2011/12/21/statically-compiled-ruby/
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jj6gjm$2m6a$1...@digitalmars.com... But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. https://github.com/D-Programming-Language/druntime/pull/174 https://github.com/D-Programming-Language/phobos/pull/485 https://github.com/D-Programming-Language/tools/pull/23 I completely understand the secs==seconds pull request being rejected and I think that's perfectly reasonable... But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with no aliases. You'll need to have dur aliased to duration to follow the normal deprecation procedure. I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields. -Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote: On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jj6gjm$2m6a$1...@digitalmars.com... But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. https://github.com/D-Programming-Language/druntime/pull/174 https://github.com/D-Programming-Language/phobos/pull/485 https://github.com/D-Programming-Language/tools/pull/23 I completely understand the secs==seconds pull request being rejected and I think that's perfectly reasonable... But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with no aliases. You'll need to have dur aliased to duration to follow the normal deprecation procedure. I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields. Yeah. My general reaction is that this is a _bad_ idea. It creates aliases and uses names for free functions which are commonly used. We'll see if Walter says anything about this one, but my first reaction is to reject it. I'll wait for comments on it though. - Jonathan M Davis
Can getHash be made pure?
Still chugging away at implementing AA's in druntime proper, I reviewed the code for methods that can be marked pure but ran into a major road block: getHash() is not marked pure. That makes a lot of AA methods impure, that could, and probably should, be marked pure. Is it possible to make TypeInfo.getHash() pure? AFAICT there's no good reason why it shouldn't be pure. Am I missing something? T -- The most powerful one-line C program: #include /dev/tty -- IOCCC
Re: Arbitrary abbreviations in phobos considered ridiculous
Jonathan M Davis jmdavisp...@gmx.com wrote in message news:mailman.357.1331329638.4860.digitalmar...@puremagic.com... On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote: On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jj6gjm$2m6a$1...@digitalmars.com... But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. https://github.com/D-Programming-Language/druntime/pull/174 https://github.com/D-Programming-Language/phobos/pull/485 https://github.com/D-Programming-Language/tools/pull/23 I completely understand the secs==seconds pull request being rejected and I think that's perfectly reasonable... But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with no aliases. You'll need to have dur aliased to duration to follow the normal deprecation procedure. I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields. Yeah. My general reaction is that this is a _bad_ idea. It creates aliases and uses names for free functions which are commonly used. We'll see if Walter says anything about this one, but my first reaction is to reject it. I'll wait for comments on it though. If that's the case, then this alias-phobia will have *truly* gotten completely out of hand.
Re: Can getHash be made pure?
On 3/9/2012 1:54 PM, H. S. Teoh wrote: Still chugging away at implementing AA's in druntime proper, I reviewed the code for methods that can be marked pure but ran into a major road block: getHash() is not marked pure. That makes a lot of AA methods impure, that could, and probably should, be marked pure. Is it possible to make TypeInfo.getHash() pure? AFAICT there's no good reason why it shouldn't be pure. Am I missing something? It should be const, pure, nothrow, @safe.
Breaking backwards compatiblity
This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes.
Re: Arbitrary abbreviations in phobos considered ridiculous
Nick Sabalausky a@a.a wrote in message news:jjdu0j$209o$1...@digitalmars.com... I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields. I'd argue that should not be considered a problem in this case: http://forum.dlang.org/post/jj6hnv$2o9s$1...@digitalmars.com Plus, having to [**occasionally**] change a minutes to numMinutes (or something, frankly, much more descriptive) is a hell of a lot better than having to use 'dur!minutes(5)' instead of 'minutes(5)'.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, 09 Mar 2012 16:47:01 -0500, Jonathan M Davis jmdavisp...@gmx.com wrote: On Friday, March 09, 2012 16:36:27 Steven Schveighoffer wrote: On Fri, 09 Mar 2012 16:14:08 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jj6gjm$2m6a$1...@digitalmars.com... But, I'm thinking this whole dur vs duration matter is stupid anyway. Seconds, hours, etc *are* durations. What the hell do we even need the dur or duration for anyway? I say fuck it: Let's just toss this into core.time (or std.datetime or whatever) and be done: alias dur!years years; alias dur!months months; alias dur!weeks weeks; alias dur!days days; alias dur!hours hours; alias dur!minutes minutes; alias dur!seconds seconds; alias dur!msecs msecs; alias dur!usecs usecs; alias dur!hnsecs hnsecs; And then we have the brevity issue solved (and in fact, improved over dur), so then dur can (and should) change to duration without screwing up brevity. And all probelms are optimally solved. As for the possibility of new name collisions: Honestly, in this case I see no reason to give a shit. https://github.com/D-Programming-Language/druntime/pull/174 https://github.com/D-Programming-Language/phobos/pull/485 https://github.com/D-Programming-Language/tools/pull/23 I completely understand the secs==seconds pull request being rejected and I think that's perfectly reasonable... But I'm going to be really pissed if this one's rejected out of some misapplied, overly-puritanical obsession with no aliases. You'll need to have dur aliased to duration to follow the normal deprecation procedure. I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields. Yeah. My general reaction is that this is a _bad_ idea. It creates aliases and uses names for free functions which are commonly used. We'll see if Walter says anything about this one, but my first reaction is to reject it. I'll wait for comments on it though. I'll say I *don't* agree with the rejection of aliases on principle -- aliases can be extremely useful/helpful, and they cost literally nothing (the cognitive cost on the docs is a BS argument IMO). I just don't agree with consuming so many common symbols for the sake of sugar. -Steve
Re: Breaking backwards compatiblity
On 03/09/2012 11:32 PM, Walter Bright wrote: This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. Most bug fixes are breaking changes. I don't think we are there yet.
Re: Breaking backwards compatiblity
On 3/9/2012 2:41 PM, Timon Gehr wrote: On 03/09/2012 11:32 PM, Walter Bright wrote: This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. Most bug fixes are breaking changes. I don't think we are there yet. There have been some gratuitous ones, in my not-so-humble opinion. Those need to stop.
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, 09 Mar 2012 17:38:08 -0500, Nick Sabalausky a@a.a wrote: Nick Sabalausky a@a.a wrote in message news:jjdu0j$209o$1...@digitalmars.com... I can't say I agree with this, as it pollutes the global namespace with several common terms that could be used for fields. I'd argue that should not be considered a problem in this case: http://forum.dlang.org/post/jj6hnv$2o9s$1...@digitalmars.com Plus, having to [**occasionally**] change a minutes to numMinutes (or something, frankly, much more descriptive) is a hell of a lot better than having to use 'dur!minutes(5)' instead of 'minutes(5)'. I find both equally descriptive and neither one too offensive. All things being equal, dur wins because it consumes only one top-level symbol, and is already there. This is all my opinion of course, and we've already seen how much affect that has ;) -Steve
Re: Breaking backwards compatiblity
On 09-03-2012 23:32, Walter Bright wrote: This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages... -- - Alex
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, 09 Mar 2012 16:50:22 -0500, Adam D. Ruppe
destructiona...@gmail.com wrote:
On Friday, 9 March 2012 at 21:36:28 UTC, Steven Schveighoffer wrote:
I can't say I agree with this, as it pollutes the global namespace with
several common terms that could be used for fields.
There's no such thing as a global namespace in D, and
field names wouldn't be affected even if there was one.
Of course there isn't. What I meant was the module level namespace. Any
file you import by default goes into your current module namespace. In
effect it's the global namespace *for your module*.
But if I have to spell that out every time, it's going to be a lot of
typing. It's generally understood that the global namespace is the
effective global namespace during your module. Yes, there are ways to
rename imports, I find it poor design to *require* renaming imports.
int minutes(int i) {
return i;
}
struct A {
int minutes; // not a problem
void foo() {
minutes = .minutes(1); // works
}
}
Again, I find this just as descriptive and not terrible to type:
struct A {
Duration minutes;
void foo() {
minutes = dur!minutes(1);
}
}
-Steve
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote: I'll say I *don't* agree with the rejection of aliases on principle -- aliases can be extremely useful/helpful, and they cost literally nothing (the cognitive cost on the docs is a BS argument IMO). I just don't agree with consuming so many common symbols for the sake of sugar. aliases need to have a really good argument for existing. If UFCS is fully implemented, then I think that there is _some_ argument for having stuff like hours and minutes, because then you can do stuff like 5.seconds() (though honestly, I really don't like the idea). The alias enables different usages rather than simply being another name for the same thing. Now, in this particular case, it's that much worse for exactly the reason that you're against it: it uses common names for free functions. It's not as big a problem as it would be in C or C++, but it's still a problem. There's also some risk that it will break code. - Jonathan M Davis
Re: Breaking backwards compatiblity
On Friday, March 09, 2012 14:44:05 Walter Bright wrote: On 3/9/2012 2:41 PM, Timon Gehr wrote: On 03/09/2012 11:32 PM, Walter Bright wrote: This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. Most bug fixes are breaking changes. I don't think we are there yet. There have been some gratuitous ones, in my not-so-humble opinion. Those need to stop. Do you have any specific ones in mind? There were a number of them to try and make it so that names were more consistent with regards to camelcasing and the like, but those changes have largely stopped (or at least are well into the deprecation process if they haven't been completed yet). The only stuff along those lines that I'm aware of at the moment is the discussion on making some changes to some of the function names in core.time and std.datetime, because some people don't like some of them. And no such changes have been made yet (though there are people are still looking to make some of them). - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On Friday, 9 March 2012 at 22:54:37 UTC, Steven Schveighoffer wrote: Again, I find this just as descriptive and not terrible to type: Yeah, that's fine by me (though duration is still better than dur :-D ) I'm just the name conflict isn't a big deal either since writing .minutes in some places to disambiguate the scope works in most cases too.
Re: Multiple return values...
Manu wrote: I'm just talking about the ABI for returning multiple values, not chaining Does this mean, that you want a special type of function? For example this would be disallowed statement: `auto result= f( g( parameters));', if `f' and `g' are functions returning multiple values? Under chaining I understand concatenation of actual parameter lists like `auto result= f( parameters1)(parameters2);', which are legal because `f( parameters1)' returns a function `g', for which `parameters2' is a valid actual parameterlist. What about recursion? -manfred
Re: Arbitrary abbreviations in phobos considered ridiculous
On Fri, Mar 9, 2012 at 3:56 PM, Jonathan M Davis jmdavisp...@gmx.comwrote: On Friday, March 09, 2012 17:41:01 Steven Schveighoffer wrote: I'll say I *don't* agree with the rejection of aliases on principle -- aliases can be extremely useful/helpful, and they cost literally nothing (the cognitive cost on the docs is a BS argument IMO). I just don't agree with consuming so many common symbols for the sake of sugar. aliases need to have a really good argument for existing. If UFCS is fully implemented, then I think that there is _some_ argument for having stuff like hours and minutes, because then you can do stuff like 5.seconds() (though honestly, I really don't like the idea). The alias enables different usages rather than simply being another name for the same thing. What remains on UFCS? I've heard someone (Nick?) say he'd like it to match static member functions too. I haven't tested but it seems like 5.seconds() should work ever since Kenji's pull request was merged a couple of days ago (thanks Kenji and Walter, I'm really looking forward to that change). Regards, Brad Anderson Now, in this particular case, it's that much worse for exactly the reason that you're against it: it uses common names for free functions. It's not as big a problem as it would be in C or C++, but it's still a problem. There's also some risk that it will break code. - Jonathan M Davis
Re: Arbitrary abbreviations in phobos considered ridiculous
On 3/9/12 5:54 AM, Ary Manzana wrote: Sample Ruby session: irb ruby-1.8.7-p352 :001 [1, 2, 3].count = 3 ruby-1.8.7-p352 :002 [1, 2, 3].length = 3 ruby-1.8.7-p352 :003 [1, 2, 3].size = 3 I never saw *anyone* complaining about this. When you write, you choose whatever is convenient to you (whatever comes to your mind first). When you read it, it's understandable. Nobody wonders why didn't he wrote 'length' instead of 'size', because the meaning is clear. I don't think this sits well in the D culture. Andrei
Re: Breaking backwards compatiblity
Walter Bright newshou...@digitalmars.com wrote in message news:jje0er$24mb$1...@digitalmars.com... This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. Freezing things against breaking changes is all fine and good, but NOT before they're reached a point where they're good enough to be frozen. Premature freezing is how you create cruft and other such shit. Let's not go jumping any guns here.
Re: Breaking backwards compatiblity
On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote: On 09-03-2012 23:32, Walter Bright wrote: This statement is from Linus Torvalds about breaking binary compatibility: https://lkml.org/lkml/2012/3/8/495 While I don't think we need to worry so much at the moment about breaking binary compatibility with new D releases, we do have a big problem with breaking source code compatibility. This is why we need to have a VERY high bar for breaking changes. If we want to start being able to avoid breaking changes, we *really* need to finally deprecate the stuff that's been slated for deprecation for ages... [...] Does that include std.stdio and std.stream? When are we expecting std.io to be ready? IMHO, this is one major change that needs to happen sooner rather than later. The current lack of interoperability between std.stdio and std.stream is a big detraction from Phobos' overall quality. T -- Жил-был король когда-то, при нём блоха жила.
