The D Programming Language
in [C++]
|
From: Francis Glassborow on 23 Nov 2006 10:34 In article <1164234032.921657.260240(a)m73g2000cwd.googlegroups.com>, James Kanze <james.kanze(a)gmail.com> writes >I let that statement go, since Walter didn't bother to define >"more powerful", and without that definition, the statement is >meaningless. The obvious meaning is obviously not what he >meant. I know of libraries which can manage a GUI or an HTML >connection---now that's real power, and I've never seen anything >like that in a language. Well I have a candidate language: Forth. I am not going to go into details here but I certainly implemented not only user defined semantics but user defined syntax in Forth. Of course and Threaded Interpreted Language is going to be very different to the common mainstream languages but TILs are very powerful beasts. -- Francis Glassborow ACCU Author of 'You Can Do It!' and "You Can Program in C++" see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 23 Nov 2006 13:14 Walter Bright <walter(a)digitalmars-nospamm.com> writes: > Gabriel Dos Reis wrote: >> So, the question is: Can there be better library implementations, or >> can the core language be extended to allow better library >> implementation? (e.g. allow for literal of user-defined types), >> or do you think that there are *intrinsinc* reasons why they must be >> core languages? If yes, could you elaborate on those logical, >> intrinsinc, reasons? > > A compiler will always be more powerful than what's possible with the > library, for the intrinsic reason that one can code the compiler to do > whatever one wants to. With a library, you're stuck with what the > compiler chooses to make available. I think that's pretty obvious, since > there are no examples of languages where libraries are as powerful as > the compiler. FORTH. And no, I'm not kidding. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 23 Nov 2006 13:14 Walter Bright <walter(a)digitalmars-nospamm.com> writes: > James Kanze wrote: >> But the argument that C++ doesn't have a string type is false. >> It does. > > I didn't argue C++ didn't have a string type. I argued that: > > 1) library features are not part of the core language. > > 2) C++ (and D) do not have good enough core features to be able to > create a library string (and vector, complex and associative arrays) > that are good enough to compete with core support for such. That, I buy. However... > 3) String, complex, vector and associative arrays are ubiquitous enough > that the extra goodies one can get with a core feature make them > worthwhile to put in the core language. .....what does "put it in the core language" really mean? If you look at Python, for example, the only part of string, list, and dict that is truly and irremedially "in the core language" is the syntax for literals. The rest could, in principle, be written in Python. Of course, you'd need strings, lists, and dicts of some kind to do that, but then Python doesn't have the low-level facilities of a systems programming language, which would allow us to write those parts. D doesn't have that limitation. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: David Abrahams on 23 Nov 2006 13:16 Gabriel Dos Reis <gdr(a)integrable-solutions.net> writes: > | I know that D, at least, will not have user > | defined tokens, for the reason that such would blow the legs off of > | third party tools that process source without needing to be full blown > | compilers. > > That is more a problem with D's design philosophy than an intrinsically > linguistic issue. Or a feature. It definitely could be seen as a problematic consequence of C++'s design philosophy that third party tools for C++ are in short supply, and many of those that do exist still don't have legs. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Terry G on 23 Nov 2006 13:22
> Assuming the underlying hardware doesn't define such behaviour, the > compiler would have to generate a code like this for (X << Y): > > if (Y < 0) > evaluate X >> Y instead > else if (Y >= bit_sizeof(X)) > if (X < 0) > return -1 > else > return 0 > else > evaluate X << Y > > Not all programs need/can afford this overhead. When the input is known > to be in a certain range, the program can skip the check. Otherwise, the > program can do the check itself. This is the merit that leaving some > corner cases undefined gives. First, let me apologize for that post. Yes, I was only thinking of signed-right shift. Reading my post, I could barely discern that. Sorry. Doesn't most hardware reasonably define these operations, so that the runtime impact isn't quite so severe? That's not rhetorical. I don't know. Hardware should behave better too. One should expect to (possibly) give up performance in favor of defined behavior when using shift with signed types. If shift were only defined for unsigned and implicit conversion from unsigned to signed were defined better, then life would be easier (for me). In my experience, the right hand operator (the shift value, Y) is typically constant anyway. So the compiler can generate fast, well-defined code. If X and Y are unsigned, then things are better too. return (Y < BitSizeof(X) ? (X<<Y) : 0; I suppose compilers today can keep track of the possible range of expressions, so the compiler may be able to infer that Y < BitSize(X) and avoid the runtime check. Not all projects can afford this undefined behavior. Most C++ programmers have never read the standard. They just expect reasonable looking code that compiles to work. Its sad, but its reality. So undefined behavior is desirable for performance reasons? This requires the programmer to know more. That is exactly why Java is so palatable. It lets me be lazy. Java forces the hardware to behave "normally". And in most cases, I don't really care about performance, because I can demonstrate to the bosses with benchmarks and charts that we NEED a better/faster processor. I don't get blamed, the hardware does. This puts more emphasis on processor/compiler selection. In the case of the undefined behavior in C++, newbies (and most oldbies) write software that looks correct, but isn't. Code reviews don't catch it, and it takes weeks and weeks of wasted schedule time to find all of these subtle bugs. In these cases, anxiety is high and people lose their jobs. C++ gets blamed. Of course, one could argue that they deserve to lose their jobs, because they didn't take their jobs seriously in the first place. You know, focusing on meetings, process, and politics, and not bothering to grok the standard. With C++ I'm able to make a SafeInt class that does define this behavior and other overflow/underflow cases, at the cost of performance. That's cool. I never have the time to do that. Lazy again. If I made one, no one would want to learn to use it. I wouldn't use it either, because I"ve read the standard and have learned how to avoid these pitfalls. And I secretly adore efficiency. Bjarne Stroustrup implied that C++ would be enjoyable, not necessarily easier. I get the two concepts confused. terry -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |