Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On 06/11/2016 11:49 PM, Sheldon Shen wrote: > On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote: >> I recommend against building the pdf versions frequently because that >> takes a lot of time. > Actually we have a problem in pdf versions. It seems that any chinese > character is replaced by '?', which may be an issure of the prince :( It is most definitely a font issue: The embedded fonts probably don't have Chinese characters. You need to pick new fonts. >> Please contact me at acehr...@yahoo.com to start the process and to >> see how it goes. Would you be open to having one or more technical >> editors review the chapters as you post a pull request? That would >> improve the quality. > Thanks to your suggestions, we have already started the project :) > It is located at https://github.com/DlangRen/Programming-in-D That's wonderful! :) > We are wondering what editor you used to write the book in Ddoc, because > apparently MonoD can't handle it porperly. I don't know any editor other than Emacs. :o) Although it's extremely capable, I did not need any help for ddoc. I typed everything by hand. > > meatatt > Ali
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 15:04:52 UTC, Ali Çehreli wrote: On 06/10/2016 07:41 AM, Seb wrote: >> [...] want to > [...] translating it > [...] in. > [...] [...] IMHO maybe D编程 or D语言编程 is better than 编程在D, because 编程在D looks odd in Chinese. Programming in Scala translated into Scala编程 in Chinese; Programming In Lua translated into Lua程序设计; Programming in C(3rd Edition) translated into C语言编程 and 4th Edition translated into C语言程序设计; If this Chinese book is not published in Chinese, the original name "Programming in D" or "Programming in D 中文版" (Programming in D Chinese version) is also OK.
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Monday, 13 June 2016 at 02:34:13 UTC, Dsby wrote: On Friday, 10 June 2016 at 20:24:47 UTC, Meta wrote: On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote: Hi,everyone: The 'Programming In D' is a good book for new D coders,we want to start it in Chinese, do you have any good suggestions? Thank you. 太好了！很不幸，我的中文知识不足够的，所以不可能帮你们。加油，我很兴奋的！ 这句中文说的很不错的。 你太客气了~
Re: We want to start the 'Programming In D 'in Chinese, do you have any good suggestions?
On Friday, 10 June 2016 at 20:24:47 UTC, Meta wrote: On Friday, 10 June 2016 at 14:26:31 UTC, FrankLike wrote: Hi,everyone: The 'Programming In D' is a good book for new D coders,we want to start it in Chinese, do you have any good suggestions? Thank you. 太好了！很不幸，我的中文知识不足够的，所以不可能帮你们。加油，我很兴奋的！ 这句中文说的很不错的。
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 12:42:23 UTC, Adam D. Ruppe wrote: The standard has moved on, the bar on performance has raised, and dmdscript hasn't even kept up with changes in D. Not too worried about the performance, but EcmaScript 6 has increased the feature set so much that the spec is over twice as large as for EcmaScript 5... And Chrome 52 is apparently shipping with both ES6 and some ES7, so it will be hard to keep up.
Re: Monads in D
On 12.06.2016 20:28, Max Samukha wrote: On Sunday, 12 June 2016 at 16:46:13 UTC, Ola Fosheim Grøstad wrote: Input world, output modified world... Geez, why doesn't tutorials on Monads say that before they try to explain it with code? Because IO is just one of many applications of the monad concept? Most of the tutorials are not actually very good.
Re: The Problem With DIPs
On 6/10/2016 9:38 AM, Ola Fosheim Grøstad wrote: On Friday, 10 June 2016 at 15:37:31 UTC, Steven Schveighoffer wrote: DIP 20 by Alex Rønne Petersen in 2012 Alex is a member of Phobos, druntime, dlang.org, and tools team. Aww, apologies to Alex :-) Modifying the compiler might be more productive than writing a DIP, then. Consider: would you ever have noticed a n.g. posting written by Alex in 2012?
Re: The Problem With DIPs
On 6/12/2016 11:50 AM, Dicebot wrote: Your are very correct about importance of link stability though. What comes to my mind immediately is to store all DIPs in same folder but keep Approved/Implementec/etc as folders containing symlinks to the merged one (git stores symlinks just fine). I like Bugzilla's method of tagging issues, which allows arbitrary crosscuts to be made.
Re: The Problem With DIPs
On 06/12/2016 09:58 PM, Vladimir Panteleev wrote: > On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote: >> Your are very correct about importance of link stability though. What >> comes to my mind immediately is to store all DIPs in same folder but >> keep Approved/Implementec/etc as folders containing symlinks to the >> merged one (git stores symlinks just fine). > > This might not be the case on Windows. > > Does GitHub present symlinks in a nice way (i.e. as a redirect)? AFAIK in Windows those are visible as text files containing linked path. Github doesn't seem to be very helpful either : https://github.com/Dicebot/DIPs/blob/master/Drafts/DIP20.md :(
Re: The Problem With DIPs
On Sunday, 12 June 2016 at 18:50:06 UTC, Dicebot wrote: Your are very correct about importance of link stability though. What comes to my mind immediately is to store all DIPs in same folder but keep Approved/Implementec/etc as folders containing symlinks to the merged one (git stores symlinks just fine). This might not be the case on Windows. Does GitHub present symlinks in a nice way (i.e. as a redirect)?
Re: The Problem With DIPs
On 06/12/2016 08:19 PM, Guillaume Boucher wrote: > On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote: >> On 06/09/2016 01:12 AM, Walter Bright wrote: >>> On 6/8/2016 1:47 PM, Dicebot wrote: I will finish description for proposed process this weekend and send it to dmd-internal mail list. >>> >>> Cool! >> >> http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9...@dicebot.lv >> > > What are the reasons for putting the DIPs into several directories > (Drafts, Approved, Implemented and Discarded)? Rust also did that at > first, but they merged them later into one folder (see > https://github.com/rust-lang/rfcs/issues/360). If you keep the > structure as is, what is the preferred way to link to a certain DIP? Rationale is to allow quickly navigate through existing DIPs (in absence of actual database to query), filtering categories is probably most common navigation task. Your are very correct about importance of link stability though. What comes to my mind immediately is to store all DIPs in same folder but keep Approved/Implementec/etc as folders containing symlinks to the merged one (git stores symlinks just fine).
Re: Monads in D
On Sunday, 12 June 2016 at 16:46:13 UTC, Ola Fosheim Grøstad wrote: Input world, output modified world... Geez, why doesn't tutorials on Monads say that before they try to explain it with code? Because IO is just one of many applications of the monad concept?
Re: The Problem With DIPs
On Sunday, 12 June 2016 at 12:16:11 UTC, Dicebot wrote: On 06/09/2016 01:12 AM, Walter Bright wrote: On 6/8/2016 1:47 PM, Dicebot wrote: I will finish description for proposed process this weekend and send it to dmd-internal mail list. Cool! http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9...@dicebot.lv What are the reasons for putting the DIPs into several directories (Drafts, Approved, Implemented and Discarded)? Rust also did that at first, but they merged them later into one folder (see https://github.com/rust-lang/rfcs/issues/360). If you keep the structure as is, what is the preferred way to link to a certain DIP?
Re: Monads in D
On Sunday, 12 June 2016 at 15:33:31 UTC, Timon Gehr wrote: I don't see the point of this criticism. Different language makes sense to different people. I think he had a point, but his explanation was harder to follow than this one: http://research.microsoft.com/en-us/um/people/simonpj/papers/marktoberdorf/mark.pdf Input world, output modified world... Geez, why doesn't tutorials on Monads say that before they try to explain it with code?
Re: Monads in D
On 11.06.2016 20:27, deadalnix wrote: Honestly, the whole bind/return is just a giant NIH. >>> and >>= are its symptoms. There is a reason why nobody understands jack shit about monad even after 10s of tutorial when they aren't even hard in any way: because haskell and alike have made all that is in their power to obfuscate what is a monad. I could go on, but this guy already did it way better that I can: https://www.infoq.com/presentations/functional-pros-cons The part about monad starts 25mins in. I don't see the point of this criticism. Different language makes sense to different people.
.stringof
On 12.06.2016 15:52, Timon Gehr wrote: You may very well be right that it would be more consistent to return the name of the alias, but I think what .stringof returns is an independent concern. (Last time I checked, it was completely unspecified anyway btw.) What do you think about the following? enum e=3; static assert(e.stringof=="3");
Re: Passing private functions to template algorithms
On 12.06.2016 15:52, Timon Gehr wrote: semantics are useful is useful
Re: Passing private functions to template algorithms
On 12.06.2016 13:05, Dicebot wrote: On 06/12/2016 01:55 PM, Timon Gehr wrote: On 12.06.2016 10:28, Dicebot wrote: On 06/07/2016 09:59 PM, Timon Gehr wrote: I think it is obvious that this should work. Visibility checks need to happen during identifier lookup. This lookup is happening in the module where isFileNothrow is visible. My understanding is that right now template alias argument means transparent symbol lookup. It acts as if doesn't access alias symbol in template but aliased one directly. ... The lookup accesses the alias and is immediately rewritten to refer to the aliased symbol. Visibility checks should be applied during the lookup, but not after the rewrite. Yes, that is natural solution but it makes alias itself first-class symbol which leads to my example snippet question. ... In my mind it already is a first-class symbol (it can even be part of an overload set), but after you look it up, it is immediately rewritten to another symbol. https://github.com/tgehr/d-compiler/blob/master/semantic.d#L4670 Does DMD special-case it during lookup instead? I agree such semantics are sub-optimal but changing that can break quite some existing idioms. Consider this snippet for example: enum name ( alias sym ) = sym.stringof; Right now it evaluates to name of passed symbol. If we change lookup semantics to be non-transparent, it must always return `sym` for consistency. I completely disagree that this would need to happen. E.g. fullyQualifiedName should work with private symbols just as well as with public ones. Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding Private or public is irrelevant here, it seems you have misunderstood my concern. Probably I indeed misunderstood your concern, but what I disagree with is the notion that breaking code not directly checking for visibility is somehow a prerequisite for having the correct visibility checks in place. You may very well be right that it would be more consistent to return the name of the alias, but I think what .stringof returns is an independent concern. (Last time I checked, it was completely unspecified anyway btw.) The essential question is "what the alias is?", not how it is accessed. There must be no special cases for aliases regarding private/public symbol access, There are no special cases in what I propose. The alias rewrite has nothing to do with lookup: https://github.com/tgehr/d-compiler/blob/master/scope_.d#L185 I guess this is precisely your proposal too? it is matter of defining actual alias semantics so that generic access rules start being useful. I agree. (Or maybe rather, it is a matter of defining both such that the resulting semantics are useful, I don't know precisely where DMD goes astray here.)
Re: Passing private functions to template algorithms
The language does not prevent taking the address of a private symbol and escaping it. The alias case isn't (ie shouldn't be) different. artur
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 12:05:49 UTC, Ola Fosheim Grøstad wrote: Conformance would be more important so that you can use libraries and compilers that compile to EcmaScript. That's kinda the problem with dmdscript: it is an excellent and conformant implementation of Javascript that performed better than its competitors... many years ago. The standard has moved on, the bar on performance has raised, and dmdscript hasn't even kept up with changes in D. It's still a very good implementation of ECMAScript 3, and with a bit of D stuff, interfacing with it is reasonably easy, but tbh it just isn't something I'd use anymore... my script.d is easier to build and interface for quick toys, and one of the newer JS engines is better at Javascript itself.
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 12:30:46 UTC, ketmar wrote: js is fubared from the start. there is no need to follow the broken path. Whatever, the core of JavaScript is close to Self: https://en.wikipedia.org/wiki/Self_(programming_language) JavaScript was just messy in the details. ES6 is fixing a lot of that.
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 12:25:00 UTC, Ola Fosheim Grøstad wrote: Well, ES6 is actually reasonably ok. js is fubared from the start. there is no need to follow the broken path.
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 12:13:45 UTC, Chris wrote: On Sunday, 12 June 2016 at 11:58:08 UTC, ketmar wrote: On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote: I haven't had a chance to look at the source code in detail yet. How hard would it be to integrate JIT and D (and C) interop? not hard. there is extension example (extending engine with D). also, the engine compiles scripts to IR code, which can be JITed as is, or used as a base for some other code representation. the worst thing (for me) is that it is javascript. Yeah, same here! It'd be best to write a proper scripting language based on DMDScript. Well, ES6 is actually reasonably ok. It has both generators and WeakSet (set of objects that is pruned if the object is collected and many many other improvements: http://es6-features.org/
Re: D grammar
On Sunday, 12 June 2016 at 12:14:33 UTC, WebFreak001 wrote: There is a full grammar definition on the D Spec pdf file: https://dlang.org/dlangspec.pdf it is invalid. anyone who will try to write a parser following this grammar only will hit a wall.
Re: The Problem With DIPs
On 06/09/2016 01:12 AM, Walter Bright wrote: > On 6/8/2016 1:47 PM, Dicebot wrote: >> I will finish description for proposed process this weekend and send >> it to >> dmd-internal mail list. > > Cool! http://forum.dlang.org/thread/d5996d6d-1f8e-2fa7-31a7-177c121a9...@dicebot.lv
Re: D grammar
On Sunday, 12 June 2016 at 06:45:58 UTC, Russel Winder wrote: I should know this, but… Is there an official D grammar (EBNF or otherwise) or is the language defined by the DMD parser? I am looking to continue Kingsley's DLanguage IntelliJ IDEA plugin and for that it is necessary to have a grammar specification. Kingsley has been working on one, but there may be differences between it and 2.071. Given the compilers and all the supporting tools either there is one language specification they all work with or there is a lot of fragmented viewpoints as to what D actually is. I am hoping the latter is not the case. There is a full grammar definition on the D Spec pdf file: https://dlang.org/dlangspec.pdf I also converted the whole grammar (excluding Allocator & Deallocator Arguments) with some nicer names to a txt file: https://i.webfreak.org/c5aCpv
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 11:58:08 UTC, ketmar wrote: On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote: I haven't had a chance to look at the source code in detail yet. How hard would it be to integrate JIT and D (and C) interop? not hard. there is extension example (extending engine with D). also, the engine compiles scripts to IR code, which can be JITed as is, or used as a base for some other code representation. the worst thing (for me) is that it is javascript. Yeah, same here! It'd be best to write a proper scripting language based on DMDScript.
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote: I haven't had a chance to look at the source code in detail yet. How hard would it be to integrate JIT and D (and C) interop? Theoretically something like the Derelict-D libs allow for interop with Python and Lua too. I think we could create something really nice and useful here. I don't think JIT is needed to be useful. Conformance would be more important so that you can use libraries and compilers that compile to EcmaScript. But conformance to EcmasScript 6 is a big big big big job. http://www.ecma-international.org/ecma-262/6.0/
Re: Interest in Paris area D meetups?
On Thursday, 9 June 2016 at 17:35:32 UTC, Guillaume Chatelet wrote: On Thursday, 9 June 2016 at 16:27:41 UTC, Claude wrote: On Thursday, 9 June 2016 at 09:11:05 UTC, Guillaume Chatelet wrote: Sounds good to me. How about next Wednesday (15th) at "Bière et Malt" (4 rue Poissonnière in the 2nd district) at say 19:00? Ok, great! FYI my email address: chatelet.guillaume at gmail Fine, did you receive my email?
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 11:23:56 UTC, Chris wrote: I haven't had a chance to look at the source code in detail yet. How hard would it be to integrate JIT and D (and C) interop? not hard. there is extension example (extending engine with D). also, the engine compiles scripts to IR code, which can be JITed as is, or used as a base for some other code representation. the worst thing (for me) is that it is javascript.
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 10:51:16 UTC, Walter Bright wrote: On 6/12/2016 3:17 AM, Chris wrote: On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote: On 6/10/2016 3:55 AM, Chris wrote: > Cool. I'd love to see `DScript` one day - and replace JS > once and for all ... > well ... just day dreaming ... Dreams are reality: https://github.com/DigitalMars/DMDScript I just tried to compile it on Linux with dmd v2.071.0 in 64bit mode. The compiler emits loads of deprecation warnings concerning module import, Yeah, the import lookup was recently changed. and it seems to be geared towards 32bit: That's right. It should be fixed. Nevertheless, these are minor issues. If you try to create a new script compiler, you're in for a heluva lot more work than fixing some bit rot. Sure, but then we should turn it into a first class citizen and update it with each version of dmd and prevent bit rot. I haven't had a chance to look at the source code in detail yet. How hard would it be to integrate JIT and D (and C) interop? Theoretically something like the Derelict-D libs allow for interop with Python and Lua too. I think we could create something really nice and useful here. By the way, provided we go ahead with this, wouldn't the name DScript be catchier than DMSScript? Although I don't want to bikeshed about the name now.
Re: Version identifier for PS4
On Sunday, 12 June 2016 at 06:29:08 UTC, Walter Bright wrote: On 6/9/2016 5:30 AM, Johan Engelen wrote: Hi all, PR 5850 is proposing to add a predefined (reserved) version identifier for the PS4 OS: "PS4" [1]. Thanks for your comment (preferably with an alternative suggestion in case you don't like "PS4"). Thanks, Johan [1] https://github.com/dlang/dmd/pull/5850 As others suggested, me kinda prefer "PlayStation4" as there's little doubt what that refers to. As per popular request I have changed the commit to reserve "PlayStation" and "PlayStation4". First of all, if what Johan says is right about "PlayStation" reserving all additions to the keyword as well (PlayStation4, PlayStation5, PlaystationOver9000) then my reasoning behind reserving "PlayStation4" is for claritys sake and for the documentation. If it isn't right, "PlayStation" is a good keyword because there might be a possibility to reuse code between the PS4 and a theoretical future PS5.
Re: Passing private functions to template algorithms
On 06/12/2016 01:55 PM, Timon Gehr wrote: > On 12.06.2016 10:28, Dicebot wrote: >> On 06/07/2016 09:59 PM, Timon Gehr wrote: >>> I think it is obvious that this should work. Visibility checks need to >>> happen during identifier lookup. This lookup is happening in the module >>> where isFileNothrow is visible. >> >> My understanding is that right now template alias argument means >> transparent symbol lookup. It acts as if doesn't access alias symbol in >> template but aliased one directly. >> ... > > The lookup accesses the alias and is immediately rewritten to refer to > the aliased symbol. Visibility checks should be applied during the > lookup, but not after the rewrite. Yes, that is natural solution but it makes alias itself first-class symbol which leads to my example snippet question. >> I agree such semantics are sub-optimal but changing that can break quite >> some existing idioms. Consider this snippet for example: >> >> enum name ( alias sym ) = sym.stringof; >> >> Right now it evaluates to name of passed symbol. If we change lookup >> semantics to be non-transparent, it must always return `sym` for >> consistency. >> > > I completely disagree that this would need to happen. E.g. > fullyQualifiedName should work with private symbols just as well as with > public ones. > > Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding Private or public is irrelevant here, it seems you have misunderstood my concern. The essential question is "what the alias is?", not how it is accessed. There must be no special cases for aliases regarding private/public symbol access, it is matter of defining actual alias semantics so that generic access rules start being useful.
Re: Passing private functions to template algorithms
On 12.06.2016 10:28, Dicebot wrote: On 06/07/2016 09:59 PM, Timon Gehr wrote: I think it is obvious that this should work. Visibility checks need to happen during identifier lookup. This lookup is happening in the module where isFileNothrow is visible. My understanding is that right now template alias argument means transparent symbol lookup. It acts as if doesn't access alias symbol in template but aliased one directly. ... The lookup accesses the alias and is immediately rewritten to refer to the aliased symbol. Visibility checks should be applied during the lookup, but not after the rewrite. I agree such semantics are sub-optimal but changing that can break quite some existing idioms. Consider this snippet for example: enum name ( alias sym ) = sym.stringof; Right now it evaluates to name of passed symbol. If we change lookup semantics to be non-transparent, it must always return `sym` for consistency. I completely disagree that this would need to happen. E.g. fullyQualifiedName should work with private symbols just as well as with public ones. Maybe this is helpful: https://en.wikipedia.org/wiki/Information_hiding
Re: I'd love to see DScript one day ...
On 6/12/2016 3:17 AM, Chris wrote: On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote: On 6/10/2016 3:55 AM, Chris wrote: > Cool. I'd love to see `DScript` one day - and replace JS once and for all ... > well ... just day dreaming ... Dreams are reality: https://github.com/DigitalMars/DMDScript I just tried to compile it on Linux with dmd v2.071.0 in 64bit mode. The compiler emits loads of deprecation warnings concerning module import, Yeah, the import lookup was recently changed. and it seems to be geared towards 32bit: That's right. It should be fixed. Nevertheless, these are minor issues. If you try to create a new script compiler, you're in for a heluva lot more work than fixing some bit rot.
Re: I'd love to see DScript one day ...
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote:
On 6/10/2016 3:55 AM, Chris wrote:
> Cool. I'd love to see `DScript` one day - and replace JS once
and for all ...
> well ... just day dreaming ...
Dreams are reality:
https://github.com/DigitalMars/DMDScript
I just tried to compile it on Linux with dmd v2.071.0 in 64bit
mode. The compiler emits loads of deprecation warnings concerning
module import, and it seems to be geared towards 32bit:
[...]
engine/source/dmdscript/dstring.d(953,16): Deprecation: module
std.string is not accessible here, perhaps add 'static import
std.string;'
engine/source/dmdscript/expression.d(216,9): Warning: statement
is not reachable
engine/source/dmdscript/expression.d(306,28): Deprecation: module
std.ascii is not accessible here, perhaps add 'static import
std.ascii;'
engine/source/dmdscript/expression.d(318,9): Error: static assert
(8LU == 4LU) is false
dmd failed with exit code 1.
The error message refers to:
`override void toIR(IRstate *irs, uint ret)
{
static assert((Identifier*).sizeof == uint.sizeof); //
<==
if(ret)
{
uint u = cast(uint)Identifier.build(string);
irs.gen2(loc, IRstring, ret, u);
}
}
`
Re: I'd love to see DScript one day ...
On Sunday, 12 June 2016 at 08:32:10 UTC, Dicebot wrote: On 06/11/2016 01:01 AM, Walter Bright wrote: On 6/10/2016 3:55 AM, Chris wrote: Cool. I'd love to see `DScript` one day - and replace JS once and for all ... well ... just day dreaming ... Dreams are reality: https://github.com/DigitalMars/DMDScript On a related topic - has anyone looked into what needs to be done to support D + WebAssembly combo? WebAssembly is currently close to asm.js. In fact I believe WebAssembly is distilled from the asm.js backend. Single threaded, no garbage collection support.
Re: I'd love to see DScript one day ...
On Friday, 10 June 2016 at 22:01:53 UTC, Walter Bright wrote: On 6/10/2016 3:55 AM, Chris wrote: > Cool. I'd love to see `DScript` one day - and replace JS once and for all ... > well ... just day dreaming ... My crazy dream (or cool idea :): to use the DMD interpreter as the script engine!
Re: Transient ranges
On Friday, 3 June 2016 at 12:03:26 UTC, Steven Schveighoffer wrote: It only strengthens my opinion that Phobos is not a standard library I want. Really, many of those issue would have been solved if basic input range was defined as `empty` + `ElementType popFront()` instead. This doesn't solve the problem. empty may not be knowable until you try to fetch the next element (for instance, i/o). A better interface would be bool getNext(ref ElementType), or Nullable!ElementType getNext(), or tuple!(bool, "eof", ElementType, "value") getNext(). Not necessarily, one can simply define that range processing requires checking `empty` both before and after getting next element (and that returned value is undefined if empty == true). Though I do agree that returning `Optional!ElementType` would be even better. Yes, I can see good reason why you would want this. Hm... a set of adapters which reduce a range to its lesser API would be useful here: array.asInput.map But an expectation for map should be that you want it to be exactly the same as the original, but with a transformation applied to each fetch of an element. I think it needs to provide random access if random access is provided to it. That is matter of design philosophy. For me such basic library primitives warrant C++ attitude of "don't pay for what you don't ask for" - and everything else, including actual feature completeness, is of negligible importance compared to that. If keeping random access for map requires either caching or multiple evaluations of predicate, I want it to be banned by default and enabled explicitly (not sure what could be good API for that though). Phobos indeed doesn't seem to make such priorities right now and that is one of reasons I am growing increasingly unhappy with it. Then it's not a bug? It's going to work just fine how you specified it. I just don't consider it a valid "range" for general purposes. You can do this if you want caching: only(0).map!(x => uniform(0, 10)).cache Good advice. Don't want bugs with non-stable results and accidental double I/O in your long idiomatic range pipeline? Just put "cache" calls everywhere just to be safe, defensive programming for the win! Strawman, not what I said. But that is what your answer meant in context of my original question :) My complaint was about existing semantics are being error-prone and hard to spot - you proposed it by adding more _manual_ fixup, which kills the whole point.
Re: I'd love to see DScript one day ...
On 06/11/2016 01:01 AM, Walter Bright wrote: > On 6/10/2016 3:55 AM, Chris wrote: >> Cool. I'd love to see `DScript` one day - and replace JS once and for > all ... >> well ... just day dreaming ... > > Dreams are reality: > > https://github.com/DigitalMars/DMDScript On a related topic - has anyone looked into what needs to be done to support D + WebAssembly combo?
Re: Passing private functions to template algorithms
On 06/07/2016 09:59 PM, Timon Gehr wrote: > I think it is obvious that this should work. Visibility checks need to > happen during identifier lookup. This lookup is happening in the module > where isFileNothrow is visible. My understanding is that right now template alias argument means transparent symbol lookup. It acts as if doesn't access alias symbol in template but aliased one directly. I agree such semantics are sub-optimal but changing that can break quite some existing idioms. Consider this snippet for example: enum name ( alias sym ) = sym.stringof; Right now it evaluates to name of passed symbol. If we change lookup semantics to be non-transparent, it must always return `sym` for consistency.
Re: D grammar
On Sunday, 12 June 2016 at 06:45:58 UTC, Russel Winder wrote: I should know this, but… Is there an official D grammar (EBNF or otherwise) or is the language defined by the DMD parser? I am looking to continue Kingsley's DLanguage IntelliJ IDEA plugin and for that it is necessary to have a grammar specification. Kingsley has been working on one, but there may be differences between it and 2.071. Given the compilers and all the supporting tools either there is one language specification they all work with or there is a lot of fragmented viewpoints as to what D actually is. I am hoping the latter is not the case. Officially, the grammar is defined throughout the specification pages, e.g. on http://dlang.org/spec/grammar.html. Practically, not sure how complete / correct it is, though I know it has been kept up to date by people working on compilers and parsers. Pragmatically, there's this: https://github.com/Hackerpilot/DGrammar
