The D Programming Language
in [C++]
|
From: Gabriel Dos Reis on 23 Nov 2006 15:26 Walter Bright <walter(a)digitalmars-nospamm.com> writes: [...] | > For a library solution, I've seen compiler steadily improving support | > for library functionalities -- think of GCC and its support for C | > library functions. I'm afraid your speculation is countered by actual | > data. | | Ok, show me a language that is so user extensible so that, say, I can | construct a library so powerful that it can exactly emulate other | computer languages. I don't think that was the point I'm disputing. If you would prefer to change topic, that is fine by me; but, let's make sure we start a new thread and adequately change the "Subject:" too. The question was not a language that is powerful enought to emulate any other language. The point I was disputing was: # 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 | > | > no, it is not. | | If you think it can be done, by all means go for it. Again, you made a claim that some *allegation was obvious*. I'm saying that the allegation was not obvious. That is a different claim from from "it can be done". | > | If it was possible, out of the thousands of languages | > | invented, certainly one of them would have done so? | > Some have done quite a remarkable job at it; you just need to admit | > it. That is a separate problem. | | I'd love to see a language where you could, say, add the ability to | compile C++ source by adding a library. Are you insuating that it is impossible to have a C++ compiler as library component in a C++ program? | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2116.pdf | | Thank you for the convenient reference. It's a good proposal. But I | don't think it really allows for user defined literals; what it does is | just do more advanced constant folding so you can have functions (and | constructors) in constant expressions. For example, the proposal still | does not allow: | | complex foo = x + 3i; // 3i is an imaginary type struct imaginary { constexpr explicit imaginary(double x = 0.0) : val(x) { } friend constexpr imaginary operator*(double re, imaginary im) { return imaginary(re * im.val); } friend constexpr complex operator+(double re, imaginary im) { return complex(re, im.val); } // ... private: double val; }; constexpr imaginary i(1.0); // constant expression of type imaginary complex foo = x + 3 * i; // 3 * i is a constant expression of // type imaginary ? [...] | > One of them is to allow users to attach their meaning to tokens. | | I foresee a great future for new meanings for the 'static' keyword <g>. That is too easy a prediction. -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 23 Nov 2006 15:24 David Abrahams wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: >> Ok, show me a language that is so user extensible so that, say, I can >> construct a library so powerful that it can exactly emulate other >> computer languages. In other words, where is language X that can accept >> C++, Pascal, C#, Lisp, etc., source code just be adding on a powerful >> library? > > FORTH Has anyone proven this by writing a FORTH library that can accept C++ source code? Pascal code? C# code? Lisp code? > What's important is to be able to write sufficiently expressive APIs, > for some definition of "sufficiently expressive." I don't believe C++ > or D has been built with enough flexibility to allow what I consider > "sufficient." As I suggested to Bo Persson, such a "mother of all languages" may not be that usable. After all, why aren't you using FORTH? -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Walter Bright on 23 Nov 2006 15:25 David Abrahams wrote: > Walter Bright <walter(a)digitalmars-nospamm.com> writes: >> 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. I think you answered your question <g>. The only thing I can think of to add is that Python may need to put such basic things it its core language for performance reasons. A constant theme I hear from heavy Python programmers is they have to be adept at C because they have to write bits and pieces of their app in C and hook them into the Python engine, because doing it in 100% Python is too slow. Neither D nor C++ have that problem. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Gabriel Dos Reis on 23 Nov 2006 15:26 Walter Bright <walter(a)digitalmars-nospamm.com> writes: | Gabriel Dos Reis wrote: | > So, there must be something more to your arguments than you have | > said. | | See my reply to Alf P. Steinbach dated 11/22/2006 2:29 PM in this thread. I think I sent my message long before your reply appeared on my newsserver, and I believe my message had been in the moderation for some time. The usual stuff for a moderated group. | BTW, Prof. Kahan is the person behind the design of the 8087 floating | point CPU chip, as well as the IEEE 754 floating point specification. As if I did not know. But, the 8087 floating point implementation does not meet unanimous consensus -- and this not just from ignorant programmers. | If | there is any authority on computer floating point, it'd be him. Although | argument by authority is a logical fallacy, Yes, argument by authority is a logical fallacy; that is why I was excepting you to logically explain your points without having to appeal "but Prof. Kahan says so". -- Gabriel Dos Reis gdr(a)integrable-solutions.net [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Andrei Alexandrescu (See Website For Email) on 23 Nov 2006 19:58
James Kanze wrote: > AJ wrote: >> One other serious legacy flaw in D (inherited from C/C++) is that it >> doesn't do away with undefined behavior. It's close, I think, but it's >> unfortunate that the holes aren't closed entirely. > > No language manages to completely do away with undefined > behavior. Although C++ could surely do better in this regard; > there's a lot of unnecessary undefined behavior. (Late in the thread, but this cannot be let slip away.) Whatever happened to all languages that do manage to completely do away with undefined behavior? I'm asking this again: it would be best if we all refrained from "I'll qualify it on-demand" statements. Andrei -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |