[Dconf 2024] Phobos Golf
In golf, you try to hit a ball into a hole using the smallest amount of strokes. In code golf, you try to solve a programming puzzle using the smallest amount of key strokes. In Phobos golf, you additionally get to use all of Phobos! This small competition will during DConf'24. It is hosted on Discord: https://discord.gg/a6rm7mBU You send private messages to a bot called "Caddy" to make submissions, check out the #square channel for examples. The score for submissions is based on the token count, where literal and identifier tokens have variable costs based on their length. Detailed rules are in the #rules channel. Happy golfing!
Re: D Language Foundation May 2024 Monthly Meeting Summary
On 8/31/24 17:41, Timon Gehr wrote: On 8/30/24 22:36, Dukc wrote: > He said that going forward, accepting a bad DIP would be less consequential than it had been in the past once we had editions. In the worst case, we'd have one thing more to maintain in an intermediate edition before it was fixed. Maybe that was a calculation we could take into consideration. Átila said that was a good point. You should be at least as worried about the damage to contributor morale on a bad decision as about the damage to the language. Editions do good job limiting the latter but not the former. If you accept that you can see why this attitude is unnerving. Rejecting a DIP can be one of those bad decisions. Anyway, obviously I prefer good decisions over bad decisions, but language development is an incremental process and it helps if progress does not have to be fully monotone. (Accidentally hit send.)
Re: D Language Foundation May 2024 Monthly Meeting Summary
On 8/30/24 22:36, Dukc wrote: > He said that going forward, accepting a bad DIP would be less consequential than it had been in the past once we had editions. In the worst case, we'd have one thing more to maintain in an intermediate edition before it was fixed. Maybe that was a calculation we could take into consideration. Átila said that was a good point. You should be at least as worried about the damage to contributor morale on a bad decision as about the damage to the language. Editions do good job limiting the latter but not the former. If you accept that you can see why this attitude is unnerving. Rejecting a DIP can be one of those bad decisions. Anyway, obviously I prefer good decisions over bad decisions,
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On 12/11/23 20:55, Timon Gehr wrote: There is the following trick. Not ideal since the length cannot be inferred, but this successfully injects alloca into the caller's scope. I see Nick already brought it up.
Re: D Language Foundation October 2023 Quarterly Meeting Summary
On 12/6/23 17:28, Mike Parker wrote:
One way to do that in D is to use `alloca`, but that's an issue because
the memory it allocates has to be used in the same function that calls
the `alloca`. So you can't, e.g., use `alloca` to alloc memory in a
constructor, and that prevents using it in a custom array
implementation. He couldn't think of a way to translate it.
There is the following trick. Not ideal since the length cannot be
inferred, but this successfully injects alloca into the caller's scope.
```d
import core.stdc.stdlib:alloca;
import std.range:ElementType;
import core.lifetime:moveEmplace;
struct VLA(T,alias len){
T[] storage;
this(R)(R initializer,return void[]
storage=alloca(len*T.sizeof)[0..len*T.sizeof]){
this.storage=cast(T[])storage;
foreach(ref element;this.storage){
assert(!initializer.empty);
auto init=initializer.front;
moveEmplace!T(init,element);
initializer.popFront();
}
}
ref T opIndex(size_t i)return{ return storage[i]; }
T[] opSlice()return{ return storage; }
}
auto vla(alias len,R)(R initializer,void[]
storage=alloca(len*ElementType!R.sizeof)[0..len*ElementType!R.sizeof]){
return VLA!(ElementType!R,len)(initializer,storage);
}
void main(){
import std.stdio,std.string,std.conv,std.range;
int x=readln.strip.to!int;
writeln(vla!x(2.repeat(x))[]);
}
```
Re: Safer Linux Kernel Modules Using the D Programming Language
On 1/12/23 07:25, Walter Bright wrote: But also, adding dynamic arrays to C won't make the currently existing C code safer, the one they care about, because no one's gonna send the money to update their C89/99/whatever code to C23/26. Even if they did, there's no guarantee others would as well. You can incrementally fix code, as I do with the dmd source code (originally in C) regularly. Yes; _source code_. This is the crux of the matter. Can't incrementally fix source code that you don't have access to.
Re: DIP 1043---Shortened Method Syntax---Accepted
On 21.09.22 12:39, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. The fact that the feature was already implemented behind a preview switch carried weight with Atila. He noted that, if not for that, he wasn't sure where he would stand on adding the feature, but he could see no reason to reject it now. Walter accepted with a suggested (not a required) enhancement: It could be even shorter. For functions with no arguments, the () could be omitted, because the => token will still make it unambiguous. For example: T front() => from; becomes: T front => from; As DIP author, Max decided against this. He said it's not a bad idea, but it's then "inconsistent with other the other syntaxes". If there is a demand for this, it would be easy to add later, but he felt it's better to keep things simple for now by going with the current implementation as is. 🎉 Great news! :)
Re: Giving up
On 8/6/22 19:27, Rumbu wrote: On Saturday, 6 August 2022 at 08:29:19 UTC, Walter Bright wrote: On 8/5/2022 9:43 AM, Max Samukha wrote: Both "123." and "123.E123" is valid C. For some reason, D only copied the former. It's to support UFCS (Universal Function Call Syntax). The idea with C compatible aspects of D is to not *silently* break code when there's a different meaning for it. And so, these generate an error message in D (although the error message could be much better). So, does it work with ImportC? test2.c: float z = 85886696878585969769557975866955695.E0; long double x = 0x1p-16383; dmd -c test2.c test2.c(3): Error: number `0x1p-16383` is not representable It is. Since real exponent is biased by 16383 (15 bits), it is equivalent of all exponent bits set to 0. Probably it looks unimportant, but here it was about a floating point library. Subnormal values are part of the floating point standard. Seems you should just use a long double/real literal? real x = 0x1p-16383L; // (works)
Re: Beta 2.098.0
On 11.10.21 03:08, Paul Backus wrote: On Monday, 11 October 2021 at 00:34:28 UTC, Mike Parker wrote: On Sunday, 10 October 2021 at 23:36:56 UTC, surlymoor wrote: Meanwhile @live is in the language, and it's half-baked. Then there's preview switches that will linger on into perpetuity; DIPs' implementations that haven't been finished. And Walter has prioritized this issue over those. No matter what he works on, people will moan that he isn’t working on something else. Maybe we should clone him. Perhaps worth asking why Walter, specifically, is required to work on @live in order for it to make progress. Is it just because no one else is willing to step up to the plate, or is he the only person qualified/capable enough? I think @live is a dead end and any further work on it is probably wasted unless the code is reusable for some other feature. Ownership is a property of values, not of functions operating on those values. In particular, prioritizing ImportC over @live is the right call. ImportC is high-impact and Walter has a lot of relevant expertise.
Re: Please Congratulate My New Assistant
On 25.01.21 21:03, Paul Backus wrote: On Monday, 25 January 2021 at 12:48:48 UTC, Imperatorn wrote: But, at the same time, I guess it could be a bit demoralizing you know? That's true. I beg to differ. Open issues are not demoralizing. Sometimes, reality is demoralizing. That doesn't mean we should hide our heads in the sand and ignore it. What's demoralizing about this exchange is that it seems to imply there are people around who have nothing better to do than waiting for you to die so they can close your issues in the issue tracker. Apparently they will even feel like they are doing a good thing as they destroy your legacy. :(
Re: Please Congratulate My New Assistant
On 25.01.21 13:48, Imperatorn wrote: On Monday, 25 January 2021 at 10:39:14 UTC, Walter Bright wrote: On 1/24/2021 10:46 PM, Imperatorn wrote: Imo it's reasonable to close or archive issues that are older than 10 years. We are not going to do that just because they are old. If a bug still exists in the current DMD, the bug report stays open. I can understand why, I really do. ... Great, case closed.
Re: Please Congratulate My New Assistant
On 25.01.21 11:05, Imperatorn wrote: On Monday, 25 January 2021 at 06:59:00 UTC, ag0aep6g wrote: On 25.01.21 07:46, Imperatorn wrote: Proposed solution: Archive issues older than 10 years (and maybe some critera based on latest updated). If they are relevant, it's the authors responsibility to update the issue so that it's reproducible in the latest release. #reasonablebutcontroversial Just no. Reproducibility is a criterion. Age isn't. Sure, but how do you define it? If you need reproducibility to be defined, please stay away from the issue tracker.
Re: Please Congratulate My New Assistant
On 24.01.21 14:00, Max Haughton wrote: On Sunday, 24 January 2021 at 12:36:16 UTC, Timon Gehr wrote: On 18.01.21 10:21, Mike Parker wrote: Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family. Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community. So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton". And congratulate him while you're at it! Congratulations. However, Max seems to be just closing all enhancement requests on bugzilla as invalid. This is the behavior of a vandal. Please stop. Any policy that requires this is ill-advised. Issues are valuable and binning them like this is disrespectful to the time of the reporters. I was going through trying to close things that are either not bugs anymore because they haven't been touched from 2010 and they've been fixed by entropy, I can get behind this. You closed one of my issues that was fixed this way, but I don't usually report INVALID issues, this is why there is a WORKSFORME category. or language changes which will never be looked at again because they aren't DIPs. Of course they won't be looked at again if you claim they are invalid just by virtue of being enhancement requests. Obviously you looked at them now, so your reasoning here makes no sense. This is why there is an enhancement request category in the first place. They are not invalid issues, they are enhancement request issues. They're still in public record but fundamentally they're just not useful anymore Issues are not useful anymore when they are fixed or there is a good reason why they should not be fixed. - I was literally just going through bugs FILO and trying to either reproduce or at least characterise whether they even can be acted on by the foundation. ... Why does it seem like people who are hired to help improve D instead always start closing bugzilla issues without actually fixing them? This is meaningless optimization of indicators that don't even mean what you seem to think they mean. It's a waste of time and resources. It's entirely possible I was overzealous and if I was, obviously reopen them I don't have time for that, I don't get notified for all of them, just the ones I reported or interacted with. I have no idea what other potentially valuable enhancement requests you closed with a condescending "INVALID" verdict just because they were enhancement requests. Please reopen all enhancement requests that you closed even though they remain unfixed. but ultimately the enhancements have to go through a DIP because it's not 2012 anymore. ... That does not change what those enhancement requests are for, it just makes it a bit harder to fix them. Obviously, nowadays the proper way to get rid of enhancement requests is by pushing them through the DIP process (or perhaps just making a good point to the reporter why it would be a bad idea to implement them), but of course, that requires more work than a couple of clicks and button presses. Closing as invalid because it is an enhancement request is not a valid way to get rid of enhancement requests. If you really want to enact a policy that new enhancement requests should be illegal, I guess DLF can do that even though it is obviously a stupid idea (a DIP is a lot more formal, a large bar to overcome, so you will lose a lot of ideas), but how about you at least don't close issues that were made at a time when this was the officially encouraged way to track ideas? IMNSHO it should stay this way, there is no reason to dislike enhancement requests. They don't have the same purpose as DIPs (and DIPs are sometimes even necessary to fix issues that are not enhancement requests, for example type system unsoundness). I also updated Stephen S's shared-delegate race condition bug to have a test case that actually compiles, and that's from 2010 - theadsan catches it now although it doesn't work with @safe either so I'm not sure whether we should be embarrassed or not. There is certainly useful work to be done in the issue tracker. I am here objecting to certain systematic destructive practices that do not even have any upside. I wish this kind of behavior would stop forever. You are not the first person to engage into careless issue closing sprees. I think the underlying issue is a bad understanding of the value of issues in the issue tracker and some sort of irrational assignment of cost to open issues. Walter always says: Put this in bugzilla, it will get lost on the forums, and he is right.
Re: Please Congratulate My New Assistant
On 18.01.21 10:21, Mike Parker wrote: Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family. Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community. So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton". And congratulate him while you're at it! Congratulations. However, Max seems to be just closing all enhancement requests on bugzilla as invalid. This is the behavior of a vandal. Please stop. Any policy that requires this is ill-advised. Issues are valuable and binning them like this is disrespectful to the time of the reporters.
Re: Printing shortest decimal form of floating point number with Mir
On 06.01.21 07:50, Walter Bright wrote: > I want to execute the code that I wrote, not what you think I should have > instead written, because sometimes you will be wrong. With programming languages, it does not matter what you think you wrote. What matters is how the language semantics are defined to work. The language semantics right now are defined to not work, so people are going to rely on the common sense and/or additional promises of specific backend authors. People are going to prefer that route to the alternative of forking every dependency and adding explicit rounding to every single floating-point operation. (Which most likely does not even solve the problem as you'd still get double-rounding issues.) In writing professional numerical code, one must carefully understand it, knowing that it does *not* work like 7th grade algebra. That's why it's important to have precise control. Besides, a lot of contemporary applications of floating-point computations are not your traditional numerically stable fixed-point iterations. Reproducibility even of explicitly chaotic behavior is sometimes a big deal, for example for artificial intelligence research or multiplayer games. Also, maybe you don't want your code to change behavior randomly between compiler updates. Some applications need to have a certain amount of backwards compatibility. Different languages can and do behave differently, too. Or different implementations. I'm not going to switch languages due to an issue that's fixed by not using DMD.
Re: Printing shortest decimal form of floating point number with Mir
On 06.01.21 03:27, Walter Bright wrote: On 1/5/2021 5:30 AM, Guillaume Piolat wrote: It would be nice if no excess precision was ever used. It can sometimes gives a false sense of correctness. It has no upside except accidental correctness that can break when compiled for a different platform. That same argument could be use to always use float instead of double. I hope you see it's fallacious ... Evidence that supports some proposition may well fail to support a completely different proposition. An analogy for your exchange: G: Birds can fly because they have wings. W: That same argument could be used to show mice can fly. I hope you see it's fallacious Anyway, I wouldn't necessarily say occasional accidental correctness is the only upside, you also get better performance and simpler code generation on the deprecated x87. I don't see any further upsides though, and for me, it's a terrible trade-off, because possibility of incorrectness and lack of portability are among the downsides. I want to execute the code that I wrote, not what you think I should have instead written, because sometimes you will be wrong. There are algorithms in Phobos that can break when certain operations are computed at a higher precision than specified. Higher does not mean better; not all adjectives specify locations on some good/bad axis.
Re: Printing shortest decimal form of floating point number with Mir
On 23.12.20 16:37, Ola Fosheim Grøstad wrote: On Wednesday, 23 December 2020 at 03:06:51 UTC, 9il wrote: You, Andrey, and Atila don't care about language features that have been requested for Mir or even more: rejecting DIP draft + DMD partial implementation for no real reason. Out of curiosity, which language features would improve Mir? https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1023.md https://forum.dlang.org/post/kvcrsoqozrflxibgx...@forum.dlang.org https://forum.dlang.org/thread/gungkvmtrkzcahhij...@forum.dlang.org?page=1 https://forum.dlang.org/post/jwtygeybvfgbosxsb...@forum.dlang.org
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 16.06.20 17:35, Robert M. Münch wrote: On 2020-06-15 13:01:02 +, Timon Gehr said: The talk will be on YouTube. Great. Papers: https://www.sri.inf.ethz.ch/publications/bichsel2020silq https://www.sri.inf.ethz.ch/publications/gehr2020lpsi Source code: https://github.com/eth-sri/silq https://github.com/eth-sri/psi/tree/new-types Thanks, somehow missed these. ... I think they were not online when you asked (neither were the versions in ACM DL). What's the main difference of your approach WRT something like this: http://pyro.ai/ ... Pyro is a Python library/EDSL, while PSI is a typed programming language (with some support for dependent typing). Pyro's focus is on scalable machine learning. PSI alone would not be particularly helpful there. Pyro fits a parameterized probabilistic model to data using maximum likelihood estimation while at the same time inferring a posterior distribution for the latent variables of the model. If you use a probabilistic model without parameters, Pyro can be used for plain probabilistic inference without maximum likelihood estimation. PSI currently does not do optimization, just probabilistic inference. (PSI can do symbolic inference with parameters, then they can be optimized with some other tool.) The goal is to find a distribution such that KL-divergence of the posterior and this distribution is as small as possible. PSI always finds the true posterior when it is successful (i.e. KL-divergence 0 when applicable), but will not always succeed, in particular, it might not be fast enough, or the result may not be in a useful form. Pyro produces best-effort results. You may have to use some sort of validation to make sure that results are useful. - The posterior distribution is assumed to have a specific form that can be represented symbolically and is normalized by construction. Often, the true posterior is not actually (known to be) in that family. - The KL-divergence is upper-bounded using ELBO (evidence lower bound). - The (gradient of the) ELBO is approximated by sampling from the assumed posterior with current parameters. - This approximate ELBO is approximately optimized using gradient descent. Also see: https://pyro.ai/examples/svi_part_i.html BTW: I'm located in Zug... so not far away from you guys.
Re: Interesting work on packing tuple layout
On 15.06.20 16:03, Max Samukha wrote:
On Monday, 15 June 2020 at 13:57:01 UTC, Max Samukha wrote:
void main() {
Tuple!(byte, int, short) t;
writeln(t[0]);
}
test.d(57,23): Error: need `this` for `__value_field_2` of type `byte`
It should work. This works:
void main() {
Tuple!(byte, int, short) t;
t[0] = 0;
t[1] = 2;
t[2] = 3;
auto a0 = t[0];
auto a1 = t[1];
}
}
I cannot reproduce the error. writeln(t[0]) works here:
https://run.dlang.io/is/kz6lFc
Apparently, it has been fixed in 2.092. Nice!
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 15.06.20 09:46, M.M. wrote: On Sunday, 14 June 2020 at 20:22:41 UTC, Timon Gehr wrote: For PLDI 2020, I have contributed to the following research papers: https://pldi20.sigplan.org/details/pldi-2020-papers/47/Silq-A-High-Level-Quantum-Language-with-Safe-Uncomputation-and-Intuitive-Semantics https://pldi20.sigplan.org/details/pldi-2020-papers/46/-PSI-Exact-Inference-for-Higher-Order-Probabilistic-Programs Congratulations. ... Thanks! The only relation to D is that the implementations of the two presented programming languages are written in D. Does that mean that your junior co-author(s) use D as well? Occasionally.
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 15.06.20 08:58, Robert M. Münch wrote: On 2020-06-14 20:22:41 +, Timon Gehr said: https://pldi20.sigplan.org/details/pldi-2020-papers/46/-PSI-Exact-Inference-for-Higher-Order-Probabilistic-Programs This one sounds pretty interesting. Will there be a recording and a published paper be available? The talk will be on YouTube. Papers: https://www.sri.inf.ethz.ch/publications/bichsel2020silq https://www.sri.inf.ethz.ch/publications/gehr2020lpsi Source code: https://github.com/eth-sri/silq https://github.com/eth-sri/psi/tree/new-types
Re: This Right In: PLDI 2020 will take place online and registration is FREE. Closes on Jun 5, so hurry!
On 04.06.20 14:46, Andrei Alexandrescu wrote: PLDI (Programming Language Design and Implementation) is a top academic conference. This year PLDI will be held online and registration is free. This is an amazing treat. https://conf.researchr.org/home/pldi-2020 Workshops and tutorials (also free) are of potential interest. These caught my eye: https://pldi20.sigplan.org/home/SOAP-2020 (on the 15th) https://conf.researchr.org/track/ismm-2020/ismm-2020 (on the 16th) For PLDI 2020, I have contributed to the following research papers: https://pldi20.sigplan.org/details/pldi-2020-papers/47/Silq-A-High-Level-Quantum-Language-with-Safe-Uncomputation-and-Intuitive-Semantics https://pldi20.sigplan.org/details/pldi-2020-papers/46/-PSI-Exact-Inference-for-Higher-Order-Probabilistic-Programs The only relation to D is that the implementations of the two presented programming languages are written in D.
Re: Interesting work on packing tuple layout
On 14.06.20 20:25, Paul Backus wrote: On Sunday, 14 June 2020 at 16:26:17 UTC, Avrina wrote: The situation also applies to the only tuple implementation in D. If you are proposing a new type with emphasis on reducing the footprint of the tuple then I don't see a problem with that. Changing the existing tuple implementation would be problematic. Presumably any such change would be made backwards-compatible. So Tuple.opIndex and Tuple.expand would still return elements in the order specified by the user, even if that order is different from the internal storage order. Indeed, that's why I noted that the obvious way to achieve that does not work. Although some assumptions will break, for example, there might be code that assumes that tupleof does the same thing as expand. I was thinking about e.g., manual cache optimization, but reducing size in the common case where such considerations are not made may well be more important. If it can be done at all; I am not currently aware of a workaround.
Re: Interesting work on packing tuple layout
On 13.06.20 21:11, Andrei Alexandrescu wrote:
https://github.com/ZigaSajovic/optimizing-the-memory-layout-of-std-tuple
Would be interesting to adapt it for std.tuple.
That's likely to run into the following arbitrary language limitation:
---
alias Seq(T...)=T;
struct T{
int a,b;
alias expand=Seq!(b,a);
}
void main(){
import std.stdio;
writeln(T(1,2).expand);
}
---
Error: need `this` for `b` of type `int`
Error: need `this` for `a` of type `int`
---
Another question is if automatic packing is worth making the layout
harder to predict.
Re: DIP 1028 "Make @safe the Default" is dead
On 29.05.20 06:53, Walter Bright wrote: The subject says it all. Thanks! For the record, this would have been my preference: fix @safe, @safe by default > fix @safe, @system by default > don't fix @safe, @system by default > don't fix @safe, @safe by default While this retraction improves matters in the short term, I think there is still potential for improvement. In particular, `@safe` is still broken for function prototypes. I recommending adding `safe:` as the first line in all your project modules It would be great if `@safe:` did not affect declarations that would otherwise infer annotations.
Re: Rationale for accepting DIP 1028 as is
On 28.05.20 10:50, Daniel Kozak wrote: He seems to think that weakening @safe is worth doing, because it will ultimately mean that more code will be treated as @safe and mechnically checked by the compiler, And I believe he is right. No, it's a false dichotomy. Weakening @safe to allow more code to be @safe might have been sensible if there was no @trusted annotation. However, as things stand, @trusted is sufficient as a tool to introduce potentially wrong assumptions about memory safety, we don't need more, especially not implicit ones. The reason why people are not using @safe is partly that it is not the default, but it is mostly that their library dependencies _including Phobos_ are not properly annotated. This needs actual work to fix. If there is significant perceived value in performing @safety checks in @system code, we can add a new function attribute that causes non-transitive @safe checks but otherwise gets treated as @system. @safe does not have to take this role.
Re: Rationale for accepting DIP 1028 as is
On 27.05.20 12:51, Walter Bright wrote: On 5/27/2020 3:01 AM, Timon Gehr wrote: This is clearly not possible, exactly because the old @safe rules are stronger. Thank you. We can agree on something. ... I am not sure if you noticed that I agree with most of your points, just not about their relevance to the topic at hand. But why exactly should API breakage not count? I've addressed exactly this a dozen times or more, to you No. You did not. I went over all of your responses to my posts again to make sure. Why are you making this claim? I haven't made API breakage a central point to any of my previous posts and you did not address any of my criticism in any depth. As far as I can tell, the only point you engaged with was that @trusted is not greenwashing. and others. I don't think you did, but I am not going to check. Repeating myself has become pointless. It's fine to disagree with me. Argue that point. But don't say I didn't address it. As far as I remember, you did not address this specific point, but if I had to extrapolate your response from previous points you made I would expect your opinion to be that implicitly broken APIs should be fixed by universal manual review of not explicitly annotated functions and that this is better than the compiler catching it for you because this way only people who are competent to judge which annotation should be there will notice that it is missing.
Re: Rationale for accepting DIP 1028 as is
On 27.05.20 07:54, Walter Bright wrote: On 5/26/2020 1:32 PM, Paul Backus wrote: The reason extern function declarations are particularly problematic is that changing them from @system-by-default to @safe-by-default can cause *silent* breakage in existing, correct code. Can you post an example of currently compiling and correctly working code that will break? Setting aside use of __traits(compiles, ...). What exactly is your standard here? Are you saying we have to produce the following? - Monolithic example, API breakage does not count. - No __traits(compiles, ...) - The code has to compile under both old and new rules. - The code has to corrupt memory in @safe code under new rules. This is clearly not possible, exactly because the old @safe rules are stronger. But why exactly should API breakage not count?
Re: Rationale for accepting DIP 1028 as is
On 27.05.20 11:34, Bastiaan Veelo wrote: On Wednesday, 27 May 2020 at 09:09:58 UTC, Walter Bright wrote: On 5/26/2020 11:20 PM, Bruce Carneal wrote: I'm not at all concerned with legacy non-compiling code of this nature. Apparently you agree it is not an actual problem. Really? I don't know if you really missed the point being made, or you're being provocative. Both seem unlikely to me. -- Bastiaan. It's just selective reading and confirmation bias. Walter did not read past the quoted sentence as it successfully slaughters the straw man he set up in his previous post.
Re: DIP1028 - Rationale for accepting as is
On 26.05.20 13:09, Atila Neves wrote: On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote: On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote: A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness. Ideally you should be able to blindly mark every function definition with @safe, because the compiler will catch you if you fall. Only if you type @trusted you should need to be careful. Doesn't work for templated functions since their @safety might depend on the the particular instantiation (consider std.algorithm.map). I think the point was that annotating with @safe liberally should not enable memory corruption.
Re: DIP1028 - Rationale for accepting as is
On 25.05.20 14:22, Johannes T wrote: On Monday, 25 May 2020 at 11:52:27 UTC, Timon Gehr wrote: On 25.05.20 11:25, Johannes T wrote: @trusted can't be trusted That's the point of @trusted. ._. The code is trusted by the programmer, not the annotation by the compiler. Sorry, I phrased it poorly. I meant @trusted would be used more frequently. The focus would spread and lead to less rigorous checks. This is just not true. If the compiler forces you to decide to put either @trusted or @system, then you will not get more usage of @trusted than if it implicitly decides for you that what you want is implicit @trusted.
Re: DIP1028 - Rationale for accepting as is
On 25.05.20 11:25, Johannes T wrote: @trusted can't be trusted That's the point of @trusted. ._. The code is trusted by the programmer, not the annotation by the compiler.
Re: DIP1028 - Rationale for accepting as is
On 24.05.20 11:10, Walter Bright wrote: On 5/23/2020 11:26 PM, Bruce Carneal wrote: I don't believe that you or any other competent programmer greenwashes safety critical code. Regardless, the safety conscious must review their dependencies whatever default applies. That's the theory. But we do, for various reasons. I've seen it a lot over the years, at all levels of programming ability. It particularly happens when someone needs to get the code compiling and running, and the error message is perceived as a nuisance getting in the way. We should be very careful about adding nuisances to the language that make it easier to greenwash than to do the job correctly. Implicit greenwashing by the compiler is a nuisance that makes it harder to do the job correctly and easier to do the wrong thing.
Re: DIP1028 - Rationale for accepting as is
On 24.05.20 10:55, Walter Bright wrote: I infer your position is the idea that putting @trusted on the declarations isn't greenwashing, while @safe is. ... It's only greenwashing if it's misleading. Putting @safe is a lie, putting @trusted is honest. I can't see a practical difference between: @safe extern (C) void whatevs(parameters); @trusted extern (C) void whatevs(parameters); Both require that whatevs() provide a safe interface. The difference between them is in the implementation of those functions, not the interface. Since the D compiler cannot see those implementations, they are immaterial to the compiler and user. Sure, that's the point. Your @safe by default DIP in practice makes certain declarations @trusted by default. @safe is a fine default. @trusted is a horrible default. That's why your DIP claims it is for @safe by default (and not @trusted by default). Except in this one weird special case, where it introduces @trusted by default.
Re: DIP1028 - Rationale for accepting as is
On 24.05.20 05:28, Walter Bright wrote: I'd like to emphasize: I understand all of those points and most of them are true, and obvious. The issue is that they are not a justification for the decision. You seem to think that greenwashing is not greenwashing when it is done by the compiler without user interaction. Why is that? 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe. ... Which is exactly why it should not be possible to declare it @safe. 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. ... Slapping @safe on it should not even compile. You should slap either @system or @trusted on it. 3. Un-annotated declarations are easily detectable in a code review. ... It's easier to find something that is there than something that is not there. Greenwashing is not easier to detect if the compiler did it implicitly. 4. Greenwashing is not easily detectable in a code review. ... Even though it is easy to miss in a code review, it's easy to detect automatically. Any extern(C) prototype that is annotated @safe (explicitly or implicitly) is greenwashed. 5. Greenwashing doesn't fix anything. The code is not safer. Actually further down you say that it makes the code safer in a "not-at-all obvious way". Which is it? It's an illusion, not a guarantee. ... Yes. On the other hand, @trusted is not an illusion, it is a way to clarify responsibilities. 6. If someone cares to annotate declarations, it means he has at least thought about it, because he doesn't need to. True, but this is an argument against restrictive defaults in general, in particular @safe by default. Also note that if someone cares to annotate declarations, the compiler pointing out missing annotations that would otherwise cause implicit greenwashing is _useful_. Hence it's more likely to be correct than when greenwashed. ... This is true whether or not the compiler does the greenwashing implicitly. Annotating with @safe is a lie, whether the compiler does it or the programmer. It should be rejected and force @system or @trusted. You can still quickly see a difference in applied care by checking whether it's a single @trusted: or each prototype is annotated individually. 7. D should *not* make it worthwhile for people to greenwash code. ... Greenwashing automatically is not a solution, it's admitting defeat. Why can't the compiler just reject greenwashing with @safe? Slapping @trusted on prototypes is not greenwashing, it's saying "I take responsibility for the memory safety of this external C code". It is, in a not-at-all obvious way, safer for C declarations to default to being safe. @safe is advertised to give mechanical guarantees, where @trusted is a way for programmers to take responsibility for parts of the code. It is not advertised to be an unsound linter with pseudo-pragmatic trade-offs and implicit false negatives.
Re: DIP1028 - Rationale for accepting as is
On 22.05.20 18:43, Adam D. Ruppe wrote: On Friday, 22 May 2020 at 16:39:42 UTC, jmh530 wrote: Fortunately, the above point can be more easily fixed by making `free` @system With the o/b system `free` might actually work out OK free(new int);
Re: DIP1028 - Rationale for accepting as is
On 22.05.20 16:49, bachmeier wrote: On Friday, 22 May 2020 at 14:38:09 UTC, Timon Gehr wrote: On 22.05.20 15:58, bachmeier wrote: ... Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical? Honesty is what's critical. The annotations should mean what they are advertised to mean and making those meanings as simple as possible makes them easier to explain. As things stand, @safe can mean that someone accidentally or historically did not annotate an extern(C) prototype and an unsafe API a few calls up was ultimately exposed with the @safe attribute because the compiler never complained. In my opinion, the only advantage of @safe is that the compiler has checked the code and determines that it only does things considered safe. Wrong, but let's roll with that. I don't see that marking an extern(C) function @trusted buys you anything, at least not until you can provide a compiler guarantee for arbitrary C code. It buys you the ability to call that function from @safe code. Clearly you can't mark it @safe because the compiler has not checked it.
Re: DIP1028 - Rationale for accepting as is
On 22.05.20 15:58, bachmeier wrote: ... Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical? Honesty is what's critical. The annotations should mean what they are advertised to mean and making those meanings as simple as possible makes them easier to explain. As things stand, @safe can mean that someone accidentally or historically did not annotate an extern(C) prototype and an unsafe API a few calls up was ultimately exposed with the @safe attribute because the compiler never complained. How would you feel if you never intended to expose a @safe interface, but someone imported your library after determining it contained no @trusted annotations (following the advice of articles on @safe), relied on the @safe annotation and then had weird sporadic memory corruption issues in production that took them months to ultimately trace back to your library? Would you feel responsible or would you rather put the blame on Walter?
Re: DIP1028 - Rationale for accepting as is
On 22.05.20 03:22, Walter Bright wrote: This is Obviously A Good Idea. Why would I oppose it? 1. I've been hittin' the crack pipe again. 2. I was secretly convinced, but wanted to save face. 3. I make decisions based on consultation with my astrologer. 4. I am evil. 5. You are backwards-rationalizing a wrong intuition that is based on experiences that are not actually analogous. You are ignoring feedback given by many people around you because that worked out well for you in the past. I know that you had many interactions with large groups of ignorant people who thought that you would never be able to pull off a certain thing. This is not one of those cases. I understand the appeal, but the backlash really should not encourage you to soldier on this time. 1. Go through 200 functions in clibrary.d and determine which are @safe and which are @system. This is what we want them to do. We try to motivate this with compiler error messages. Unfortunately, this is both tedious and thoroughly impractical, as our poor user Will Not Know which are safe and which are system. We can correctly annotate core.stdc.stdio because I know those functions intimately. This is not true for other system C APIs, and even less true for some third party C library we're trying to interface to. 2. Annotate useClibrary() as @trusted or @system. While easier, First do 2, then, over time, do 1. If having the @safe tag and no @trusted code is important to you, aim to replace the C code with something you can automatically verify, by slowly porting it over to D. this causes all benefits to @safe by default to be lost. Absolutely not. Greenwashing causes the benefits of certification to be lost. Honesty does not. The value of @safe code is what it is because there is code that can't be @safe. 4. Edit clibrary.d and make the first line: @safe: I submit that, just like with Java, Option 4 is what people will reach for, nearly every time. I've had some private conversations where people admitted this was what they'd do. People who knew it was wrong to do that. ... They should know to put @trusted instead of @safe, and the compiler should enforce it. Also, why do those people speak for everyone else? They don't speak for me. If it's @safe by default, and then someone chooses to annotate it with @system here and there, I'd feel a lot more confident about the accuracy of the code annotations than if it just had @safe: at the top. At least they tried. ... If it has @safe:/@trusted: at the top at least you know they were aware what they were doing. Also, what about if it has @trusted: at the top and some @system annotations here and there? Did they not try? What is actually accomplished with this amendment if it was implemented? 1. Adds a funky, special case rule. It's better to have simple, easily understood rules than ones with special cases offering little improvement. ... What about the funky special case rule that the compiler is responsible for memory safety of @safe code except in this one weird special case? 2. Existing, working code breaks. ... Making @safe the default is bound to break code. It's bad enough that code will break. Avoiding part of that code breakage is no justification for breaking @safe. 3. The most likely code fixes are to just make it compile, absolutely nothing safety-wise is improved. The added annotations will be a fraud. ... It's vastly better to have some fraudulent annotations in some projects than a fraudulent compiler compiling all projects. Do you really want to put the responsibility for the memory safety of random C libraries on the compiler developers? D should not encourage "greenwashing" practices like the Java exception specification engendered. So your argument is that you don't want D programmers to do have to do the dirty work of greenwashing. Therefore the compiler will implicitly greenwash for them? What about the programmers who actually want to do the right thing and don't want the compiler to implicitly greenwash C libraries for them? The compiler cannot vet the accuracy of bodyless C functions, and we'll just have to live with that. The proposed amendment does not fix that. ... @trusted is the fix. And so, I did not incorporate the proposed amendment to the Safe by Default DIP. Which (so far) is a harmless mistake with an easy fix.
Re: Ownership and Borrowing in D
On 23.07.19 10:20, Sebastiaan Koppe wrote: On Tuesday, 23 July 2019 at 04:02:50 UTC, Timon Gehr wrote: On 21.07.19 02:17, Walter Bright wrote: On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote: Do you mean to keep track of ownership/borrowedness manually? No, that's what the copyctor/opAssign/dtor semantics so. This is not true. I thought as much. Thanks for the confirmation. I am considering moving to pointers to benefit from the future semantics. It's just that I don't like pointers that much... I think tying ownership/borrowing semantics to pointers instead of structs makes no sense; it's not necessary and it's not sufficient. Your use case illustrates why it is not sufficient.
Re: Ownership and Borrowing in D
On 21.07.19 02:17, Walter Bright wrote: On 7/20/2019 3:39 PM, Sebastiaan Koppe wrote: Do you mean to keep track of ownership/borrowedness manually? No, that's what the copyctor/opAssign/dtor semantics so. This is not true.
Re: Ownership and Borrowing in D
On 17.07.19 22:59, Walter Bright wrote: Any competing system would need to not be 'opt-in' on a type by type basis. I.e. the central feature of an @live function is the user will not be able to write memory unsafe code within that function. Those two things are not the least bit at odds with each other. You only need to do the additional checks for types that actually need it. (And there you need to _always_ do them in @safe code, not just in specially-annotated "@live" functions.) A dynamic array of integers that is owned by the garbage collector doesn't need any O/B semantics. A malloc-backed array that wants to borrow out its contents needs to be able to restrict @safe access patterns to ensure that the memory stays alive for the duration of the borrow. Furthermore, making built-in types change meaning based on function attributes is just not a good idea, because you will get needless friction at the interface between functions with the attribute and functions without. Anyway, it makes no sense to have a variable of type `int*` that owns the `int` it points to (especially in safe code), because that type doesn't track how to deallocate the memory. Ownership and borrowing should be supported for user-defined types, not raw pointers. Rust doesn't track ownership for built-in pointers. In Rust, raw pointer access is unsafe.
Re: DIP 1016--ref T accepts r-values--Formal Assessment
On 01.02.19 10:10, aliak wrote:
Shouldn't doubleMyValue(pt.x) be a compiler error if pt.x is a getter?
For it not to be a compile error pt.x should also have a setter, in
which case the code needs to be lowered to something else:
{
auto __temp = pt.x;
doubleMyValue(__temp);
pt.x = __temp;
}
I believe this is something along the lines of what Swift and C# do as
well.
Or something... a DIP to fix properties anyone? :)
http://wilzbach.github.io/d-dip/DIP24
I'm not sure your rewrite is good though, because it does not preserve
aliasing during the function call.
Re: On D in competitive programming
On 30.07.2018 21:44, Steven Schveighoffer wrote: On 7/28/18 3:51 PM, Ivan Kazmenko wrote: Hey, I wrote a post with my general reflections on using D in competitive programming. Mostly compared to C++, since that's what more than 90% of people use for it. The post is tailored to cover only the competitive programming specifics. http://codeforces.com/blog/entry/60890 (en+ru, the language switch is at the top) Good read. a lifetime ago, I competed using topcoder (and wrote a bunch of problem sets for them too). Topcoder had a "challenge" phase, where you could challenge the solutions of others. Is there anything like that in codeforces, and if so, is D an advantage as a "somewhat obscure" language (i.e. competitors can't always understand your code)? Just curious :) -Steve On codeforces it's called "hacks", but it happens during the contest. Therefore, if your solution were to be "hacked" it would actually likely be good for you because you get a chance to fix your code before the contest ends.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On 07.04.2018 00:45, Timon Gehr wrote: On 06.04.2018 19:36, H. S. Teoh wrote: On Fri, Apr 06, 2018 at 05:02:54PM +, Adam D. Ruppe via Digitalmars-d-announce wrote: On Friday, 6 April 2018 at 16:57:21 UTC, Jonathan M Davis wrote: Now, if the contracts ended up in the documentation or something My documentation generator supports contracts, but I found in practice, most of them are so illegible it doesn't actually help any to include them, so I never do. But if they were simpler single expressions, it might make sense to revisit that. Yeah, I think having expression syntax will make contracts more readable. We'll just have to see. When will this DIP be implemented? AIUI Timon already has an implementation sitting around somewhere. Can't wait for it to get merged... T I'll rebase it against master and create a pull request ASAP. I created a pull request: https://github.com/dlang/dmd/pull/8155 It took a while to rebase, as relevant parts of the compiler have been refactored in the meantime.
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On 06.04.2018 19:36, H. S. Teoh wrote: On Fri, Apr 06, 2018 at 05:02:54PM +, Adam D. Ruppe via Digitalmars-d-announce wrote: On Friday, 6 April 2018 at 16:57:21 UTC, Jonathan M Davis wrote: Now, if the contracts ended up in the documentation or something My documentation generator supports contracts, but I found in practice, most of them are so illegible it doesn't actually help any to include them, so I never do. But if they were simpler single expressions, it might make sense to revisit that. Yeah, I think having expression syntax will make contracts more readable. We'll just have to see. When will this DIP be implemented? AIUI Timon already has an implementation sitting around somewhere. Can't wait for it to get merged... T I'll rebase it against master and create a pull request ASAP.
Re: Release D 2.076.0
On 07.09.2017 09:48, Rainer Schuetze wrote: I've added two more: https://issues.dlang.org/show_bug.cgi?id=17812 https://github.com/dlang/dmd/pull/7127 https://issues.dlang.org/show_bug.cgi?id=17814 https://github.com/dlang/dmd/pull/7126
Re: Release D 2.076.0
On 04.09.2017 21:55, Timon Gehr wrote: On 04.09.2017 16:05, nkm1 wrote: On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote: This release comes with static foreach Great! I noticed one small issue, though. When compiled with warnings, it warns about unreachable code when static foreach in a switch, ... It works, though, so I guess it's not a bug per se. This is actually a bug. Thanks! https://issues.dlang.org/show_bug.cgi?id=17807 https://github.com/dlang/dmd/pull/7120 (This bug was actually not within the static foreach implementation.)
Re: Release D 2.076.0
On 04.09.2017 16:05, nkm1 wrote: On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote: This release comes with static foreach Great! I noticed one small issue, though. When compiled with warnings, it warns about unreachable code when static foreach in a switch, ... It works, though, so I guess it's not a bug per se. This is actually a bug. Thanks! https://issues.dlang.org/show_bug.cgi?id=17807
Re: Release D 2.076.0
On 04.09.2017 12:46, Petar Kirov [ZombineDev] wrote: Would you be able to also address https://issues.dlang.org/show_bug.cgi?id=17798? https://github.com/dlang/dlang.org/pull/1884 (Any help with getting it to build appreciated -- even the base 'stable' branch does not compile on my machine.)
Re: Release D 2.076.0
On 04.09.2017 11:00, Timon Gehr wrote: On 02.09.2017 08:51, Ilya Yaroshenko wrote: On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote: Glad to announce D 2.076.0. This release comes with static foreach, many -betterC enhancements, various phobos additions, an -mcpu=avx2 switch, and lots of bugfixes. Thanks to everyone involved in this 👏. http://dlang.org/download.html http://dlang.org/changelog/2.076.0.html - -Martin First "static foreach" bug report https://issues.dlang.org/show_bug.cgi?id=17800 Thanks, but actually it is the second one. ;) https://issues.dlang.org/show_bug.cgi?id=17688 I'll get to work. https://github.com/dlang/dmd/pull/7118
Re: Release D 2.076.0
On 02.09.2017 08:51, Ilya Yaroshenko wrote: On Friday, 1 September 2017 at 14:03:26 UTC, Martin Nowak wrote: Glad to announce D 2.076.0. This release comes with static foreach, many -betterC enhancements, various phobos additions, an -mcpu=avx2 switch, and lots of bugfixes. Thanks to everyone involved in this 👏. http://dlang.org/download.html http://dlang.org/changelog/2.076.0.html - -Martin First "static foreach" bug report https://issues.dlang.org/show_bug.cgi?id=17800 Thanks, but actually it is the second one. ;) https://issues.dlang.org/show_bug.cgi?id=17688 I'll get to work.
Re: DIP 1010--Static foreach--Accepted
On 18.07.2017 00:44, Andrei Alexandrescu wrote: On 7/17/17 8:38 AM, Steven Schveighoffer wrote: What is the resolution of how break statements affect static foreach/foreach? We initially allowed break and continue to refer to the enclosing statement, but upon further consideration we will make it an error. This allows us to collect more experience with the feature and leaves us the option to permit break/continue later on. I have contacted Timon about the matter. Thanks! -- Andrei https://github.com/dlang/DIPs/pull/87 https://github.com/dlang/dmd/pull/7009
Re: Trip notes from Israel
On 22.05.2017 17:38, Adam D. Ruppe wrote: On Monday, 22 May 2017 at 15:26:26 UTC, Andrei Alexandrescu wrote: Yah, didn't want to overload the article (or the discussion) with the expression/statement distinction. -- Andrei Yeah, the details might be too much for a general audience (and I realize you know this, I'm commenting more for other readers who might be interested), but I do think this illustrates an important point for anyone who wants to use mixin: it is similar to, but not exactly like copy/pasting code into the source. mixin parses a piece of code, then pastes the *AST node*, not the source code, into the tree where the mixin is found. That's why the semicolon is required in the statement context - it needs a complete branch that actually fits the AST at the moment, not just a string that is pasted into the source code at the location. So similar enough to copy/paste to get someone quickly started playing with code generation, but this key difference is needed to really understand it. The grammar has: expression; as a statement. mixin(...) as an expression and mixin(...); as a statement Hence, mixin(...); is actually grammatically ambiguous and the behaviour of the compiler is somewhat arbitrary. The compiler could easily compensate for the ambiguity during semantic and not require the terminating semicolon when parsing the string of a mixin statement.
Re: Working code in an upcoming PR by Timon Gehr
On 07.05.2017 19:03, Stanislav Blinov wrote:
On Sunday, 7 May 2017 at 16:57:58 UTC, Andrei Alexandrescu wrote:
Zoom in on the screen for a nice surprise! http://imgur.com/a/qjI4l --
Andrei
I see only unsurprising Jpeg artifacts and not much more :)
It's too low resolution to make anything out.
It's approximately this:
---
alias Seq(T...)=T;
void main(){
import std.stdio: writeln;
import std.conv: to;
static foreach(i;Seq!(0,1,2)){
mixin(`int x`~to!string(i)~" = i;");
}
writeln(x0," ",x1," ",x2);
}
---
./src/dmd -run staticforeach.d
DMD v2.075.0-devel-fd4ff76 DEBUG
0 1 2
---
That was the first test case that worked.
I have made it almost feature-complete yesterday:
https://github.com/tgehr/dmd/blob/static-foreach/test_staticforeach.d
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 24.04.2017 19:02, Nick Sabalausky (Abscissa) wrote: On 04/24/2017 11:17 AM, Timon Gehr wrote: Also, Java's type system is unsound. Not doubting you, but this sounds interesting. Further info or links? https://dev.to/rosstate/java-is-unsound-the-industry-perspective
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On 24.04.2017 13:33, Ola Fosheim Grøstad wrote: On Monday, 24 April 2017 at 06:37:40 UTC, Walter Bright wrote: The trouble is, one cannot look at a piece of code and tell if it follows the rules or not. I.e. it's not about it being possible to write memory safe code in C or C++ (it is), it's about verifying an arbitrary piece of code as being memory safe. I don't think D and Rust fare any better than modern C++ as far as ARBITRARY code goes. Swift and Java does... Swift allows raw pointer manipulation. Java implementations expose similar unsafe features. JVMs have bugs. Also, Java's type system is unsound.
Re: DIP 1003: remove `body` as a keyword
On 25.11.2016 22:18, Sönke Ludwig wrote:
Am 25.11.2016 um 12:39 schrieb Timon Gehr:
On 24.11.2016 10:24, Kagamin wrote:
I see no ambiguity even if parsing is not greedy.
import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo()in{ assert(true); }{
writeln("Hello World!");
}
void main(){
static extern(C) void foo()in{ assert(true); }
{ foo(); }
}
Removing contracts, is this this code (printing "Hello World!"):
import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo(){
writeln("Hello World!");
}
void main(){
static extern(C) void foo();
{ foo(); }
}
Not without explicitly adding that ";".
?
The point here was to illustrate what the two possible interpretations
are in terms of code that is compatible with current D. The syntax for
body-less function declarations with contracts proposed in pull 3611 [1]
does not require a ';' to be present.
[1] https://github.com/dlang/dmd/pull/3611
The interpretation you are complaining about is in fact the standard
interpretation without option 3, but with contracts on function
declarations.
Re: DIP 1003: remove `body` as a keyword
On 24.11.2016 10:24, Kagamin wrote:
On Wednesday, 23 November 2016 at 20:24:13 UTC, Timon Gehr wrote:
Technically, there is an ambiguity (technically, ambiguity means that
there are multiple grammar derivations resulting in the same sentence).
Pragmatically, the greedy parse-the-body-if-possible-approach will work.
I see no ambiguity even if parsing is not greedy.
import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo()in{ assert(true); }{
writeln("Hello World!");
}
void main(){
static extern(C) void foo()in{ assert(true); }
{ foo(); }
}
Removing contracts, is this this code (printing "Hello World!"):
import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo(){
writeln("Hello World!");
}
void main(){
static extern(C) void foo();
{ foo(); }
}
Or this code (linker error):
import std.stdio;
pragma(mangle,"_D2tt4mainFZ3fooUZv")
void foo(){
writeln("Hello World!");
}
void main(){
static extern(C) void foo()
{ foo(); }
}
Re: DIP 1003: remove `body` as a keyword
On 24.11.2016 10:47, Kagamin wrote: As to contracts without body we have https://issues.dlang.org/show_bug.cgi?id=4720 There is even this: https://github.com/dlang/dmd/pull/3611 (Only works for interfaces and abstract classes though. Note that the parser didn't change.)
Re: DIP 1003: remove `body` as a keyword
On 24.11.2016 12:35, Sönke Ludwig wrote:
Am 23.11.2016 um 21:32 schrieb Timon Gehr:
On 23.11.2016 11:15, Sönke Ludwig wrote:
scope (exit) { assert(n > 0); }
{
n += 1;
}
This is not a counterexample, because the block statement following the
scope statement is not part of the scope statement. I.e. if anything, it
is bad that this looks similar, because it is grammatically different.
The function body isn't part of the "in"/"out" contract either. I don't
see the point here.
...
There can be no free-standing contract, it's part of the function signature.
(Also, in my code there are usually exactly zero block statements nested
directly in block statements.)
The whole topic in general so far seems to be mainly hinged around
personal taste (me included). Not sure if we'll be able to reach consent
for anything but option 1.
That's understood (this is about syntax).
BTW, a point against option 2 is: "body" is actually one of the few
keywords that D has that have adequate names. It's the body that
follows, not the function.
Re: DIP 1003: remove `body` as a keyword
On 23.11.2016 11:15, Sönke Ludwig wrote:
The more important point is that there is no precedent where {...}{...}
are two components of the same entity, it looks ugly even with the
space-wasting convention where '{' is put on its own line. Not all
contracts are one-liners like in your example above (which looks almost
tolerable).
It can happen all the time with normal block statements. Especially
something like 'scope' that works outside of the normal program flow has
a certain similarity:
scope (exit) { assert(n > 0); }
{
n += 1;
}
This is not a counterexample, because the block statement following the
scope statement is not part of the scope statement. I.e. if anything, it
is bad that this looks similar, because it is grammatically different.
(Also, in my code there are usually exactly zero block statements nested
directly in block statements.)
Re: DIP 1003: remove `body` as a keyword
On 23.11.2016 11:15, Sönke Ludwig wrote:
Function declarations don't necessarily have a body, but they might have
contracts. (This is currently not allowed for technical reasons, but it
should/will be.) But this is a rather minor point (usually you don't
want to have contracts without implementation in a context where
something starting with '{' is allowed).
Okay, but that doesn't sound like there is a technical ambiguity here,
then? Since there must be a full (block) statement after the in/out, it
should always resolve naturally.
Technically, there is an ambiguity (technically, ambiguity means that
there are multiple grammar derivations resulting in the same sentence).
Pragmatically, the greedy parse-the-body-if-possible-approach will work.
Re: DIP 1003: remove `body` as a keyword
On 22.11.2016 20:05, Meta wrote:
On Tuesday, 22 November 2016 at 15:11:04 UTC, Sönke Ludwig wrote:
Am 21.11.2016 um 22:19 schrieb Timon Gehr:
3 is ambiguous.
Can you give an example?
I'm curious as well. I considered that option 3 might be ambiguous but I
managed to convince myself that it wouldn't be. I'm guessing you're
referring to the fact that:
{
//function body
}
Is a delegate literal, which could conceivably conflict with Option 3's
syntax?
void fun(ref int n)
in { assert(n > 0); }
out { assert(n > 0); }
{ //Is this a syntax error or an immediately executed delegate literal?
n += 1;
}()
Function declarations don't necessarily have a body, but they might have
contracts. (This is currently not allowed for technical reasons, but it
should/will be.) But this is a rather minor point (usually you don't
want to have contracts without implementation in a context where
something starting with '{' is allowed).
The more important point is that there is no precedent where {...}{...}
are two components of the same entity, it looks ugly even with the
space-wasting convention where '{' is put on its own line. Not all
contracts are one-liners like in your example above (which looks almost
tolerable).
Re: DIP 1003: remove `body` as a keyword
On 19.11.2016 22:16, Dicebot wrote: DIP 1003 is merged to the queue and open for public informal feedback. PR: https://github.com/dlang/DIPs/pull/48 Initial merged document: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md If you want the change to be approved and have ideas how to improve it to better match on https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing published reviews - please submit new PR with editorial and ping original author. I'm opposed to both option 2 and option 3 on the basis that they are both plain ugly (also, breaking), 2 is verbose, 3 is ambiguous. (Doing nothing is much better than 2 or 3.) For option 1, the "on the basis that they will complicate the parser" argument is weak. Just lex 'body' as an identifier and expect to see that identifier in the parser. TOKbody occurs 4 times in DMD's parser, all of them are trivial to replace.
Re: DIP 1003: remove `body` as a keyword
On 21.11.2016 17:55, Piotrek wrote:
On Saturday, 19 November 2016 at 21:16:15 UTC, Dicebot wrote:
DIP 1003 is merged to the queue and open for public informal feedback.
PR: https://github.com/dlang/DIPs/pull/48
Initial merged document:
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md
If you want the change to be approved and have ideas how to improve it
to better match on
https://github.com/dlang/DIPs/blob/master/GUIDELINES.md and existing
published reviews - please submit new PR with editorial and ping
original author.
How about this alternative ("in" and "out" blocks inside function body):
void foo(int a)
{
in
{
assert (a > 0);
}
out
{
(ret) assert(ret > 0);
}
// body code
return a;
}
or for one-liners:
void foo(int a)
{
in assert (a > 0);
out (ret) assert(ret > 0);
// body code
return a;
}
BR,
Piotrek
Won't work. Contracts are part of the function signature. That's the point.
Re: DIP1000: Scoped Pointers
On 12.08.2016 21:39, Walter Bright wrote: On 8/12/2016 5:33 AM, Nordlöw wrote: If this is successfully implemented, what will D not be able to do, that Rust can/will? Have ownership semantics for pointers in more complex data structures. In D you'll have to do such with ref counted objects. On the other hand, D code can reference mutable globals in @safe code, whereas Rust cannot. Assuming, of course, I understood the Rust semantics correctly. AFAIU Rust has safe static TLS.
Re: DIP1000: Scoped Pointers
On 11.08.2016 09:48, Walter Bright wrote: On 8/10/2016 11:36 PM, rikki cattermole wrote: Perfect :) The nice thing about this scheme is it can do some things that Rust can't What are some of those things?
Re: Battle-plan for CTFE
On 08.06.2016 03:20, Stefan Koch wrote: On Friday, 3 June 2016 at 15:46:27 UTC, Stefan Koch wrote: On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote: I will post more details as soon as I dive deeper into the code. Okay I briefly evaluated the current IR dmd uses for backend communication, and it seems usable for the purposes of a CTFE-Interpreter/JIT. The Memory-Management issue is mostly orthogonal to CTFE. But nonetheless very important. I have to admit currently I am a bit stuck. @Timon Gehr cooperation would be highly appreciated. Sorry, I had missed this. I see you were able to make progress.
Re: Battle-plan for CTFE
On 13.05.2016 15:59, Don Clugston wrote: All that's needed is a very simple bytecode interpreter. Here is the one I have hacked together: https://github.com/tgehr/d-compiler/blob/master/interpret.d This file does both constant folding and byte-code interpretation for most of the language. I still need to implement exception handling. I'll let you know when it passes interpret3.d. :)
Re: C#7 features
On 06.05.2016 18:58, Kagamin wrote: On Friday, 6 May 2016 at 14:33:22 UTC, Andrei Alexandrescu wrote: Added a comment: https://www.reddit.com/r/programming/comments/4i3h77/some_new_c7_features/d2v5lu6 D has ref variables? Not for a long time though. D actually does not support ref local variables in most contexts (one can have ref locals declared by foreach). There is an explicit check ruling them out, but I'm pretty sure DMD supports them internally, they are useful for lowering.
Re: mir.combinatorics: reviewers and ideas are wanted
On 28.03.2016 09:24, 9il wrote: Hello All, Sebastian Wilzbach (aka @greenify) starts mir.combinatorics. Numeric functions: - `binomial` Ranges: - `permutations` RoR - `cartesianPower` RoR - `combinations` RoR - `combinationsRepeat` RoR RoR - Range of Ranges PR: https://github.com/DlangScience/mir/pull/29 Best regards, Ilya Regarding ideas: For each range, there should probably be a numeric function computing the length of that range. (e.g. here, binomial corresponds to combinations, there should be factorial corresponding to permutations etc.) This table might provide some inspiration: https://en.wikipedia.org/wiki/Twelvefold_way#Formulas I'd suggest completing the set of functions and ranges such that they cover all cases in this table. They can then be generalized. (E.g. instead of choosing a subset of a given size, one might want to choose multiple disjoint subsets of given sizes etc.) Also (both numeric functions and ranges, often more than one range per numeric function): - https://en.wikipedia.org/wiki/Multinomial_theorem - https://en.wikipedia.org/wiki/Stirling_numbers_of_the_first_kind - https://en.wikipedia.org/wiki/Derangement - https://en.wikipedia.org/wiki/Cyclic_permutation, in particular transpositions - https://en.wikipedia.org/wiki/Catalan_number - https://en.wikipedia.org/wiki/Fuss%E2%80%93Catalan_number - https://en.wikipedia.org/wiki/Narayana_number - https://en.wikipedia.org/wiki/Delannoy_number - https://en.wikipedia.org/wiki/Motzkin_number - https://en.wikipedia.org/wiki/Schr%C3%B6der_number - https://en.wikipedia.org/wiki/Schr%C3%B6der%E2%80%93Hipparchus_number - ...
Re: It's a class! It's a struct! It's ... SuperStruct!
On 10/18/2015 09:00 PM, rcorre wrote:
SuperStruct is a struct that acts like a class:
---
struct Square {
float size;
float area() { return size * size; }
}
struct Circle {
float r;
float area() { return r * r * PI; }
}
alias Shape = SuperStruct!(Square, Circle);
// look! polymorphism!
Shape sqr = Square(2);
Shape cir = Circle(4);
Shape[] shapes = [ sqr, cir ];
// call functions that are shared between the source types!
assert(shapes.map!(x => x.area).sum.approxEqual(2 * 2 + 4 * 4 * PI));
---
SuperStruct is basically a Variant that exposes the common members of
its source
types. You can check it out here:
https://github.com/rcorre/superstruct
I'm not quite sure if this is a good idea (or if it already exists in some
form that I haven't seen), but it was fun to work on. There's a lot more
info on
the README if you're curious. Let me know what you think!
"A call signature for a given member is 'compatible'
* if, for an instance of any one of `SubTypes`, that member can be
called with
* the provided set of arguments _and_ all such calls have a common
return type."
Probably you could/should return your SuperStruct instead of the/when
there is no common return type.
Re: This Week in D summarizes those long threads for you!
On 08/24/2015 06:09 PM, Adam D. Ruppe wrote:
the if(array) thread
But, this can be surprising if you aren't used to it, since an empty array is
not necessarily null:
[] is null passes, since the literal avoids allocating for nothing, but
[1][1..$] is null fails,
despite the array being empty, because the pointer is then set to the end of
the input array.
void main(){
assert([1][1..$] is null);
}
You forgot to take into account constant folding.
Re: Release D 2.068.0
On 08/10/2015 10:48 AM, Martin Nowak wrote: Glad to announce D 2.068.0. http://downloads.dlang.org/releases/2.x/2.068.0/ This release comes with many rangified phobos functions, 2 new GC profilers, a new AA implementation, and countless further improvements and fixes. See the changelog for more details. http://dlang.org/changelog.html#2.068.0 -Martin "3. Attributes for auto return function are now inferred." This is a bad idea. What if I want/need to specify the return type but still want attribute inference? What if I don't want attribute inference, but I want the return type to be inferred?
Re: [blog post] Dependent types in (half of) D
On 07/30/2015 06:13 PM, Timon Gehr wrote: ... The real difference is (roughly!) that the dependently typed interpreted program always fails if it would fail in any possible execution (This is ambiguous. What I mean is: If there is some execution in which it would fail.)
Re: [blog post] Dependent types in (half of) D
On 07/30/2015 05:45 PM, thedeemon wrote: On Thursday, 30 July 2015 at 13:25:31 UTC, Timon Gehr wrote: There is no dependent typing here. Failures occur during interpretation. Type theory doesn't say anything about interpretation and compilation. You need to consider the type system and the evaluation semantics. What are they for the "interpreted meta-programming part of D"? (I can find the semantics, but not a non-trivial type system.) Are you saying there cannot be an interpreted dependently typed language? (hint: Idris has a REPL) Obviously I'm not saying this, because it is nonsense. I'm saying that e.g. Python is not such a language, and neither is the language which is interpreted by the D compiler while generating an executable. Also, during compilation dependently typed languages evaluate a lot of code (do CTFE in D terms), and some fails occur during this process. So this is not the real difference. The real difference is (roughly!) that the dependently typed interpreted program always fails if it would fail in any possible execution (and usually in more cases than this one) (assuming type-safety). "Dynamically typed" interpreted languages on the other hand only fail if the particular execution exposed fails. This is what we are looking at here.
Re: [blog post] Dependent types in (half of) D
On 07/30/2015 09:31 AM, thedeemon wrote: I had this idea for a long time but a recent talk about a real dependently typed language helped me with nice examples to demonstrate on. The interpreted part of D is actually dependently typed! http://www.infognition.com/blog/2015/dependent_types_in_d.html There is no dependent typing here. Failures occur during interpretation.
Re: D needs...
On 05/11/2015 01:59 PM, Namespace wrote:
Inspired by ponce idioms list for D I've set up something similar.
There are some themes in D which come up regulary and are discussed to
the vomit. If something is agreed, it gets forgotten sometimes and the
theme disappears into oblivion (for a few months :P). To prevent this,
I've collected some hot-discussed themes, their history and their
current state. I hope this helps to avoid unnecessary discussions in the
future and finally cut off these issues (either with an official
decision "Nope, keep as it is" or with an implementation).
I've tried to stay as objective as possible, but if something seems to
be too subjective, please let me know, so I can fix it.
http://dgame.github.io/dneeds/
int[] test() {
return [1, 2, 3].s; // this is stack allocated
}
That's not a very compelling use case. :o)
The stack memory goes right out of scope after having been sliced.
Re: [hackathon] FreeTree is FreeList on autotune
On 05/07/2015 04:49 PM, Andrei Alexandrescu wrote: - The implementation of 'allocate' appears to be buggy: If no memory block of a suitable size is found, the entire free tree is released. (There is only one occurrence of parent.allocate in the code and it appears right after a call to 'clear'.) If the parent allocator does not define the 'deallocate' method, the allocator will always return 'null' instead. The idea here is that if no memory block is found in either the tree or the parent, the memory the tree is holding to is useless and fragments the parent unnecessarily. So the entire tree is thrown away, returning memory to the parent. Then allocation from the parent is tried again under the assumption that the parent might have coalesced freed memory. If the parent doesn't define deallocate, it can't accept back the memory kept by the tree. LMK if I'm missing something. The comment says: "Allocates $(D n) bytes of memory. First consults the free tree, and returns from it if a suitably sized block is found. Otherwise, the parent allocator is tried. If allocation from the parent succeeds, the allocated block is returned. Otherwise, the free tree tries an alternate strategy: If $(D ParentAllocator) defines $(D deallocate), $(D FreeTree) releases all of its contents and tries again." Unless I am the one missing something, the implementation does the following instead: "Allocates $(D n) bytes of memory. First consults the free tree, and returns from it if a suitably sized block is found. Otherwise, the free tree tries an alternate strategy: If $(D ParentAllocator) defines $(D deallocate), $(D FreeTree) releases all of its contents and tries again." (findAndRemove never allocates new memory from the parent, it just gets you memory already stored in the tree, if the right allocation size is present.) Thanks for the review! My pleasure!
Re: [hackathon] FreeTree is FreeList on autotune
On 05/02/2015 08:28 AM, Andrei Alexandrescu wrote:
I'm just done implementing a pretty cool allocator: FreeTree.
https://github.com/andralex/phobos/blob/allocator/std/experimental/allocator/free_tree.d
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_free_tree.html
It's similar to the classic free list allocator but instead of a
singly-linked list it uses a binary search tree for accommodating blocks
of arbitrary size. The binary search tree accommodates duplicates by
storing one extra pointer for each node, effectively embedding a
singly-linked list (a free list really) for each node.
So a FreeTree is have a bunch of freelists organized in a binary search
tree. The tree is not balanced; instead, it uses an LRU heuristic - each
freed block is inserted as (or close to) the root. Over the lifetime of
a free tree, free lists naturally appear and disappear as dictated by
the sizes most frequently allocated by the application.
Feedback is welcome!
Andrei
- Perhaps it would make sense to splay instead of rotating to root?
- I think the destructor only compiles if the parent allocator defines
the 'deallocate' method.
- The first static if should check for "deallocate", right?
static if (hasMember!(ParentAllocator, "deallocateAll"))
void deallocateAll()
{
static if (hasMember!(ParentAllocator, "deallocateAll"))
- The implementation of 'allocate' appears to be buggy: If no memory
block of a suitable size is found, the entire free tree is released.
(There is only one occurrence of parent.allocate in the code and it
appears right after a call to 'clear'.) If the parent allocator does not
define the 'deallocate' method, the allocator will always return 'null'
instead.
Re: DConf 2014 Day 1 Talk 4: Inside the Regular Expressions in D by Dmitry Olshansky
On 06/12/2014 02:31 PM, Dicebot wrote: Compiler can cache return value of function that get called from inside mixin statement (for a given argument set). As CTFE is implicitly pure (no global state at compile-time) later generated code can be simply re-used for same argument set. > Re-using it between compiler invocations is more tricky because it is only legal if generator function and all stuff they indirectly use have not changed too. Ignoring this requirement can result in nasty build issues that are only fixed by clean build. Too harmful in my opinion. Clearly, nirvana is continuous compilation, where the compiler performs explicit dependency management at the level of nodes in the syntax tree.
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/30/2014 02:37 PM, Steven Schveighoffer wrote:
in which case
static if(cond) {
immutable:
}
int x;
should not create x as immutable if cond is true. The current
behavior is not consistent with attribute either.
Ugh, that is really bad. It shouldn't do that. Is that intentional?
enum cond=true;
static if(cond){
immutable:
}
int x;
static assert(is(typeof(x)==int));
What is the problem?
Re: Scott Meyers' DConf 2014 keynote "The Last Thing D Needs"
On 05/29/2014 05:35 AM, Jonathan M Davis via Digitalmars-d-announce wrote: On Wed, 28 May 2014 16:07:08 -0700 Walter Bright via Digitalmars-d-announce wrote: Some of the inconsistencies you mentioned and Brian mentioned in his talk are actually the result of consistencies. I know this is a bit of a difficult thing to wrap one's head around, but having something be mathematically consistent and humanly consistent are often at severe odds. I don't disagree, but I also think that we need to be very careful when they're at odds, because it tends to result in buggy code when the rules are inconsistent from the human's perspective. In some cases, it's best to better educate the programmer, whereas in others, it's better to just make it consistent for the programmer - especially when you're dealing with a case where being consistent with one thing means being inconsistent with another. Overall, I think that we've done a decent job of it, but there are definitely places (e.g. static array declarations) where I think we botched it. - Jonathan M Davis I think this is not a point about "consistency", but about intuition. In any case, simply reversing the order for static array types using an ad-hoc rewrite rule would be a huge wart, even more severe than the other points you raised, and we definitely wouldn't be trading one kind of consistency for another. (In any case, the most elegant solution is to simply not have special syntax for language built-in types.)
Re: Interesting rant about Scala's issues
On 04/03/2014 04:45 AM, Walter Bright wrote: On 4/2/2014 6:55 PM, Andrei Alexandrescu wrote: A lot of them could apply to us as well. https://www.youtube.com/watch?v=TS1lpKBMkgg at about 44:00: "I begged them not to do them [AST macros]." :-) (This is a misquote.)
Re: Range-Based Graph Search in D (blog post)
On 01/09/2014 11:04 PM, Peter Alexander wrote: Trying to write a bit more about D on my blog now. To start, I've written about a proof-of-concept range-based API for graph search. http://poita.org/2014/01/09/range-based-graph-search-in-d.html I'd greatly appreciate any feedback on the design. I like the general direction. One issue with the API is that it does not deal with graphs with more than one edge between two given vertices very well. I think it'd need a separate edge abstraction. (Formally, a graph is just a pair of sets (V,E) with two functions from E to V giving you start and end vertex of an edge.) A graph search can have more properties than just the sequence of visited edges, so maybe it is not a range, but just provides a range. (And maybe also a range of events, usable instead of callbacks, maybe a DFS tree etc.) Allocation of memory for visited flags and the like should be controllable. Maybe the design should even allow using persistent data structures for storing visited flags, such that the search range can be used as a value type / forward range. As we don't yet have a graph library for D, it would be interesting to discuss APIs in general. -Peter Probably it would be worthwhile to explore a design that is similar to Phobos ranges at some level. I.e. support kinds of graphs with different capabilities. (Eg. your implicitGraph cannot enumerate all vertices or edges that are present in the Graph. The least capable graph kind reasonably supported might not even be able to quickly report all adjacent edges to a vertex. Some graphs may allow in-place mutation etc.) Then provide some explicit representations with high capabilities and helper functions to convert certain representations to (more) explicit representations. (similar to constructing eg. an array from a range.) Constructions on graphs would then return implicit representations.
Re: legacy code retreat's triva game : the D version
On 12/22/2013 09:06 AM, Marco Leise wrote: Am Sun, 22 Dec 2013 02:12:51 +0100 schrieb Timon Gehr : On 12/22/2013 02:09 AM, Timon Gehr wrote: The morale is that "uniform" random numbers doesn't imply that every value in the range will eventually be generated once! Yes it does. (The probability that some value is never generated is 0.) The actual morale is that random number generators do not generate true randomness, and poor random number generators may generate sequences that do not look remotely random. 'pseudo random number generators' would be a more accurate term. Can you elaborate a bit? The probability that a certain number does not occur in one round is (n-1)/n. ((n-1)/n)^k goes to 0 rather fast as k goes to infinity. In fact, the expected number of trials until all numbers are covered is ~ n log n, and the probability that the process runs significantly longer is very small. See also: http://en.wikipedia.org/wiki/Coupon_collector%27s_problem How do you know that the Java LCG can produce every 32-bit integer once? Typically constants are chosen such that this holds, but your code would require something stronger to fail, namely, that a certain congruence class does not occur. Typically pseudo random number generators are chosen such that the generated sequences look close to true randomness. If such a simple process can be used to reliably distinguish true randomness and the pseudo random number generator, then the pseudo random number generator is not very good. If that's true then the problem with the Java code was something different and I was just biased, because I was already expecting the code to fail before the fact. Maybe. There is a vast number of ways that this could have failed. (Expectations can do strange things to your perception.) Indeed. :)
Re: legacy code retreat's triva game : the D version
On 12/22/2013 02:09 AM, Timon Gehr wrote: The morale is that "uniform" random numbers doesn't imply that every value in the range will eventually be generated once! Yes it does. (The probability that some value is never generated is 0.) The actual morale is that random number generators do not generate true randomness, and poor random number generators may generate sequences that do not look remotely random. 'pseudo random number generators' would be a more accurate term.
Re: legacy code retreat's triva game : the D version
On 12/22/2013 01:07 AM, Marco Leise wrote: ... It didn't cause issues for any of the other students, but on this particular computer the random seed that the Random ctor chose caused a degenerate case where it never hit any of the 3 remaining indexes of the list. The morale is that "uniform" random numbers doesn't imply that every value in the range will eventually be generated once! Yes it does. (The probability that some value is never generated is 0.) The actual morale is that random number generators do not generate true randomness, and poor random number generators may generate sequences that do not look remotely random.
Re: I'm porting some go code to D
On 08/26/2013 12:55 AM, Rory McGuire wrote:
shared chan!Fiber scheduler; // channel contains Fibers waiting for
their time slice
static this () {
if (scheduler is null) {
You want 'shared static this' instead to avoid a race condition.
Re: My first email to Walter, ever
On 07/07/2013 02:27 PM, Peter Alexander wrote: ... We're almost there with CTFE, but CTFE can only run functions that could run at runtime. In a crazy world where types were first class objects, stuff like this would be feasible. Or perhaps we just need a compile-time metalanguage that allows things like this to be run with CTFE? Almost there indeed. http://d.puremagic.com/issues/show_bug.cgi?id=9945
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/16/2013 12:07 AM, bearophile wrote: Timon Gehr: Eiffel can call arbitrary methods in contracts. This is surprising. Maybe the "Modern Eiffel" is more strict. It's design isn't finished, but IIRC it enforces purity, contracts can be arbitrarily complex, and manual proofs are required. I disagree. The only problem is the verboseness of the contract system. If your contracts contain arbitrary D code, I don't think a static analyser will be able to use them. Why not? The static analyser obviously needs to analyse arbitrary D code anyway, unless it only analyses contracts, which is not useful. So it will give you a compilation error, or it will give a warning and then keep the contract as run-time test. It's unreasonable to expect that the static analyser will automatically prove all correct programs correct without manually provided evidence. This holds true independently of the format the contracts are specified in. In both cases this makes the static analysis much less useful. Than what? So you end using a subsed of the D syntax and D semantics. But then compilation becomes a try-and-guess, and different static analysers will digest different amounts of D syntax and semantics, Obviously. But not closely related to the way contracts are specified. causing those contracts to be not portable across static analysers. If those analysers all follow the same specification, they will be portable in any case. Both Ada Reference? and Liquid Haskell avoids all this. ... It does not make any sense to claim that Liquid Haskell avoids all this. It is not a programming language but a static verifier, AFAIK based on predicate abstraction.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/15/2013 05:14 PM, Jacob Carlborg wrote: On 2013-06-12 14:50, Andrei Alexandrescu wrote: Reddit: http://www.reddit.com/r/programming/comments/1g6x9g/dconf_2013_code_analysis_for_d_with_analyzed/ Hackernews: https://news.ycombinator.com/item?id=5867764 Twitter: https://twitter.com/D_Programming/status/344798127775182849 Facebook: https://www.facebook.com/dlang.org/posts/655927124420972 Youtube: http://youtube.com/watch?v=ph_uU7_QGY0 As I understand it, the static analyzer doesn't handle D completely. How does it behave/what happens if it encounters something it cannot handle? It bails out.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/14/2013 11:03 AM, bearophile wrote: Don: I don't think contracts can be much use to a static analyzer if they can contain arbitrary code. The other contract systems I know of (Eiffel, Ada, C#, Sing#), plus few other systems that use the type system for similar reasons (Liquid Haskell, etc), use a very restricted expression language to state contracts. D is the only that uses free form D code. Eiffel can call arbitrary methods in contracts. I presented this problem to Walter lot of time ago in a post. He answered me that analysing a loop is not harder than analysing the all/any/exists used in those systems. I was never convinced by that. I still think there's one D design problem here. ... I disagree. The only problem is the verboseness of the contract system.
Re: DConf 2013 Day 3 Talk 2: Code Analysis for D with AnalyzeD by Stefan Rohe
On 06/12/2013 11:23 PM, Walter Bright wrote: On 6/12/2013 2:21 PM, bearophile wrote: Jonathan M Davis: What I find most interesting about checked exceptions is the fact that almost everyone thinks that they're a fantastic idea when they first encounter them and yet they're actually a bad idea. It's actually a good example of how a feature sometimes needs to be thoroughly field-tested before it becomes clear how good or bad it is. Maybe checked exceptions are bad only for the type system of Java. Maybe for a language that has global type inferencing on the exceptions such feature becomes better. C++98 had checked exceptions (exception specifications), too. Another failure of the idea, it failed so badly hardly anyone but language lawyers ever knew it had it. Weren't those checked at runtime?
Re: DConf 2013 Day 3 Talk 1: Metaprogramming in the Real World by Don Clugston
On 06/11/2013 02:33 PM, Andrei Alexandrescu wrote:
Reddit:
http://www.reddit.com/r/programming/comments/1g47df/dconf_2013_metaprogramming_in_the_real_world_by/
Hackernews: https://news.ycombinator.com/item?id=5861237
Twitter: https://twitter.com/D_Programming/status/344431490257526785
Facebook: https://www.facebook.com/dlang.org/posts/655271701153181
Youtube: http://youtube.com/watch?v=pmwKRYrfEyY
Please drive discussions on the social channels, they help D a lot.
Andrei
Nice talk.
I'd like to relativize the statement about JITing CTFE though.
This is feasible, even given issues such as global local variables. [1]
I have a byte code interpreter for most of CTFE. I have been
unexpectedly busy lately, but hope to get my D frontend out the door in
a more or less respectable state soon.
[1] Given that I understand the term correctly. Is this what you meant?:
int foo(int x){
immutable globalLocal1 = 1;
int globalLocal2 = x;
int foo(bool first){return first?globalLocal1:globalLocal2;}
enum y = foo(true);
return foo(false)+y;
}
static assert(foo(2)==3);
Re: dmd 2.063 released with 260 bugfixes and enhancements
On 05/30/2013 08:00 PM, Mafi wrote: What a great release! Great work! I really like the new langugage changes. One change caught my attention: #10 "The Template This Parameter now changes the member function qualifier". Does this mean that const/immutable ranges can implement a useful opSlice? ... Yes, const/immutable containers are now able to implement a useful opSlice without manual duplication.
Re: Shameless autopromotion : type safe tagged union in D
On 05/10/2013 02:32 PM, deadalnix wrote:
http://www.deadalnix.me/2013/05/10/type-safe-tagged-union-in-d-programming-language/
A trick that I used to use more and more, so I ended up creating a
generic solution and wrote an article about it.
I'd have implemented your TaggedUnion struct as follows. (I believe this
is equivalent to your implementation.)
struct TaggedUnion(T...){
private{
union{ T members; }
int tag;
static int indexOf(S)(){
foreach(i,t;T) static if(is(S==t)) return i;
return -1;
}
}
this(T)(T t) if(~indexOf!T){
members[indexOf!T]=t;
tag=indexOf!T;
}
auto ref apply(alias fun)(){
switch(tag){
foreach(i,_;T) case i: return fun(members[i]);
default: assert(0);
}
}
}
But note that this is as unsafe as the original implementation. You will
at least have to provide a postblit constructor and a destructor in
order to keep the promise of safety.
Re: Functional Programming with D
On 04/13/2013 05:25 PM, qznc wrote:
Sat, 13 Apr 2013 15:03:51 +0200: Vladimir Panteleev wrote
On Saturday, 13 April 2013 at 12:29:29 UTC, qznc wrote:
While there is no syntactic sugar,
What about lambdas?
http://dlang.org/expression.html#Lambda
Oh. I forgot about those. Thanks!
The syntactic sugar seems to be quite diverse, since most of the
FunctionLiteral is optional. As far as I understand the docs, all the
following forms are valid?
auto square1 = function int (int x) { return x*x; };
yes.
auto square2 = function (int x) { return x*x; };
yes.
auto square3 = (int x) { return x*x; };
yes.
auto square4 = int (int x) { return x*x; };
no.
auto square5 = (int x) => x*x;
yes.
auto square6 = x => x*x;
no. (valid grammar, but you need some type annotation.)
But there are more, like function(int x)=>x*x.
Re: Higgs, a JavaScript JIT done in D
On 02/03/2013 11:14 PM, Peter Alexander wrote:
On Sunday, 3 February 2013 at 22:00:05 UTC, bearophile wrote:
Nick Sabalausky:
Why is it silly? (Genuine question)
"Silly" wasn't the right word, sorry.
But generally if a language offers you a clean feature (D contract
programming is designed clean enough) it's better to use it, when you
clearly need it.
I don't use D contracts, even though I use asserts.
I find that adding contracts bloats my code quite a lot, making it less
readable.
real log(real x)
in
{
assert(x > 0);
}
body
{
return ...;
}
If the code is written consistently in this vertically-bloated style, it
is 'less readable' anyway. Contracts will not make a huge difference. :o)
v.s.
real log(real x)
{
assert(x > 0);
return ...;
}
real log(real x) in{ assert(x > 0); }body{
return ...;
}
real log(real x) in{
assert(x > 0);
}body{
return ...;
}
As far as I'm aware there is no difference except when inheritance is
involved, so it's an easy choice for me.
The difference is that the first version of log given above may be
correct whereas the second is certainly buggy (pass in 0 and it fails).
As correctness is not necessarily modular, the entire code base as a
unit may still work correctly if it contains either version. That's why
your approach is practicable in the absence of a tool/review process
that checks assertions in a modular way.
