Re: Does D have too many features?
forum.dlang.org apparently failed to post this 10 minutes ago, retrying. On Tuesday, 10 July 2012 at 02:43:05 UTC, Era Scarecrow wrote: On Tuesday, 10 July 2012 at 01:41:29 UTC, bearophile wrote: David Piepgrass: This use case is pretty complex, so if I port this to D, I'd probably just cast away const/immutable where necessary. You are not the first person that says similar things. So D docs need to stress more than casting away const/immutable in D is rather more dangerous than doing the same thing in C++. ... Let's say a class/struct is a book with Page protectors signifying 'const(ant)'. You promise to return the book to the library without making any changes; Although you promised you wouldn't make changes, you still take the Page protectors off and make make notes on the outer edges or make adjustments in the text, then return the book. Is this wise? This isn't C++. If something shouldn't change, then don't change it god damn it. If it needs to change it isn't const(ant) and shouldn't suggest it is. The difficulty, in case you missed it, is that somebody else (the Object class) says that certain functions are const, but in certain cases we really, really want to mutate something, either for efficiency or because "that's just how the data structure works". If a data structure needs to mutate itself when read, yeah, maybe its functions should not be marked const, but quite often the "const" is inherited from Object or some interface that (quite reasonably, it would seem) expects functions that /read stuff/ to be const. And yet we can't drop const from Object or such interfaces, because there is other code elsewhere that /needs/ const to be there. So far I have no solution to the dilemma in mind, btw. But the idea someone had of providing two (otherwise identical) functions, one const and one non-const, feels like a kludge to me, and note that anybody with an object would expect to be able to call the const version on any Object. Seriously, it's not that hard a concept. I guess if something doesn't port well from C++ then redesign it. Some things done in C++ are hacks due to the language's limitations and faults. I was referring to a potential port from C#, which has no const. My particular data structure (a complex beast) contains a mutable tree of arbitrary size, which the user can convert to a conceptually immutable tree in O(1) time by calling Clone(). This marks a flag in the root node that says "read-only! do not change" and shares the root between the clones. At this point it should be safe to cast the clone to immutable. However, the original, mutable-typed version still exists. As the user requests changes to the mutable copy in the future, parts of the tree are duplicated to avoid changing the immutable nodes, with one exception: the read-only flag in various parts of the original, immutable tree will gradually be set to true. In this case, I don't think the D type system could do anything to help ensure that I don't modify the original tree that is supposed to be immutable. Since the static type of internal references must either be all mutable or all immutable, they will be typed mutable in the mutable copy, and immutable in the immutable copy, even though the two copies are sharing the same memory. And one flag, the read-only flag, must be mutable in this data structure, at least the transition from false->true must happen *after* the immutable copy is created; otherwise, Clone() would have to run in O(N) time, to mark every node read-only. This fact, however, does not affect the immutable copy in any way.
Re: Does D have too many features?
On 09-05-2012 10:27, Jacob Carlborg wrote: On 2012-05-09 02:56, Sean Cavanaugh wrote: Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . . I don't see any point in supporting 31.f as a floating point syntax. +1. -- - Alex
Re: Does D have too many features?
On 5/11/12, Andrej Mitrovic wrote: > It turns out it's not a regression: > http://d.puremagic.com/issues/show_bug.cgi?id=8082 > Something odd about module compilation order which makes unrelated > modules error out. > In my project making sure my main.d file is compiled *last* reduces the error count from ~400 lines to just 2 error lines.
Re: Does D have too many features?
On 5/9/12, Don Clugston wrote: > OK, looks like it's a different bug. Please put in bugzilla, with status > of regression. It turns out it's not a regression: http://d.puremagic.com/issues/show_bug.cgi?id=8082 Something odd about module compilation order which makes unrelated modules error out.
Re: Does D have too many features?
On 09/05/12 10:16, Alex Rønne Petersen wrote: On 08-05-2012 23:48, Sean Kelly wrote: On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote: We've previously discussed having _all_ of the C system call functions from the various OSes that we support being in druntime, and I very much think that that's the right way to go. Phobos and druntime then have whatever they need as for as standard C and system call functions go, and anyone who needs any which aren't wrapped by Phobos in some manner has them available to them. Anyone that doesn't want to use any of those C function directly, doesn't have to, but I don't see any reason to hide them just because someone doesn't want to use them in their code. If the problem is that certain C functions end up getting used a lot when they should have D wrappers of some kind which better encapsulate their functionality, then maybe we add the appropriate wrappers to Phobos. But that's a completely different issue. Hiding the C functions doesn't help us any. I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos. It's easily greppable, and easy to avoid using the routines. In fact, I think "import core" anything should be an exceptional case in a typical D application. Everything exposed in Druntime is for what I'd consider power users. Unsafe threads, runtime and GC hooks, platform API calls, etc. It's all there because the higher-level stuff needs it, but is really not intended for general use. I just hope none of it goes away. I make extensive use of many core.* modules. It makes sense to make truly internal stuff internal, but the standard C function declarations and OS system functions are _not_ internal to druntime. They're _very_ much external. druntime is just providing them because they're functionality which is core to the system that any D program is running on. Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all. It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C. *Is* there any system that doesn't support C? ;) There are plenty of systems that don't support C99 perfectly.
Re: Does D have too many features?
On Wednesday, 9 May 2012 at 08:16:35 UTC, Alex Rønne Petersen wrote: I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos. It's easily greppable, and easy to avoid using the routines. In fact, I think "import core" anything should be an exceptional case in a typical D application. Everything exposed in Druntime is for what I'd consider power users. Unsafe threads, runtime and GC hooks, platform API calls, etc. It's all there because the higher-level stuff needs it, but is really not intended for general use. I just hope none of it goes away. I make extensive use of many core.* modules. Could you please provide more details about your use-cases? As Sean said, it might indicate missing functionality in Phobos. Keep in mind we were specifically discussing the C APIs which are an external dependency. No one suggests removing the low-level druntime APIs such as GC hooks. Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all. It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C. *Is* there any system that doesn't support C? ;) It isn't only a question of whether the system supports C or not. There are many considerations when choosing your tool-chain. For instance, the reference implementation of some languages is implemented in ML for its correctness properties. EcmaScript for instance uses ML for the language/runtime. In the JS case, it doesn't necessarily mean your browser will run ML, it just means the highly optimized vendor implementation has an official correct version to compare to. In the D world, we have a few projects that aim to implement a D compiler using D. Why would such a compiler/runtime need to provide C APIs if it's completely written in D?
Re: Does D have too many features?
On 2012-05-09 02:56, Sean Cavanaugh wrote: Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . . I don't see any point in supporting 31.f as a floating point syntax. -- /Jacob Carlborg
Re: Does D have too many features?
On 08-05-2012 23:48, Sean Kelly wrote: On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote: We've previously discussed having _all_ of the C system call functions from the various OSes that we support being in druntime, and I very much think that that's the right way to go. Phobos and druntime then have whatever they need as for as standard C and system call functions go, and anyone who needs any which aren't wrapped by Phobos in some manner has them available to them. Anyone that doesn't want to use any of those C function directly, doesn't have to, but I don't see any reason to hide them just because someone doesn't want to use them in their code. If the problem is that certain C functions end up getting used a lot when they should have D wrappers of some kind which better encapsulate their functionality, then maybe we add the appropriate wrappers to Phobos. But that's a completely different issue. Hiding the C functions doesn't help us any. I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos. It's easily greppable, and easy to avoid using the routines. In fact, I think "import core" anything should be an exceptional case in a typical D application. Everything exposed in Druntime is for what I'd consider power users. Unsafe threads, runtime and GC hooks, platform API calls, etc. It's all there because the higher-level stuff needs it, but is really not intended for general use. I just hope none of it goes away. I make extensive use of many core.* modules. It makes sense to make truly internal stuff internal, but the standard C function declarations and OS system functions are _not_ internal to druntime. They're _very_ much external. druntime is just providing them because they're functionality which is core to the system that any D program is running on. Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all. It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C. *Is* there any system that doesn't support C? ;) -- - Alex
Re: Does D have too many features?
Sean Cavanaugh wrote: > On 5/8/2012 3:36 PM, foobar wrote: > >On Tuesday, 8 May 2012 at 19:00:01 UTC, deadalnix wrote: > >> > >>I think that goal is misunderstood. It is aimed at human being, not > >>compiler. > >> > >>If one read D code that look like C, it should be able to understand > >>it easily. I is not supped to compile with 100% exact semantic. > > > >Unfortunately that is not the case. > >The stated argument is that compiling C code with a D compiler should > >either compile exactly the same or produce a compilation error. > > Thousands of my C/C++ floating point constants are broken by the > CTFE change since as 'integer'-like float constants 31.f and won't > compile anymore, since its trying to do f(31) to them for me now . . > . I wholeheartedly agree that breaking changes are frustrating. But especially this one was needed. What we should provide is a clear path to fix the code. In your case, search and replace using a regular expression like s/(\d+).f/\1.0f/g is the way to fix your code in less than 5 minutes I hope. Jens
Re: Does D have too many features?
On 08/05/12 14:50, Andrej Mitrovic wrote: On 5/8/12, Don Clugston wrote: That bug was fixed in git not long after release. I still get it with this version: http://d.puremagic.com/test-results/test_data.ghtml?dataid=180993 Same errors: http://pastebin.com/8uqgskHd OK, looks like it's a different bug. Please put in bugzilla, with status of regression.
Re: Does D have too many features?
On May 8, 2012, at 2:31 PM, Jonathan M Davis wrote: > > We've previously discussed having _all_ of the C system call functions from > the various OSes that we support being in druntime, and I very much think > that > that's the right way to go. Phobos and druntime then have whatever they need > as for as standard C and system call functions go, and anyone who needs any > which aren't wrapped by Phobos in some manner has them available to them. > Anyone that doesn't want to use any of those C function directly, doesn't > have > to, but I don't see any reason to hide them just because someone doesn't want > to use them in their code. > > If the problem is that certain C functions end up getting used a lot when > they > should have D wrappers of some kind which better encapsulate their > functionality, then maybe we add the appropriate wrappers to Phobos. But > that's a completely different issue. Hiding the C functions doesn't help us > any. I personally use "import core.stdc" as an indicator that there may be some feature missing from Phobos. It's easily greppable, and easy to avoid using the routines. In fact, I think "import core" anything should be an exceptional case in a typical D application. Everything exposed in Druntime is for what I'd consider power users. Unsafe threads, runtime and GC hooks, platform API calls, etc. It's all there because the higher-level stuff needs it, but is really not intended for general use. > It makes sense to make truly internal stuff internal, but the standard C > function declarations and OS system functions are _not_ internal to druntime. > They're _very_ much external. druntime is just providing them because they're > functionality which is core to the system that any D program is running on. Once upon a time, there was a D runtime library (unrelated to Druntime) that has no C library dependence at all. It was an interesting idea, but I don't know that there's any system that D targets which doesn't support C.
Re: Does D have too many features?
On 5/8/2012 7:56 PM, Sean Cavanaugh wrote: On 5/8/2012 3:36 PM, foobar wrote: On Tuesday, 8 May 2012 at 19:00:01 UTC, deadalnix wrote: I think that goal is misunderstood. It is aimed at human being, not compiler. If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic. Unfortunately that is not the case. The stated argument is that compiling C code with a D compiler should either compile exactly the same or produce a compilation error. Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . . s/CTFE/UFCS
Re: Does D have too many features?
On 5/8/2012 7:56 PM, Sean Cavanaugh wrote: On 5/8/2012 3:36 PM, foobar wrote: On Tuesday, 8 May 2012 at 19:00:01 UTC, deadalnix wrote: I think that goal is misunderstood. It is aimed at human being, not compiler. If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic. Unfortunately that is not the case. The stated argument is that compiling C code with a D compiler should either compile exactly the same or produce a compilation error. Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . . s/CTFE/UFCS
Re: Does D have too many features?
On 5/8/2012 3:36 PM, foobar wrote: On Tuesday, 8 May 2012 at 19:00:01 UTC, deadalnix wrote: I think that goal is misunderstood. It is aimed at human being, not compiler. If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic. Unfortunately that is not the case. The stated argument is that compiling C code with a D compiler should either compile exactly the same or produce a compilation error. Thousands of my C/C++ floating point constants are broken by the CTFE change since as 'integer'-like float constants 31.f and won't compile anymore, since its trying to do f(31) to them for me now . . .
Re: Does D have too many features?
On 08-05-2012 23:31, Jonathan M Davis wrote: On Tuesday, May 08, 2012 14:17:14 Sean Kelly wrote: On May 8, 2012, at 9:35 AM, foobar wrote: On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?>> No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.> Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation". This is difficult to do with the module system. You'd have to hand-craft .di files with the stdc headers left out to avoid bundling them in the distro. They could go into core.internal I suppose though. We've previously discussed having _all_ of the C system call functions from the various OSes that we support being in druntime, and I very much think that that's the right way to go. Phobos and druntime then have whatever they need as for as standard C and system call functions go, and anyone who needs any which aren't wrapped by Phobos in some manner has them available to them. Anyone that doesn't want to use any of those C function directly, doesn't have to, but I don't see any reason to hide them just because someone doesn't want to use them in their code. +1. We have better things to fix. If the problem is that certain C functions end up getting used a lot when they should have D wrappers of some kind which better encapsulate their functionality, then maybe we add the appropriate wrappers to Phobos. But that's a completely different issue. Hiding the C functions doesn't help us any. I do think we could benefit from hiding the (deprecated) std.c.* modules on dlang.org (I posted about this a while back). It makes sense to make truly internal stuff internal, but the standard C function declarations and OS system functions are _not_ internal to druntime. They're _very_ much external. druntime is just providing them because they're functionality which is core to the system that any D program is running on. - Jonathan M Davis -- - Alex
Re: Does D have too many features?
On Tuesday, May 08, 2012 14:17:14 Sean Kelly wrote: > On May 8, 2012, at 9:35 AM, foobar wrote: > > On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: > >> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: > >>> [...], what if I find it useful to use e.g. FORTRAN code, should the > >>> relevant functions also be in the stdlib?>> > >> No, FORTRAN has absolutely nothing to do with D. C, on the other hand, > >> does. Both druntime and Phobos depend heavily on the C stdlib. The GC > >> uses malloc/free, std.stdio.File is a wrapper around FILE*, etc.> > > Irrelevant. For all I care druntime could be implemented in Klingon. That > > doesn't mean its API needs to include Klingon as well. That's called > > "encapsulation". > This is difficult to do with the module system. You'd have to hand-craft > .di files with the stdc headers left out to avoid bundling them in the > distro. They could go into core.internal I suppose though. We've previously discussed having _all_ of the C system call functions from the various OSes that we support being in druntime, and I very much think that that's the right way to go. Phobos and druntime then have whatever they need as for as standard C and system call functions go, and anyone who needs any which aren't wrapped by Phobos in some manner has them available to them. Anyone that doesn't want to use any of those C function directly, doesn't have to, but I don't see any reason to hide them just because someone doesn't want to use them in their code. If the problem is that certain C functions end up getting used a lot when they should have D wrappers of some kind which better encapsulate their functionality, then maybe we add the appropriate wrappers to Phobos. But that's a completely different issue. Hiding the C functions doesn't help us any. It makes sense to make truly internal stuff internal, but the standard C function declarations and OS system functions are _not_ internal to druntime. They're _very_ much external. druntime is just providing them because they're functionality which is core to the system that any D program is running on. - Jonathan M Davis
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 21:17:21 UTC, Sean Kelly wrote: On May 8, 2012, at 9:35 AM, foobar wrote: On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation". This is difficult to do with the module system. You'd have to hand-craft .di files with the stdc headers left out to avoid bundling them in the distro. They could go into core.internal I suppose though. Having an internal package is a good idea. Don did the same for the Math code. More over, the general issue with the module system should be fixed. There was a recent discussion about Andrei's DIP, precisely about addressing this problem.
Re: Does D have too many features?
On May 8, 2012, at 10:24 AM, foobar wrote: > On Tuesday, 8 May 2012 at 17:03:10 UTC, Lars T. Kyllingstad wrote: >> On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote: >>> On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: > [...], what if I find it useful to use e.g. FORTRAN code, should the > relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. -Lars >>> >>> Irrelevant. For all I care druntime could be implemented in Klingon. That >>> doesn't mean its API needs to include Klingon as well. That's called >>> "encapsulation". >> >> Um... so you don't mind the C/POSIX declarations being there, you just want >> them to be private so you aren't tempted to use them in your own code? > > Yes, pretty much. > They are an implementation detail of druntime/phobos. > > Other vendors may choose to implement the tool-chain with another language in > mind and as long as the API remains the same I shouldn't need to care e.g. > how the GC allocation is implemented (Perhaps it's done with FORTRAN's memory > allocation routines). > > If I ,the user, want to interface with C I need to use the "official" C > headers in Deimos. This is after all the official location for that. I think this is two separate issues. The GC implementation is very much hidden already. The only point of exposure for standard C headers is in core.*, and frankly, I think the only ones actually used are core.sys.windows and core.sys.posix (posix admittedly being a superset of standard C, as stated before).
Re: Does D have too many features?
On May 8, 2012, at 9:35 AM, foobar wrote: > On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: >> On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: >>> [...], what if I find it useful to use e.g. FORTRAN code, should the >>> relevant functions also be in the stdlib? >> >> No, FORTRAN has absolutely nothing to do with D. C, on the other hand, >> does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses >> malloc/free, std.stdio.File is a wrapper around FILE*, etc. > > Irrelevant. For all I care druntime could be implemented in Klingon. That > doesn't mean its API needs to include Klingon as well. That's called > "encapsulation". This is difficult to do with the module system. You'd have to hand-craft .di files with the stdc headers left out to avoid bundling them in the distro. They could go into core.internal I suppose though.
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 19:00:01 UTC, deadalnix wrote: I think that goal is misunderstood. It is aimed at human being, not compiler. If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic. Unfortunately that is not the case. The stated argument is that compiling C code with a D compiler should either compile exactly the same or produce a compilation error. As discussed, this is _already_ incorrect for some cases, is completely unnecessary since you can link with pre-compiled C code (via a C compiler) _without_ any overhead and this forces us to carry legacy C design flaws. If you talking about ease of understanding "C-like" D, that's already a given because D belongs to the C-family of languages. For that matter, JavaScript also belongs to the same family and is easily understood (if you write C-like code). yet no one expects to be able to copy/paste C code into a JS script and have it working as/is.
Re: Does D have too many features?
Le 08/05/2012 13:59, foobar a écrit : On Sunday, 6 May 2012 at 22:06:32 UTC, Jonathan M Davis wrote: This argument comes up every once in a while even though AFAIK it is *not* a goal of D and never has been! D does not and *should not* strive to be source compatible with C. We already have C++ for that and it is a horrible idea. D can link with C which allows to use pre-existing C code. we should *not* encourage converting C code to D code at all. Either just link the C code or use D idiomatic code. Then you misunderstand. One of the tenets that D holds to is that any C/C++ code either compiles as valid D code with identical semantics, or it doesn't compile as D code (there are a few minor exceptions - such as static arrays being passed by value - but not many). This means that we can break compatibility with C/C++ and do our own thing for a lot of stuff but that we can't just redefine what stuff does such that it would silently break code when it's ported from C/C++ to D. That approach is _very_ different from C++'s approach where valid C code pretty much _always_ compiles identically in C++ (the fact that C++ added keywords being the only exception that I can think of at the moment), but that doesn't mean that we don't care about code portability from C/C++ to D. There's a huge difference between designing a language such that porting code to it from another language isn't error-prone and making the new language source compatibile. D does the former. C++ does the latter. Being able to port code from C/C++ to D without having to worry about silent breakage _is_ one of D's goals. - Jonathan M Davis I have a three main problems with the above: a. C++ is *not* fully source compatible with C, especially the latest C99 conflicts with C++ IIRC. b. D isn't either - there are already semantics changes compared to C, as you said so yourself, e.g. static arrays, default initialization of static floats, etc. c. If this is currently a goal of D it really shouldn't be - it prevents us from fixing design bugs we inherited from C such as implicit numeric coercions. As others said, the only thing that sort-of makes sense is to copy/paste *declarations* and even those are different enough in D that they deserve at least a look over to make sure they are correct. We shouldn't promote this "goal" at all especially given that it isn't even guarantied to be 100% correct in all cases. Really what we should be promoting is the fact that D is _link_ compatible with C and allows you to use existing C code _without_ porting it to D. I think that goal is misunderstood. It is aimed at human being, not compiler. If one read D code that look like C, it should be able to understand it easily. I is not supped to compile with 100% exact semantic.
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 17:24:24 UTC, foobar wrote: On Tuesday, 8 May 2012 at 17:03:10 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote: On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. -Lars Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation". Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code? -Lars Yes, pretty much. They are an implementation detail of druntime/phobos. Other vendors may choose to implement the tool-chain with another language in mind and as long as the API remains the same I shouldn't need to care e.g. how the GC allocation is implemented (Perhaps it's done with FORTRAN's memory allocation routines). If I ,the user, want to interface with C I need to use the "official" C headers in Deimos. This is after all the official location for that. BTW, it makes sense even if druntime is implemented with C/POSIX - it decouples the user-facing headers from those used by the runtime. the runtime could depend on an older stable version than the one exposed to the users. I assume druntime/phobos uses some windows APIs in their implementations. Now consider the new winRT API for windows. It should be a matter of updating the headers in a separate repository so that it would be exposed to end-users without waiting on a druntime update to utilize those APIs.
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 17:03:10 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote: On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. -Lars Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation". Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code? -Lars Yes, pretty much. They are an implementation detail of druntime/phobos. Other vendors may choose to implement the tool-chain with another language in mind and as long as the API remains the same I shouldn't need to care e.g. how the GC allocation is implemented (Perhaps it's done with FORTRAN's memory allocation routines). If I ,the user, want to interface with C I need to use the "official" C headers in Deimos. This is after all the official location for that.
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 16:35:05 UTC, foobar wrote: On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. -Lars Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation". Um... so you don't mind the C/POSIX declarations being there, you just want them to be private so you aren't tempted to use them in your own code? -Lars
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 14:59:43 UTC, Lars T. Kyllingstad wrote: On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. -Lars Irrelevant. For all I care druntime could be implemented in Klingon. That doesn't mean its API needs to include Klingon as well. That's called "encapsulation".
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 14:48:27 UTC, foobar wrote: [...], what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib? No, FORTRAN has absolutely nothing to do with D. C, on the other hand, does. Both druntime and Phobos depend heavily on the C stdlib. The GC uses malloc/free, std.stdio.File is a wrapper around FILE*, etc. -Lars
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 13:57:30 UTC, bearophile wrote: foobar: As others said, the only thing that sort-of makes sense is to copy/paste *declarations* and even those are different enough in D that they deserve at least a look over to make sure they are correct. We shouldn't promote this "goal" at all especially given that it isn't even guarantied to be 100% correct in all cases. Really what we should be promoting is the fact that D is _link_ compatible with C and allows you to use existing C code _without_ porting it to D. For various reasons I have translated many times routines, functions and other small and medium amounts of C code to D. And in many cases I have used the C std lib functions to circumvent bugs or limitations or performance problems of Phobos. In both cases I have found the C functions quite useful, so moving them into not built-in stuff is bad for me. The risk of using C functions by mistake is low enough. Bye, bearophile That does not contradict what I said. No one stops you from _translating_ C/C++ code (or any other language for that matter) to D. You shouldn't however rely on _copy/pasting_ C code and expect it to magically just work with 100% certainty. I also did not say that using C headers should be forbidden, merely that it should obey the code organization - the current scheme which was defined by Walter is to put such headers in Deimos. I wouldn't mind if Deimos would come bundled with the D tool-chain or be easily accessible via a package manager, Just that code should be kept organized according to our own defined scheme. Besides, what if I find it useful to use e.g. FORTRAN code, should the relevant functions also be in the stdlib?
Re: Does D have too many features?
On Tuesday, 8 May 2012 at 13:57:30 UTC, bearophile wrote: in many cases I have used the C std lib functions to circumvent bugs or limitations or performance problems of Phobos. In both I tend to agree with the performance aspect. I just got done with a very challenging class where we solved programming contest style problems ... we got bonus points for the fastest solution (or solutions that could solve extended versions of the problems). It was extremely useful for me to be able to use the C versions of functions. Especially I/O because it made it significantly faster to do some things. That said, some of the things I was doing I would never advocate for being easy/possible with D's I/O.
Re: Does D have too many features?
foobar: As others said, the only thing that sort-of makes sense is to copy/paste *declarations* and even those are different enough in D that they deserve at least a look over to make sure they are correct. We shouldn't promote this "goal" at all especially given that it isn't even guarantied to be 100% correct in all cases. Really what we should be promoting is the fact that D is _link_ compatible with C and allows you to use existing C code _without_ porting it to D. For various reasons I have translated many times routines, functions and other small and medium amounts of C code to D. And in many cases I have used the C std lib functions to circumvent bugs or limitations or performance problems of Phobos. In both cases I have found the C functions quite useful, so moving them into not built-in stuff is bad for me. The risk of using C functions by mistake is low enough. Bye, bearophile
Re: Does D have too many features?
On 5/8/12, foobar wrote: > a. C++ is *not* fully source compatible with C, especially the > latest C99 conflicts with C++ IIRC. Yeah there's a nice list in the C++ standard, Annex C.1 (C++ and ISO C). PDF: www-d0.fnal.gov/~dladams/cxx_standard.pdf
Re: Does D have too many features?
On 5/8/12, Don Clugston wrote: > That bug was fixed in git not long after release. I still get it with this version: http://d.puremagic.com/test-results/test_data.ghtml?dataid=180993 Same errors: http://pastebin.com/8uqgskHd
Re: Does D have too many features?
On Sunday, 6 May 2012 at 22:06:32 UTC, Jonathan M Davis wrote: This argument comes up every once in a while even though AFAIK it is *not* a goal of D and never has been! D does not and *should not* strive to be source compatible with C. We already have C++ for that and it is a horrible idea. D can link with C which allows to use pre-existing C code. we should *not* encourage converting C code to D code at all. Either just link the C code or use D idiomatic code. Then you misunderstand. One of the tenets that D holds to is that any C/C++ code either compiles as valid D code with identical semantics, or it doesn't compile as D code (there are a few minor exceptions - such as static arrays being passed by value - but not many). This means that we can break compatibility with C/C++ and do our own thing for a lot of stuff but that we can't just redefine what stuff does such that it would silently break code when it's ported from C/C++ to D. That approach is _very_ different from C++'s approach where valid C code pretty much _always_ compiles identically in C++ (the fact that C++ added keywords being the only exception that I can think of at the moment), but that doesn't mean that we don't care about code portability from C/C++ to D. There's a huge difference between designing a language such that porting code to it from another language isn't error-prone and making the new language source compatibile. D does the former. C++ does the latter. Being able to port code from C/C++ to D without having to worry about silent breakage _is_ one of D's goals. - Jonathan M Davis I have a three main problems with the above: a. C++ is *not* fully source compatible with C, especially the latest C99 conflicts with C++ IIRC. b. D isn't either - there are already semantics changes compared to C, as you said so yourself, e.g. static arrays, default initialization of static floats, etc. c. If this is currently a goal of D it really shouldn't be - it prevents us from fixing design bugs we inherited from C such as implicit numeric coercions. As others said, the only thing that sort-of makes sense is to copy/paste *declarations* and even those are different enough in D that they deserve at least a look over to make sure they are correct. We shouldn't promote this "goal" at all especially given that it isn't even guarantied to be 100% correct in all cases. Really what we should be promoting is the fact that D is _link_ compatible with C and allows you to use existing C code _without_ porting it to D.
Re: Does D have too many features?
On 08/05/12 09:56, Andrej Mitrovic wrote: On 4/30/12, Andrej Mitrovic wrote: Personally my gripe with compilation times is that I get very used to having fast build times where I can go through an edit+compile+run cycle really fast, but after a while build times get slower Also since 2.059 error reporting is *completely* broken. I have to wait 5 seconds just to get this error message itself to print to the screen: http://pastebin.com/y93GEPAf 500 lines of errors even though only the first line is an actual error. What in the actual fuck are all those other error messages? The only problem was this line in a main file: CppGen gen; and CppGen was undefined because I've missed an import. And if I remove the only import left (std.range), I get much less garbage but I still get unrelated errors: main.d(80): Error: undefined identifier CppGen D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl does not match any function template declaration D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl cannot deduce template function from argument types !(string)(long) D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template instance toImpl!(string) errors instantiating template loader\gcc.d(167): Error: template instance std.conv.to!(string).to!(long) error instantiating 2.058 error reporting worked fine, I don't know what someone did to screw this up so massively. That bug was fixed in git not long after release. Unfortunately it seems that there are not enough people doing beta testing. As for why it happened -- previously the compiler used a hack to prevent the flood of error messages (and the hack didn't work properly in the case where errors were gagged, like in is(typeof()) ). Now it does it properly.
Re: Does D have too many features?
On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote: On 5/3/2012 8:13 AM, Don Clugston wrote: Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc. It's there to make converting C code to D code easier. I agree that this is a good enough reason in itself. On top of that, the ANSI C stdlib is a subset of the POSIX API, which is *very* useful to have in druntime. Phobos (and druntime itself, of course), uses it for everything platform-specific. -Lars
Re: Does D have too many features?
On 4/30/12, Andrej Mitrovic wrote: > Personally my gripe with compilation times is that I get very used to > having fast build times where I can go through an edit+compile+run > cycle really fast, but after a while build times get slower Also since 2.059 error reporting is *completely* broken. I have to wait 5 seconds just to get this error message itself to print to the screen: http://pastebin.com/y93GEPAf 500 lines of errors even though only the first line is an actual error. What in the actual fuck are all those other error messages? The only problem was this line in a main file: CppGen gen; and CppGen was undefined because I've missed an import. And if I remove the only import left (std.range), I get much less garbage but I still get unrelated errors: main.d(80): Error: undefined identifier CppGen D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl does not match any function template declaration D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template std.conv.toImpl cannot deduce template function from argument types !(string)(long) D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\conv.d(244): Error: template instance toImpl!(string) errors instantiating template loader\gcc.d(167): Error: template instance std.conv.to!(string).to!(long) error instantiating 2.058 error reporting worked fine, I don't know what someone did to screw this up so massively.
Re: Does D have too many features?
On 05/07/2012 03:22 AM, Andrew Wiley wrote: I had some problems with floats being default initialized to NaN. That's still correct behavior for C, actually. Using an uninitialized variable in C results in undefined behavior, so D still complies with C requirements when it initializes floats to NaN. For variables with static storage, C initializes them by default to zero. It's in the spec.
Re: Does D have too many features?
On Mon, May 7, 2012 at 2:10 AM, Jacob Carlborg wrote: > On 2012-05-07 08:03, Jonathan M Davis wrote: > > The only place that I'm aware of where this policy has caused some >> problems is >> arithmetic and integral promotions. There a few cases where it would be >> nice >> to change the semantics for that, but for the most part, the C/C++ >> semantics >> are fine, and I'm sure that Walter considers whatever loss we get there >> to be >> worth the gain in making it so that C/C++ code ports to D without breaking >> silently. >> > > I had some problems with floats being default initialized to NaN. > > That's still correct behavior for C, actually. Using an uninitialized variable in C results in undefined behavior, so D still complies with C requirements when it initializes floats to NaN. I'm guessing there's more to it than that, though, because code that uses uninitialized floats was probably wrong to begin with.
Re: Does D have too many features?
On 07-05-2012 09:10, Jacob Carlborg wrote: On 2012-05-07 08:03, Jonathan M Davis wrote: The only place that I'm aware of where this policy has caused some problems is arithmetic and integral promotions. There a few cases where it would be nice to change the semantics for that, but for the most part, the C/C++ semantics are fine, and I'm sure that Walter considers whatever loss we get there to be worth the gain in making it so that C/C++ code ports to D without breaking silently. I had some problems with floats being default initialized to NaN. I still think floats being initialized to NaN is an atrocity... -- - Alex
Re: Does D have too many features?
On 2012-05-07 08:03, Jonathan M Davis wrote: The only place that I'm aware of where this policy has caused some problems is arithmetic and integral promotions. There a few cases where it would be nice to change the semantics for that, but for the most part, the C/C++ semantics are fine, and I'm sure that Walter considers whatever loss we get there to be worth the gain in making it so that C/C++ code ports to D without breaking silently. I had some problems with floats being default initialized to NaN. -- /Jacob Carlborg
Re: Does D have too many features?
On 2012-05-07 09:09, Alex Rønne Petersen wrote: But declarations are very different from actual statements and expressions (I assume you mean declarations?). That's true. Yes, declarations. -- /Jacob Carlborg
Re: Does D have too many features?
On 07-05-2012 09:07, Jacob Carlborg wrote: On 2012-05-07 07:48, Alex Rønne Petersen wrote: So basically, language design advances on our front have to be hindered by some kind of compatibility that has *very* questionable usefulness. I have never copy/pasted C/C++ code into D. Ever. Even when making bindings, I type declarations out manually to be completely sure I get them right. I've created bindings for libclang, I did that by copy-pasting the C code and then some quick search-and-replace. Although this is the only library I manged to create bindings for this easy. But declarations are very different from actual statements and expressions (I assume you mean declarations?). -- - Alex
Re: Does D have too many features?
On 2012-05-07 07:48, Alex Rønne Petersen wrote: So basically, language design advances on our front have to be hindered by some kind of compatibility that has *very* questionable usefulness. I have never copy/pasted C/C++ code into D. Ever. Even when making bindings, I type declarations out manually to be completely sure I get them right. I've created bindings for libclang, I did that by copy-pasting the C code and then some quick search-and-replace. Although this is the only library I manged to create bindings for this easy. -- /Jacob Carlborg
Re: Does D have too many features?
On Monday, May 07, 2012 07:48:05 Alex Rønne Petersen wrote: > On 07-05-2012 00:06, Jonathan M Davis wrote: > > On Sunday, May 06, 2012 21:18:38 foobar wrote: > >> On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote: > >>> On 5/3/2012 8:13 AM, Don Clugston wrote: > Well, they are also used in druntime, in core.stdc.math > BTW I *hate* that module, I don't know why it exists. Even > worse, it seems to be > growing -- people are adding more things to it. > >>> > >>> It's there simply because all the Standard C headers should be > >>> represented. It should not get anything that is not in Standard > >>> C. Ditto for all the other stuff in core.stdc. > >>> > >>> It's there to make converting C code to D code easier. > >> > >> This argument comes up every once in a while even though AFAIK it > >> is *not* a goal of D and never has been! > >> D does not and *should not* strive to be source compatible with > >> C. We already have C++ for that and it is a horrible idea. > >> D can link with C which allows to use pre-existing C code. we > >> should *not* encourage converting C code to D code at all. Either > >> just link the C code or use D idiomatic code. > > > > Then you misunderstand. One of the tenets that D holds to is that any > > C/C++ > > code either compiles as valid D code with identical semantics, or it > > doesn't compile as D code (there are a few minor exceptions - such as > > static arrays being passed by value - but not many). This means that we > > can break compatibility with C/C++ and do our own thing for a lot of > > stuff but that we can't just redefine what stuff does such that it would > > silently break code when it's ported from C/C++ to D. > > So basically, language design advances on our front have to be hindered > by some kind of compatibility that has *very* questionable usefulness. I > have never copy/pasted C/C++ code into D. Ever. Even when making > bindings, I type declarations out manually to be completely sure I get > them right. > > This is like when C++ tried to be source compatible with C. In practice, > nearly no one just took a C source base and compiled it as C++ and > called it a day, because of two reasons: 1) C++ wasn't actually source > compatible enough so that this would just be a tiny build system change, > 2) there would be zero gain in doing it. I haven't ever copy/pasted C > code into C++ either, now that I think about it. > > I don't think you're going to see people port their large C source bases > to D just for the sake of doing it. I think, rather, you'll see them > write bindings because that's the more pragmatic and time-efficient > approach. We only require source compatibility so far as C/C++ code which compiles as D code needs to have the same semantics as it does in C/C++. This actually causes very few restrictions, because D's syntax differs enough that compiling C/C++ as D code breaks _very_ quickly. But by having that level of compatability, we make it so that porting code from C/C++ (which people _will_ do, even if the majority of D programmers don't) doesn't break silently. The only place that I'm aware of where this policy has caused some problems is arithmetic and integral promotions. There a few cases where it would be nice to change the semantics for that, but for the most part, the C/C++ semantics are fine, and I'm sure that Walter considers whatever loss we get there to be worth the gain in making it so that C/C++ code ports to D without breaking silently. I really don't think that this level of compatibility with C/C++ has cost us much. As similar as D's syntax is, it differs in so many small ways, that C/C++ code quickly fails to compile as D code, and so the small level of compatibility that we insist on doesn't affect much. > BTW, if we're so focused on C/C++ source compatibility, what about the > unfortunate D1 folks? We seem to largely not care about source > compatibility for their code at all. Seems like our priorities are quite > skewed. D was frozen as D1 when it was so that the folks using D for real work could continue to do so while major breakages continued to occur as the language was expanded and refined (in particular, const was going to be added, which was going to break a _lot_). It was _never_ intended that D2 be source compatible with D1 or that D1 even stick around long term. It was merely a stable branch which was left around in order to let people continue to use the language for real work while the main branch continued to be developed. In the long run, D1 will be pretty much dead, while we'll still have to worry about people porting C/C++ code to D for pretty much forever. - Jonathan M Davis
Re: Does D have too many features?
On 07-05-2012 00:06, Jonathan M Davis wrote: On Sunday, May 06, 2012 21:18:38 foobar wrote: On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote: On 5/3/2012 8:13 AM, Don Clugston wrote: Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc. It's there to make converting C code to D code easier. This argument comes up every once in a while even though AFAIK it is *not* a goal of D and never has been! D does not and *should not* strive to be source compatible with C. We already have C++ for that and it is a horrible idea. D can link with C which allows to use pre-existing C code. we should *not* encourage converting C code to D code at all. Either just link the C code or use D idiomatic code. Then you misunderstand. One of the tenets that D holds to is that any C/C++ code either compiles as valid D code with identical semantics, or it doesn't compile as D code (there are a few minor exceptions - such as static arrays being passed by value - but not many). This means that we can break compatibility with C/C++ and do our own thing for a lot of stuff but that we can't just redefine what stuff does such that it would silently break code when it's ported from C/C++ to D. So basically, language design advances on our front have to be hindered by some kind of compatibility that has *very* questionable usefulness. I have never copy/pasted C/C++ code into D. Ever. Even when making bindings, I type declarations out manually to be completely sure I get them right. This is like when C++ tried to be source compatible with C. In practice, nearly no one just took a C source base and compiled it as C++ and called it a day, because of two reasons: 1) C++ wasn't actually source compatible enough so that this would just be a tiny build system change, 2) there would be zero gain in doing it. I haven't ever copy/pasted C code into C++ either, now that I think about it. I don't think you're going to see people port their large C source bases to D just for the sake of doing it. I think, rather, you'll see them write bindings because that's the more pragmatic and time-efficient approach. BTW, if we're so focused on C/C++ source compatibility, what about the unfortunate D1 folks? We seem to largely not care about source compatibility for their code at all. Seems like our priorities are quite skewed. That approach is _very_ different from C++'s approach where valid C code pretty much _always_ compiles identically in C++ (the fact that C++ added keywords being the only exception that I can think of at the moment), but that doesn't mean that we don't care about code portability from C/C++ to D. There's a huge difference between designing a language such that porting code to it from another language isn't error-prone and making the new language source compatibile. D does the former. C++ does the latter. http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B We probably have many of the incompatibilities mentioned there too. Being able to port code from C/C++ to D without having to worry about silent breakage _is_ one of D's goals. - Jonathan M Davis -- - Alex
Re: Does D have too many features?
On 5/6/2012 8:09 AM, deadalnix wrote: I may scare people here, but as Deimos is only declaration, I see no problem to use a deimos header in druntime. I do, because it adds another dependency on something not in the main download.
Re: Does D have too many features?
On Sunday, May 06, 2012 21:18:38 foobar wrote: > On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote: > > On 5/3/2012 8:13 AM, Don Clugston wrote: > >> Well, they are also used in druntime, in core.stdc.math > >> BTW I *hate* that module, I don't know why it exists. Even > >> worse, it seems to be > >> growing -- people are adding more things to it. > > > > It's there simply because all the Standard C headers should be > > represented. It should not get anything that is not in Standard > > C. Ditto for all the other stuff in core.stdc. > > > > It's there to make converting C code to D code easier. > > This argument comes up every once in a while even though AFAIK it > is *not* a goal of D and never has been! > D does not and *should not* strive to be source compatible with > C. We already have C++ for that and it is a horrible idea. > D can link with C which allows to use pre-existing C code. we > should *not* encourage converting C code to D code at all. Either > just link the C code or use D idiomatic code. Then you misunderstand. One of the tenets that D holds to is that any C/C++ code either compiles as valid D code with identical semantics, or it doesn't compile as D code (there are a few minor exceptions - such as static arrays being passed by value - but not many). This means that we can break compatibility with C/C++ and do our own thing for a lot of stuff but that we can't just redefine what stuff does such that it would silently break code when it's ported from C/C++ to D. That approach is _very_ different from C++'s approach where valid C code pretty much _always_ compiles identically in C++ (the fact that C++ added keywords being the only exception that I can think of at the moment), but that doesn't mean that we don't care about code portability from C/C++ to D. There's a huge difference between designing a language such that porting code to it from another language isn't error-prone and making the new language source compatibile. D does the former. C++ does the latter. Being able to port code from C/C++ to D without having to worry about silent breakage _is_ one of D's goals. - Jonathan M Davis
Re: Does D have too many features?
On Thursday, 3 May 2012 at 22:57:02 UTC, Walter Bright wrote: On 5/3/2012 8:13 AM, Don Clugston wrote: Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc. It's there to make converting C code to D code easier. This argument comes up every once in a while even though AFAIK it is *not* a goal of D and never has been! D does not and *should not* strive to be source compatible with C. We already have C++ for that and it is a horrible idea. D can link with C which allows to use pre-existing C code. we should *not* encourage converting C code to D code at all. Either just link the C code or use D idiomatic code. IMO C headers should be moved to Deimos, and should be clearly documented that their intended purpose is to _link_ D code with the C runtime.
Re: Does D have too many features?
Le 04/05/2012 02:03, Sean Kelly a écrit : On May 3, 2012, at 2:16 PM, deadalnix wrote: Le 03/05/2012 22:43, Sean Kelly a écrit : On May 3, 2012, at 1:11 PM, Don wrote: On 03.05.2012 21:08, Sean Kelly wrote: On May 3, 2012, at 8:13 AM, Don Clugston wrote: On 03/05/12 16:13, Andrei Alexandrescu wrote: Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math. core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface. It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro. If there is anything nonstandard in there, I'm not aware of it. Yes, but why do we have it? We're not C. Mostly because it was handy to fall back on the C API before Phobos was so well fleshed-out. Today, I think it mostly exists to ease porting of C apps. So they probably belongs to deimos. Except that they're used by druntime, both explicitly and publicly imported by core.sys.posix. I may scare people here, but as Deimos is only declaration, I see no problem to use a deimos header in druntime.
Re: Does D have too many features?
On Friday, May 04, 2012 09:38:24 Jacob Carlborg wrote: > On 2012-05-03 22:36, Jonathan M Davis wrote: > > On Thursday, May 03, 2012 15:30:40 Don Clugston wrote: > >> What is this D3 thing > >> As far as I can tell, 'D3' was invented by newcomers to the forums. > > > > I think that what it comes down to is that there are a variety of people > > who want features added or changed in D which are either not going to > > happen anytime soon or will never happen in D2 (especially if they're > > major breaking changes). So, they figure/hope that we'll have a new > > revision of the language where we'll be able to make breaking changes and > > then maybe the changes that they want will make it in then. After all, > > particularly from the perspective of a newbie, we already had D2 which > > changed a bunch of stuff from D1, why wouldn't we have D3 later on? And > > for folks who really want to see changes that aren't going to happen, the > > idea that we're going to have another major revision of the language > > which might make the changes that they want sounds really appealing. > > > > I think that Walter and Andrei have made it fairly clear when they've said > > anything on the subject that there is no intention to make any kind of D3 > > anytime soon and that if we do, it'll be years from now after D2 is mature > > and well-established, and it actually makes sense to do a new major > > revision. But I do think that you're right in that the very idea of a D3 > > was created by folks in the newsgroup. Walter and the other developers > > have been focusing on stabilizing D2 as _the_ version of the language, > > not finishing it up so that they can move onto D3. And the misconceptions > > about D1 that you've pointed out in the past probably just help > > contribute to the idea that we'll have a D3 at some point. Maybe we will, > > maybe we won't, but there's no point in worrying about it for years yet. > > > > - Jonathan M Davis > > People has been talking about D3 for quite a while. Have a look at: > > http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel > > Search for "Known to be deferred to D3.0". The features listed there > were talked about before D2. Oh. I know that they've been talking about it for a while, but as far as I can tell, the term has gotten used primarily due to people who don't like the fact that D2 is doing something a particular way or isn't doing something a particular way and who hope that there will be a future version of the language which does it the way that they want. Certainly, it's not something which Walter has pushed at all (the opposite, if anything). - Jonathan M Davis
Re: Does D have too many features?
On 2012-05-03 22:36, Jonathan M Davis wrote: On Thursday, May 03, 2012 15:30:40 Don Clugston wrote: What is this D3 thing As far as I can tell, 'D3' was invented by newcomers to the forums. I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing. I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet. - Jonathan M Davis People has been talking about D3 for quite a while. Have a look at: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel Search for "Known to be deferred to D3.0". The features listed there were talked about before D2. -- /Jacob Carlborg
Re: Does D have too many features?
On 4 May 2012 01:40, Alex Rønne Petersen wrote: > On 04-05-2012 02:13, Iain Buclaw wrote: >> >> On 3 May 2012 16:13, Don Clugston wrote: >>> >>> On 03/05/12 16:13, Andrei Alexandrescu wrote: >>> On 5/3/12 9:55 AM, Don Clugston wrote: > > > On 28/04/12 20:47, Walter Bright wrote: >> >> >> Andrei and I had a fun discussion last night about this question. The >> idea was which features in D are redundant and/or do not add >> significant >> value? >> >> A couple already agreed upon ones are typedef and the cfloat, cdouble >> and creal types. >> >> What's your list? > > > > Other ones which were agreed to a long time ago were: > > * NCEG operators > > * built-in .sort and .reverse Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). >>> >>> >>> >>> Well, they are also used in druntime, in core.stdc.math >>> >>> BTW I *hate* that module, I don't know why it exists. Even worse, it >>> seems >>> to be growing -- people are adding more things to it. >>> Practically everything in there has a better implementation in std.math. >> >> >> I used core.stdc.math to map GCC builtins to math lib functions. This >> allows for a lot of potential const folding that the D frontend does >> not (currently) handle. >> > > Does that play nice with errno? > The default is -fno-errno-math for GDC, so errno is not usually set after calling single math instructions. This allows most functions to be used in pure routines. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Does D have too many features?
On 04-05-2012 02:13, Iain Buclaw wrote: On 3 May 2012 16:13, Don Clugston wrote: On 03/05/12 16:13, Andrei Alexandrescu wrote: On 5/3/12 9:55 AM, Don Clugston wrote: On 28/04/12 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? Other ones which were agreed to a long time ago were: * NCEG operators * built-in .sort and .reverse Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math. I used core.stdc.math to map GCC builtins to math lib functions. This allows for a lot of potential const folding that the D frontend does not (currently) handle. Does that play nice with errno? -- - Alex
Re: Does D have too many features?
On 04-05-2012 01:41, H. S. Teoh wrote: On Fri, May 04, 2012 at 01:12:20AM +0200, Era Scarecrow wrote: On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote: On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote: Do we know (roughly) how many D users are out there right now? Don't know. Need a poll :) I'm definitely sure we have at least 10 users; beyond that I can only speculate; Maybe 2 to the power of ten or thirteen... Only 10?? Judging from mailing list membership, I'd say at least 25 or 30, just on the forums alone. I'm assuming that people here aren't subscribed just for kicks, they actually write D code. There are probably more outside the forums (somebody mentioned an entire company of D programmers before, perhaps about 50-100? I don't remember the exact figure). There's got to be more out there, given that Andrei has been giving talks about D for a while. *Somebody* in the audience must be actually listening to what he says. But in any case, I'd say we have a ways to go yet in terms of D adoption. There are more users than one might think. If you fancy some IRC, you should drop by #d (104 users), #d.gdc (17 users), #ldc (18 users), #d.sdc (5 users) on irc.freenode.net. :) There's also #d on irc.oftc.net (started by Iain). [...] Anyways, focus on the now. D3 may/will come some day, but that's a long ways off. Course if you plan early for certain things that will change it does make going towards it easier with language design, or give you more time to think about faults and fixes. Yep. T -- - Alex
Re: Does D have too many features?
On 3 May 2012 16:13, Don Clugston wrote: > On 03/05/12 16:13, Andrei Alexandrescu wrote: >> >> On 5/3/12 9:55 AM, Don Clugston wrote: >>> >>> On 28/04/12 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? >>> >>> >>> Other ones which were agreed to a long time ago were: >>> >>> * NCEG operators >>> >>> * built-in .sort and .reverse >> >> >> Good ones. In fact I even discounted them from this discussion because >> I'd already considered them gone. Walter agreed that I don't mention >> them in TDPL, with the intent to have them peter out. >> >> One good step right now would be to remove NCEG operators from the >> online documentation. Later on, we'll consider them an accept-invalid >> bug :o). > > > Well, they are also used in druntime, in core.stdc.math > > BTW I *hate* that module, I don't know why it exists. Even worse, it seems > to be growing -- people are adding more things to it. > Practically everything in there has a better implementation in std.math. I used core.stdc.math to map GCC builtins to math lib functions. This allows for a lot of potential const folding that the D frontend does not (currently) handle. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Does D have too many features?
On Thursday, 3 May 2012 at 23:40:32 UTC, H. S. Teoh wrote: Only 10?? Judging from mailing list membership, I'd say at least 25 or 30, just on the forums alone. I'm assuming that people here aren't subscribed just for kicks, they actually write D code. There are probably more outside the forums (somebody mentioned an entire company of D programmers before, perhaps about 50-100? I don't remember the exact figure). There's got to be more out there, given that Andrei has been giving talks about D for a while. *Somebody* in the audience must be actually listening to what he says. I was being sarcastic :P
Re: Does D have too many features?
On May 3, 2012, at 2:16 PM, deadalnix wrote: > Le 03/05/2012 22:43, Sean Kelly a écrit : >> On May 3, 2012, at 1:11 PM, Don wrote: >> >>> On 03.05.2012 21:08, Sean Kelly wrote: On May 3, 2012, at 8:13 AM, Don Clugston wrote: > On 03/05/12 16:13, Andrei Alexandrescu wrote: >> >> >> Good ones. In fact I even discounted them from this discussion because >> I'd already considered them gone. Walter agreed that I don't mention >> them in TDPL, with the intent to have them peter out. >> >> One good step right now would be to remove NCEG operators from the >> online documentation. Later on, we'll consider them an accept-invalid >> bug :o). > > Well, they are also used in druntime, in core.stdc.math > > BTW I *hate* that module, I don't know why it exists. Even worse, it > seems to be growing -- people are adding more things to it. > Practically everything in there has a better implementation in std.math. core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface. It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro. If there is anything nonstandard in there, I'm not aware of it. >>> >>> Yes, but why do we have it? We're not C. >> >> Mostly because it was handy to fall back on the C API before Phobos was so >> well fleshed-out. Today, I think it mostly exists to ease porting of C apps. > > So they probably belongs to deimos. Except that they're used by druntime, both explicitly and publicly imported by core.sys.posix.
Re: Does D have too many features?
On Fri, May 04, 2012 at 01:12:20AM +0200, Era Scarecrow wrote: > On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote: > >On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote: > >Do we know (roughly) how many D users are out there right now? > > Don't know. Need a poll :) I'm definitely sure we have at least 10 > users; beyond that I can only speculate; Maybe 2 to the power of ten > or thirteen... Only 10?? Judging from mailing list membership, I'd say at least 25 or 30, just on the forums alone. I'm assuming that people here aren't subscribed just for kicks, they actually write D code. There are probably more outside the forums (somebody mentioned an entire company of D programmers before, perhaps about 50-100? I don't remember the exact figure). There's got to be more out there, given that Andrei has been giving talks about D for a while. *Somebody* in the audience must be actually listening to what he says. But in any case, I'd say we have a ways to go yet in terms of D adoption. [...] > Anyways, focus on the now. D3 may/will come some day, but that's a > long ways off. Course if you plan early for certain things that will > change it does make going towards it easier with language design, or > give you more time to think about faults and fixes. Yep. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
Re: Does D have too many features?
On Thursday, 3 May 2012 at 22:29:47 UTC, H. S. Teoh wrote: On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote: Do we know (roughly) how many D users are out there right now? Don't know. Need a poll :) I'm definitely sure we have at least 10 users; beyond that I can only speculate; Maybe 2 to the power of ten or thirteen... There aren't any flying cars in Hollywood either. They're either just artist's concepts (*cough*CGI models*cough*), held up by strings, or just superimposed on an animated background. Exactly! It's on the 'big screen', meaning smoke and gimmicks, the same as magicians. Anyways, focus on the now. D3 may/will come some day, but that's a long ways off. Course if you plan early for certain things that will change it does make going towards it easier with language design, or give you more time to think about faults and fixes.
Re: Does D have too many features?
On 5/3/2012 8:13 AM, Don Clugston wrote: Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. It's there simply because all the Standard C headers should be represented. It should not get anything that is not in Standard C. Ditto for all the other stuff in core.stdc. It's there to make converting C code to D code easier. Practically everything in there has a better implementation in std.math. Yup. But also note that the only "implementations" in there are things that are done as macros in C's math.h, meaning they're trivial.
Re: Does D have too many features?
On Thu, May 03, 2012 at 11:32:52PM +0200, Era Scarecrow wrote: [[...] > If anything, I would consider D3 an ideal, something to work > towards. And no it wouldn't be started or really worked on for at > 10-15 years after D's mature and at Andrei's goal of having at least > a million users. And as stated before, if there [b]IS[/b] going to > be a D3 at any point it should have no problem calling D2 code. Do we know (roughly) how many D users are out there right now? > Course thinking of D3 now is kinda like thinking of flying cars and > how you want a flying car and you won't buy a car today until it can > fly... Back (in the 50-60's was it?) they thought we would be > having a flying car for every family and had these really badly done > animations of what they expected to see. I don't see any flying cars > outside of Hollywood. Best if we stick in the present and deal with > our problems now. There aren't any flying cars in Hollywood either. They're either just artist's concepts (*cough*CGI models*cough*), held up by strings, or just superimposed on an animated background. T -- It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford
Re: Does D have too many features?
On Thursday, 3 May 2012 at 20:36:47 UTC, Jonathan M Davis wrote: On Thursday, May 03, 2012 15:30:40 Don Clugston wrote: What is this D3 thing As far as I can tell, 'D3' was invented by newcomers to the forums. I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing. I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet. If anything, I would consider D3 an ideal, something to work towards. And no it wouldn't be started or really worked on for at 10-15 years after D's mature and at Andrei's goal of having at least a million users. And as stated before, if there [b]IS[/b] going to be a D3 at any point it should have no problem calling D2 code. Course thinking of D3 now is kinda like thinking of flying cars and how you want a flying car and you won't buy a car today until it can fly... Back (in the 50-60's was it?) they thought we would be having a flying car for every family and had these really badly done animations of what they expected to see. I don't see any flying cars outside of Hollywood. Best if we stick in the present and deal with our problems now.
Re: Does D have too many features?
Le 03/05/2012 22:43, Sean Kelly a écrit : On May 3, 2012, at 1:11 PM, Don wrote: On 03.05.2012 21:08, Sean Kelly wrote: On May 3, 2012, at 8:13 AM, Don Clugston wrote: On 03/05/12 16:13, Andrei Alexandrescu wrote: Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math. core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface. It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro. If there is anything nonstandard in there, I'm not aware of it. Yes, but why do we have it? We're not C. Mostly because it was handy to fall back on the C API before Phobos was so well fleshed-out. Today, I think it mostly exists to ease porting of C apps. So they probably belongs to deimos.
Re: Does D have too many features?
On Thursday, May 03, 2012 13:43:11 Sean Kelly wrote: > On May 3, 2012, at 1:11 PM, Don wrote: > > On 03.05.2012 21:08, Sean Kelly wrote: > >> On May 3, 2012, at 8:13 AM, Don Clugston wrote: > >>> On 03/05/12 16:13, Andrei Alexandrescu wrote: > Good ones. In fact I even discounted them from this discussion because > I'd already considered them gone. Walter agreed that I don't mention > them in TDPL, with the intent to have them peter out. > > One good step right now would be to remove NCEG operators from the > online documentation. Later on, we'll consider them an accept-invalid > bug :o). > >>> > >>> Well, they are also used in druntime, in core.stdc.math > >>> > >>> BTW I *hate* that module, I don't know why it exists. Even worse, it > >>> seems to be growing -- people are adding more things to it. Practically > >>> everything in there has a better implementation in std.math.>> > >> core.stdc.math corresponds to C99's math.h and is there as a part of the > >> standard C interface. It should only contain the required C99 > >> prototypes, and in some cases functions if the C implementation is a > >> macro. If there is anything nonstandard in there, I'm not aware of it.> > > Yes, but why do we have it? We're not C. > > Mostly because it was handy to fall back on the C API before Phobos was so > well fleshed-out. Today, I think it mostly exists to ease porting of C > apps. In principle, having prototypes for the entire standard C library in druntime seems like a good idea to me. In practice though, it could cause problems due to people using the C functions rather than the D functions for some things (e.g. the math functions). If we properly documented them all though, we could then put comments about the correct D function to use to replace each C function which has a D replacement, and then it could actually help people move away from the C functions. - Jonathan M Davis
Re: Does D have too many features?
On May 3, 2012, at 1:11 PM, Don wrote: > On 03.05.2012 21:08, Sean Kelly wrote: >> On May 3, 2012, at 8:13 AM, Don Clugston wrote: >> >>> On 03/05/12 16:13, Andrei Alexandrescu wrote: Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). >>> >>> Well, they are also used in druntime, in core.stdc.math >>> >>> BTW I *hate* that module, I don't know why it exists. Even worse, it seems >>> to be growing -- people are adding more things to it. >>> Practically everything in there has a better implementation in std.math. >> >> core.stdc.math corresponds to C99's math.h and is there as a part of the >> standard C interface. It should only contain the required C99 prototypes, >> and in some cases functions if the C implementation is a macro. If there is >> anything nonstandard in there, I'm not aware of it. > > Yes, but why do we have it? We're not C. Mostly because it was handy to fall back on the C API before Phobos was so well fleshed-out. Today, I think it mostly exists to ease porting of C apps.
Re: Does D have too many features?
On Thursday, May 03, 2012 15:30:40 Don Clugston wrote: > What is this D3 thing > As far as I can tell, 'D3' was invented by newcomers to the forums. I think that what it comes down to is that there are a variety of people who want features added or changed in D which are either not going to happen anytime soon or will never happen in D2 (especially if they're major breaking changes). So, they figure/hope that we'll have a new revision of the language where we'll be able to make breaking changes and then maybe the changes that they want will make it in then. After all, particularly from the perspective of a newbie, we already had D2 which changed a bunch of stuff from D1, why wouldn't we have D3 later on? And for folks who really want to see changes that aren't going to happen, the idea that we're going to have another major revision of the language which might make the changes that they want sounds really appealing. I think that Walter and Andrei have made it fairly clear when they've said anything on the subject that there is no intention to make any kind of D3 anytime soon and that if we do, it'll be years from now after D2 is mature and well-established, and it actually makes sense to do a new major revision. But I do think that you're right in that the very idea of a D3 was created by folks in the newsgroup. Walter and the other developers have been focusing on stabilizing D2 as _the_ version of the language, not finishing it up so that they can move onto D3. And the misconceptions about D1 that you've pointed out in the past probably just help contribute to the idea that we'll have a D3 at some point. Maybe we will, maybe we won't, but there's no point in worrying about it for years yet. - Jonathan M Davis
Re: Does D have too many features?
On 03.05.2012 21:08, Sean Kelly wrote: On May 3, 2012, at 8:13 AM, Don Clugston wrote: On 03/05/12 16:13, Andrei Alexandrescu wrote: Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math. core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface. It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro. If there is anything nonstandard in there, I'm not aware of it. Yes, but why do we have it? We're not C. Some of the std C functions aren't implemented correctly (especially the FreeBSD long double functions, which are completely wrong). And that shouldn't be D's problem. Even when they are, they're not pure nothrow, and sometimes they have really silly names (I'm looking at you, tgamma() ) Quite absurdly, the DMC gamma function is a port from the D version. Why include it twice??
Re: Does D have too many features?
On May 3, 2012, at 9:58 AM, Alex Rønne Petersen wrote: > On 03-05-2012 17:13, Don Clugston wrote: >> >> >> Well, they are also used in druntime, in core.stdc.math >> >> BTW I *hate* that module, I don't know why it exists. Even worse, it >> seems to be growing -- people are adding more things to it. >> Practically everything in there has a better implementation in std.math. > > But not quite everything yet. When I tried to pure/nothrow/@safe-ify > std.math[special], I eventually stumbled upon code that used core.stdc.math. > > It would definitely be nice if we could completely kill any dependency on > that module, so we can actually make proper use of pure/nothrow/@safe, etc. I've always thought use of core.stdc as an indicator for things that should be added to Phobos. Really, core.stdc should only be used by apps ported from C to D, not by apps written from scratch in D.
Re: Does D have too many features?
On May 3, 2012, at 8:13 AM, Don Clugston wrote: > On 03/05/12 16:13, Andrei Alexandrescu wrote: >> >> >> Good ones. In fact I even discounted them from this discussion because >> I'd already considered them gone. Walter agreed that I don't mention >> them in TDPL, with the intent to have them peter out. >> >> One good step right now would be to remove NCEG operators from the >> online documentation. Later on, we'll consider them an accept-invalid >> bug :o). > > Well, they are also used in druntime, in core.stdc.math > > BTW I *hate* that module, I don't know why it exists. Even worse, it seems to > be growing -- people are adding more things to it. > Practically everything in there has a better implementation in std.math. core.stdc.math corresponds to C99's math.h and is there as a part of the standard C interface. It should only contain the required C99 prototypes, and in some cases functions if the C implementation is a macro. If there is anything nonstandard in there, I'm not aware of it.
Re: Does D have too many features?
On 03-05-2012 17:13, Don Clugston wrote: On 03/05/12 16:13, Andrei Alexandrescu wrote: On 5/3/12 9:55 AM, Don Clugston wrote: On 28/04/12 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? Other ones which were agreed to a long time ago were: * NCEG operators * built-in .sort and .reverse Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math. But not quite everything yet. When I tried to pure/nothrow/@safe-ify std.math[special], I eventually stumbled upon code that used core.stdc.math. It would definitely be nice if we could completely kill any dependency on that module, so we can actually make proper use of pure/nothrow/@safe, etc. -- - Alex
Re: Does D have too many features?
On 03/05/12 16:13, Andrei Alexandrescu wrote: On 5/3/12 9:55 AM, Don Clugston wrote: On 28/04/12 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? Other ones which were agreed to a long time ago were: * NCEG operators * built-in .sort and .reverse Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Well, they are also used in druntime, in core.stdc.math BTW I *hate* that module, I don't know why it exists. Even worse, it seems to be growing -- people are adding more things to it. Practically everything in there has a better implementation in std.math.
Re: Does D have too many features?
On 5/3/12 9:55 AM, Don Clugston wrote: On 28/04/12 20:47, Walter Bright wrote: Andrei and I had a fun discussion last night about this question. The idea was which features in D are redundant and/or do not add significant value? A couple already agreed upon ones are typedef and the cfloat, cdouble and creal types. What's your list? Other ones which were agreed to a long time ago were: * NCEG operators * built-in .sort and .reverse Good ones. In fact I even discounted them from this discussion because I'd already considered them gone. Walter agreed that I don't mention them in TDPL, with the intent to have them peter out. One good step right now would be to remove NCEG operators from the online documentation. Later on, we'll consider them an accept-invalid bug :o). Andrei
Re: Does D have too many features?
On 28/04/12 20:47, Walter Bright wrote:
Andrei and I had a fun discussion last night about this question. The
idea was which features in D are redundant and/or do not add significant
value?
A couple already agreed upon ones are typedef and the cfloat, cdouble
and creal types.
What's your list?
Other ones which were agreed to a long time ago were:
* NCEG operators
* built-in .sort and .reverse
=
About the NCEG operators -- the reason they're redundant is that you
practically always want to treat NaN separately.
I've tried _very_ hard to come up with uses for them, but without success.
The thing I've used the most is:
x !<>= x
which is a kind of built-in isNaN(x), but that can also be rewritten as:
x != x
Initially I though you'd do things like
real func(real x)
{
// x must be non-NaN and in the range -x.infinity .. N
if (x !< N)
return real.nan;
but even that isn't convincing, because if x is NaN you should be
returning x, so that you preserve NaN payloads.
I think I have used these guys more than anyone else, but I still
haven't found a single use case that stands up to scrutiny.
Re: Does D have too many features?
On 01/05/12 00:33, Timon Gehr wrote: On 04/30/2012 11:28 PM, bearophile wrote: Walter: The first thing to emphasize is that NONE of this will happen for D2. The emphasis on D2 is fixing implementation and toolchain issues. Breaking existing code is off the table unless we are pretty much forced to in order to fix some other more important issue. But you need to keep into account that D2 is still a not widely used language. So deprecating some things now will cause far less troubles than doing it in D3 some years from now. D2 -> D3 will be full of breaking changes anyway. Otherwise there is no reason to add another major language version. What is this D3 thing As far as I can tell, 'D3' was invented by newcomers to the forums.
Re: Does D have too many features?
It's hard to grep for (since with is
used in comments quite often),
Try to search for "with(" or "with\s(", that are less common
in normal text.
There is no tool (maybe the compiler could provide such a tool)
to remove all comments?
That way, you could do:
cat file.d | tool | grep whatever
Re: Does D have too many features?
On 05/02/2012 05:25 PM, Andrei Alexandrescu wrote:
On 5/2/12 10:20 AM, Timon Gehr wrote:
The interface is different:
void main(){
int[] a = [0,0,0];
a[2] = 3;
assert(2 !in a);
}
vs.
void main(){
int[int] aa;
aa[2] = 3;
assert(2 in aa);
}
The syntactic interface is the same.
Encapsulation of complexity is a problem if it is not obvious to the
programmer. I am not sure it can even be called such if the semantics is
different.
That would be the semantic interface, which makes the idea twice as bad.
Andrei
I tend to agree, but I think that the two points are mutually exclusive.
Re: Does D have too many features?
On 5/2/12 10:20 AM, Timon Gehr wrote:
The interface is different:
void main(){
int[] a = [0,0,0];
a[2] = 3;
assert(2 !in a);
}
vs.
void main(){
int[int] aa;
aa[2] = 3;
assert(2 in aa);
}
The syntactic interface is the same. That would be the semantic
interface, which makes the idea twice as bad.
Andrei
Re: Does D have too many features?
On 05/02/2012 04:01 PM, Andrei Alexandrescu wrote:
On 5/2/12 6:15 AM, Tobias Pankrath wrote:
No, it is not an O(1) operation, it is *close* to O(1) (as much sense
as that statement can make). I don't know why you associate any
particular complexity with 'in' in the first place. And I do think
we're crippling the language, considering Python (and probably other
languages) has had this feature since forever.
I'm seriously worried. It seems to me like we're trying to cater to
people who can't reason about the types in their program and the
complexities of performing various operations on them. Since when did
algorithmic complexity become a reason to take away syntax sugar?
+1
I do argee. opIn is handy for arrays, too. That the complexity would be
linear and thus it should be disallowed is not a valid argument in my
opinion, because with the exact same argument you could kick
std.algorithm.find out of phobos. It is just obvious to every trained
programmer that finding an element in an unordered list takes O(n).
The problem here is making complexity an implementation detail of a
uniform interface (e.g. over hashes and linear containers). That is fail.
Andrei
The interface is different:
void main(){
int[] a = [0,0,0];
a[2] = 3;
assert(2 !in a);
}
vs.
void main(){
int[int] aa;
aa[2] = 3;
assert(2 in aa);
}
Re: Does D have too many features?
On 5/2/12 7:52 AM, bearophile wrote: Andrei Alexandrescu: FWIW there is little agreement among answers. Right, but a thread like this is comparable to the first phase of a Brainstorming process, where ideas are produced freely, where agreement is not required. Sorry, here I meant "agreement" in the statistical sense, i.e. there's not a lot of clear collection of features we should remove; for most features that some wanted to get rid of, others had gainful uses. Andrei
Re: Does D have too many features?
On 5/2/12 6:15 AM, Tobias Pankrath wrote: No, it is not an O(1) operation, it is *close* to O(1) (as much sense as that statement can make). I don't know why you associate any particular complexity with 'in' in the first place. And I do think we're crippling the language, considering Python (and probably other languages) has had this feature since forever. I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar? +1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n). The problem here is making complexity an implementation detail of a uniform interface (e.g. over hashes and linear containers). That is fail. Andrei
Re: Does D have too many features?
On 5/2/12 12:20 AM, Jakob Ovrum wrote:
S(...) does not exhibit the same problem as {...} exactly because it has
constructors and static opCall. If you change the order of fields in S,
you can write a constructor preserving the old behaviour.
Good observation. So indeed the { ... } case is inferior because there's
no reasonable way for the library writer to defend against.
Andrei
Re: Does D have too many features?
On 5/1/12 11:38 PM, Adam D. Ruppe wrote:
On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu wrote:
One feature to remove stands out - the struct initialization:
S s = { 1, 2 };
I could live without that one, because D has an alternative:
auto s = S(1, 2);
And I'd be sad if you took that out, as I use it a lot, especially
for trivial types:
struct Html { string src; }
struct Text { string src; }
struct Point { int x; int y; }
struct Size { int width; int height; }
which I like because then we can use the types for overloading,
static checks, etc., and it is very very simple to drop in and
use.
I guess there could be opCalls or constructors, but poo, it
works now without that and I like it.
Well, so probably we shouldn't remove that feature either :o).
Andrei
Re: Does D have too many features?
Andrei Alexandrescu:
It's a bit inappropriate to bind Walter to such a social
contract upon having asked an informal question.
Those comments weren't required, but they improve the quality of
this community. So it's work and time well spent. Every person
attracted to work on D development is a chance to increase
significantly the development speed.
FWIW there is little agreement among answers.
Right, but a thread like this is comparable to the first phase of
a Brainstorming process, where ideas are produced freely, where
agreement is not required.
Later there is a phase of selection, that needs to be based on
the quality of the single ideas; because technology/science
decisions can't be based (too much) on popularity.
Eliminating today's semantics of comma inevitably underlies the
hope that it can be retrofitted for something else, which I
think is near impossible without changing semantics of working
code.
Removing/restricting the usage of the comma operator is probably
able to avoid some bugs (and increase syntax uniformity in D code
written by different programmers), so it has a usefulness even if
later they are not used for tuple syntax. How much important such
bugs are, is a judgement.
One feature to remove stands out - the struct initialization:
struct S { int x, y; }
S s = { 1, 2 };
This, was noted, makes the order of members effectively part of
the struct's interface, which is subtly dangerous. I think we
should remove this feature.
It's a partially redundant feature, and it's able to introduce
some long-term rigidity in the code. On the other hand when you
have to write many struct literals, nested inside other literals
of different structs, repeating the names introduces a bit of
extra redundant code.
Thank you for the answers,
bye,
bearophile
Re: Does D have too many features?
No, it is not an O(1) operation, it is *close* to O(1) (as much sense as that statement can make). I don't know why you associate any particular complexity with 'in' in the first place. And I do think we're crippling the language, considering Python (and probably other languages) has had this feature since forever. I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar? +1 I do argee. opIn is handy for arrays, too. That the complexity would be linear and thus it should be disallowed is not a valid argument in my opinion, because with the exact same argument you could kick std.algorithm.find out of phobos. It is just obvious to every trained programmer that finding an element in an unordered list takes O(n).
Re: Does D have too many features?
On Tuesday, 1 May 2012 at 21:03:35 UTC, foobar wrote: vote++ I like your POV that operators are useful shortcuts (syntax sugar) meant for the end user whereas library authors should use the full function names for generic code. IIRC C++'s STL does the same - for instance the map::operator[] is a simple wrapper around map's functions. Is this included in D's style guide? vote- If something is a bad idea for a library, I don't see why it could be a good idea for the user code. After all, the standard library IS user code. The fact that it's in a library or not doesn't change anything to the fact that your syntactic sugar is hiding a potential problem.
Re: Does D have too many features?
On Wednesday, 2 May 2012 at 05:25:40 UTC, Andrej Mitrovic wrote:
On 5/2/12, Andrei Alexandrescu
wrote:
struct S { int x, y; }
S s = { 1, 2 };
I think we should remove
this feature.
But not this, right:
S s = { x : 1, y : 2 }; ?
Yes, these are named parameters.
Andrei's point could be made for just about everything that takes
two (or more) consecutive integers, like a function signature, so
I think it's a bit moot. Unfortunately, only named parameters can
solve this problem, but then comes the problem of accepting both
order of parameters and named parameters at the same time...
Re: Does D have too many features?
On Wednesday, May 02, 2012 07:17:20 Maxim Fomin wrote:
> On Wednesday, 2 May 2012 at 03:38:41 UTC, Adam D. Ruppe wrote:
> > On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu
> >
> > wrote:
> >> One feature to remove stands out - the struct initialization:
> >> S s = { 1, 2 };
> >
> > I could live without that one, because D has an alternative:
> >
> > auto s = S(1, 2);
>
> It has the same problem as the first one: members are part of the
> interface and a new one: struct literals are impossible if opCall
> is defined (if I am not mistaken).
Yes, members are part of the interface, but if {1, 2} isn't legal, then their
order isn't part of the interface as far as constructing the object is
concerned (the memory layout is, so low-level stuff could still be broken by
swapping or adding member variables, but the construction doesn't have to stop
working like it does with a C struct literal).
And defining opCall shouldn't have any effect on S(1, 2). S(1, 2) is clearly
calling the constructor. The only reason that you would have a conflict is if
you also defined a static opCall which conflicted. If a non-static opCall has
_any_ effect on S(1, 2), then it's a bug.
- Jonathan M Davis
Re: Does D have too many features?
On 5/2/12, Andrei Alexandrescu wrote:
> struct S { int x, y; }
> S s = { 1, 2 };
>
> I think we should remove
> this feature.
But not this, right:
S s = { x : 1, y : 2 }; ?
Re: Does D have too many features?
On Wednesday, 2 May 2012 at 03:38:41 UTC, Adam D. Ruppe wrote:
On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu
wrote:
One feature to remove stands out - the struct initialization:
S s = { 1, 2 };
I could live without that one, because D has an alternative:
auto s = S(1, 2);
It has the same problem as the first one: members are part of the
interface and a new one: struct literals are impossible if opCall
is defined (if I am not mistaken).
Re: Does D have too many features?
On Wednesday, 2 May 2012 at 03:38:41 UTC, Adam D. Ruppe wrote:
On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu
wrote:
One feature to remove stands out - the struct initialization:
S s = { 1, 2 };
I could live without that one, because D has an alternative:
auto s = S(1, 2);
And I'd be sad if you took that out, as I use it a lot,
especially
for trivial types:
struct Html { string src; }
struct Text { string src; }
struct Point { int x; int y; }
struct Size { int width; int height; }
which I like because then we can use the types for overloading,
static checks, etc., and it is very very simple to drop in and
use.
I guess there could be opCalls or constructors, but poo, it
works now without that and I like it.
S(...) does not exhibit the same problem as {...} exactly because
it has constructors and static opCall. If you change the order of
fields in S, you can write a constructor preserving the old
behaviour.
Re: Does D have too many features?
On Wednesday, 2 May 2012 at 03:22:02 UTC, Andrei Alexandrescu
wrote:
One feature to remove stands out - the struct initialization:
S s = { 1, 2 };
I could live without that one, because D has an alternative:
auto s = S(1, 2);
And I'd be sad if you took that out, as I use it a lot, especially
for trivial types:
struct Html { string src; }
struct Text { string src; }
struct Point { int x; int y; }
struct Size { int width; int height; }
which I like because then we can use the types for overloading,
static checks, etc., and it is very very simple to drop in and
use.
I guess there could be opCalls or constructors, but poo, it
works now without that and I like it.
Re: Does D have too many features?
On 4/30/12 5:15 AM, bearophile wrote:
Jonathan M Davis:
Honestly, I don't think that you _can_ take much from this thread
other than
I don't agree, I see some recurring patterns.
People have spent energy and time to write lot of answers in this
thread, some good answer bits too, so I expect such work to not let be
fully wasted. Asking for opinions, receiving lot of them, and then
ignoring them all is not a good way to run a community.
It's a bit inappropriate to bind Walter to such a social contract upon
having asked an informal question. Besides, if we're talking about work
of writing posts we should also consider the considerable work of
reading certain posts, which are so patronizing as to make reading an
exercise in eye rolling.
And thank you for your answer, I always appreciate your answers, but you
aren't Walter, that post was for him (and Andrei) to answer :-)
FWIW there is little agreement among answers. Eliminating today's
semantics of comma inevitably underlies the hope that it can be
retrofitted for something else, which I think is near impossible without
changing semantics of working code. Then there's a lot of busywork.
Eliminating e.g. "with" is going to leave things pretty much where they
are with the note some innocently bystanding programs are going to break.
One feature to remove stands out - the struct initialization:
struct S { int x, y; }
S s = { 1, 2 };
This, was noted, makes the order of members effectively part of the
struct's interface, which is subtly dangerous. I think we should remove
this feature.
Andrei
Re: Does D have too many features?
On Tuesday, 1 May 2012 at 17:50:38 UTC, Alex Rønne Petersen wrote: On 01-05-2012 19:09, Jonathan M Davis wrote: On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote: 1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? If in is not restricted to a particular level Big-O complexity, then you cannot safely use it in generic code. That's why all of the functions in std.container give their Big-O complexity. I don't think 'in' is actually used in any generic code (other than code specifically written for AAs, in which it *does* have a specific complexity in any case). I know I wouldn't use 'in' in truly generic code in any case, exactly because it has no defined complexity (even today; it's overloadable just like most other binary operators). In C++ [] is supposed to be O(log n) at worst. I would expect it to be the same in D, and since in is doing essentially the same operation, I would expect it to have the same Big-O complexity. This is a good point, but not one I would subscribe to; it only holds true if you consider 'in' to be an operation purely limited to AAs. But this is already not the case given that it can be overloaded. So, I don't think that it having different complexity for arrays is a big deal. Personally, I consider 'in' to be syntax sugar for the language user. To me, it does not seem like a feature that a library of generic algorithms should be using at all. No, nothing is stopping a programmer from giving it horrible complexity, but the standard library and language should _definitely_ stick to O(log n) worst case for in and []. It would be a disaster for generic algorithms if in worked on normal arrays, because it would not be possible to maintain the required Big-O complexity. I agree that any overload of [] and 'in' that Phobos does should stick to that constraint when possible (I say when possible, because sometimes innovative uses of these operators can't stick to this rather strict and mundane constraint; consider for example interaction with a database or what do I know...). But again, I don't think 'in' is something a generic algorithm should be using. We have the functions in std.algorithm and std.container if we need to write generic code. Also, I don't think language design should be *too* biased by the standard library's preferences. Not everyone agrees with Phobos conventions and we have to respect that IMHO. Just because it's a standard library doesn't mean that it should dictate users of the language who don't use the standard library. - Jonathan M Davis vote++ I like your POV that operators are useful shortcuts (syntax sugar) meant for the end user whereas library authors should use the full function names for generic code. IIRC C++'s STL does the same - for instance the map::operator[] is a simple wrapper around map's functions. Is this included in D's style guide?
Re: Does D have too many features?
On 01-05-2012 19:09, Jonathan M Davis wrote: On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote: 1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? If in is not restricted to a particular level Big-O complexity, then you cannot safely use it in generic code. That's why all of the functions in std.container give their Big-O complexity. I don't think 'in' is actually used in any generic code (other than code specifically written for AAs, in which it *does* have a specific complexity in any case). I know I wouldn't use 'in' in truly generic code in any case, exactly because it has no defined complexity (even today; it's overloadable just like most other binary operators). In C++ [] is supposed to be O(log n) at worst. I would expect it to be the same in D, and since in is doing essentially the same operation, I would expect it to have the same Big-O complexity. This is a good point, but not one I would subscribe to; it only holds true if you consider 'in' to be an operation purely limited to AAs. But this is already not the case given that it can be overloaded. So, I don't think that it having different complexity for arrays is a big deal. Personally, I consider 'in' to be syntax sugar for the language user. To me, it does not seem like a feature that a library of generic algorithms should be using at all. No, nothing is stopping a programmer from giving it horrible complexity, but the standard library and language should _definitely_ stick to O(log n) worst case for in and []. It would be a disaster for generic algorithms if in worked on normal arrays, because it would not be possible to maintain the required Big-O complexity. I agree that any overload of [] and 'in' that Phobos does should stick to that constraint when possible (I say when possible, because sometimes innovative uses of these operators can't stick to this rather strict and mundane constraint; consider for example interaction with a database or what do I know...). But again, I don't think 'in' is something a generic algorithm should be using. We have the functions in std.algorithm and std.container if we need to write generic code. Also, I don't think language design should be *too* biased by the standard library's preferences. Not everyone agrees with Phobos conventions and we have to respect that IMHO. Just because it's a standard library doesn't mean that it should dictate users of the language who don't use the standard library. - Jonathan M Davis -- - Alex
Re: Does D have too many features?
On Tuesday, 1 May 2012 at 14:41:43 UTC, SomeDude wrote: On Tuesday, 1 May 2012 at 14:31:25 UTC, Alex Rønne Petersen wrote: 1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? It's not crippling the language. Nothing prevents you from writing a loop. Or using a library find function that does the same thing. But the name "find" gives you a hint that it's not magical and that it has a cost, while with "if( foo in bar)", it is too easy to forget that we are actually potentially performing an O(n) operation. In an AA, the 'in' keyword performs a O(1) operation, so that's ok to use it as a syntactic sugar. I remember this was the argument Andrei also came up. Still can't make any sense out of it. If someone have some detailed reference please share! If you have it just for a niche usage, why do you have it at all? With UFCS "bar.contains(foo)" precise enough. You can make same argument for every operator in any language if you have operator overloading. And it would be against operator overloading, not particularly "in". -- Didn't know "http://forum.dlang.org/"; adopted that unreadable/annoying to no end captchas.
Re: Does D have too many features?
On Tuesday, May 01, 2012 16:31:25 Alex Rønne Petersen wrote: > 1) So because some people might use a feature incorrectly due to lack of > knowledge in algorithms and data structures, we should cripple the language? If in is not restricted to a particular level Big-O complexity, then you cannot safely use it in generic code. That's why all of the functions in std.container give their Big-O complexity. In C++ [] is supposed to be O(log n) at worst. I would expect it to be the same in D, and since in is doing essentially the same operation, I would expect it to have the same Big-O complexity. No, nothing is stopping a programmer from giving it horrible complexity, but the standard library and language should _definitely_ stick to O(log n) worst case for in and []. It would be a disaster for generic algorithms if in worked on normal arrays, because it would not be possible to maintain the required Big-O complexity. - Jonathan M Davis
Re: Does D have too many features?
On 01-05-2012 16:41, SomeDude wrote: On Tuesday, 1 May 2012 at 14:31:25 UTC, Alex Rønne Petersen wrote: 1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? It's not crippling the language. Nothing prevents you from writing a loop. Or using a library find function that does the same thing. But the name "find" gives you a hint that it's not magical and that it has a cost, while with "if( foo in bar)", it is too easy to forget that we are actually potentially performing an O(n) operation. In an AA, the 'in' keyword performs a O(1) operation, so that's ok to use it as a syntactic sugar. No, it is not an O(1) operation, it is *close* to O(1) (as much sense as that statement can make). I don't know why you associate any particular complexity with 'in' in the first place. And I do think we're crippling the language, considering Python (and probably other languages) has had this feature since forever. I'm seriously worried. It seems to me like we're trying to cater to people who can't reason about the types in their program and the complexities of performing various operations on them. Since when did algorithmic complexity become a reason to take away syntax sugar? -- - Alex
Re: Does D have too many features?
On Tuesday, 1 May 2012 at 14:31:25 UTC, Alex Rønne Petersen wrote: 1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? It's not crippling the language. Nothing prevents you from writing a loop. Or using a library find function that does the same thing. But the name "find" gives you a hint that it's not magical and that it has a cost, while with "if( foo in bar)", it is too easy to forget that we are actually potentially performing an O(n) operation. In an AA, the 'in' keyword performs a O(1) operation, so that's ok to use it as a syntactic sugar.
Re: Does D have too many features?
On 01-05-2012 06:44, SomeDude wrote: On Tuesday, 1 May 2012 at 02:26:53 UTC, Alex Rønne Petersen wrote: On 01-05-2012 03:41, Jesse Phillips wrote: Complexity of the operation. in on an array is not nearly the same as with an associative array. I know, but it's very intuitive still; see Python. And that's why it's somewhat dangerous. Because it's so easy to use, someone that doesn't pay enough attention may overlook the fact that he is not using the right data structure. If he often has to do that more than once, he is using the wrong tool for the job. I agree it would be syntaxically nice, but I worry giving this syntactic sugar for what's a for loop with lots of comparisons isn't such a good idea. And the comparisons themselves are subject to caution. If for instance it's an array of floats, or some custom objects, it's very unlikely that you are going to compare bit by bit. So basically, this would be useful only for integers and chars. 1) So because some people might use a feature incorrectly due to lack of knowledge in algorithms and data structures, we should cripple the language? 2) The same holds true for AAs keyed by floats. -- - Alex
Re: Does D have too many features?
On 2012-05-01 16:28, Alex Rønne Petersen wrote: It *can*, but it's annoying on non-US keyboards, which was my original point. Well, I don't agree. -- /Jacob Carlborg
Re: Does D have too many features?
On 01-05-2012 13:22, Jacob Carlborg wrote: On 2012-04-30 22:03, Alex Rønne Petersen wrote: On 30-04-2012 21:42, Jacob Carlborg wrote: When is r"" a better use than ``? We already have the regular "". You don't have escape sequences inside r"", so they can be useful if you have backslashes in your string. `` can be used for that. ` is good because it's a different delimiter compared to r"" or "". It *can*, but it's annoying on non-US keyboards, which was my original point. -- - Alex
